iOrchard http://www.iorchard.net/ Virtualization, Cloud Computing Expert Group en-us Tue, 12 Feb 2019 00:00:00 +0900 http://www.iorchard.net/2019/02/12/wisekb_데이터_복구.html http://www.iorchard.net/2019/02/12/wisekb_데이터_복구.html <![CDATA[wisekb 파티션 테이블 복구]]> wisekb 파티션 테이블 복구

개요

wisekb(가상머신)의 xvdb디스크(8T)의 디스크 파티션이 손상되어,

wisekb의 파티션 테이블을 복구하는 과정을 기술합니다.

Index

  • 1.) TestDisk를 이용한 파티션 테이블 복구
  • 2.) 슈퍼블록/그룹 디스크립터 복구작업
  • 3.) fsck 진행을 위한 설정 및 복구

wisekb의 정보

  • wisekb를 구동하는 하이퍼바이저의 호스트네임은 qaserver이다.
  • wisekb의 xvdb 디스크를 export 중인 스토리서버의 호스트네임은 storage4이다.

손상 전 디스크의 정보

  • Device name : xvdb
  • LV name : vm-60-b
  • Disk Size : 8TB / 8796.1GB / 8796093022208 bytes
  • Sector Size : 512B
  • Partition Table : gpt
    • Partition Number : 1
    • Start Size : 1049kB
    • End Size : 8796GB
    • File system type : ext4

손상 후 디스크의 상태

현재 디스크는 파티션 테이블이 없음을 나타낸다.:

root@qaserver:~# parted /dev/pengrix_vg/vm-60-b
GNU Parted 2.3
Using /dev/dm-53
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Linux device-mapper (linear) (dm)
Disk /dev/dm-53: 8796GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  8796GB  8796GB  ext4
  • Partition Table 라인을 보면 loop의 값을 가진다.
  • 정상적이라면 gpt를 나타내야 한다.

복구 프로그램 조사

디스크 복구 프로그램은 아래 두가지가 가장 많이 사용된다.

  1. TestDisk
  2. PhotoRec

이 둘의 차이는 아래와 같다.

  • 파티션에서 문제가 발생하면 TestDisk.
  • 손실된 사진,파일을 복구 하려면 PhotoRec.

현재 wisekb의 경우 1번(TestDisk)의 프로그램을 사용하는 것이 적합하다.

TestDisk ?

  • 라이센스 : GPLv2+
  • 지원 운영체제 : 리눅스, 윈도우, OS X, FreeBSD, NetBSD, OpenBSD
  • TestDisk의 기능
    • Fix partition table, recover deleted partition
    • Recover FAT32 boot sector from its backup
    • Rebuild FAT12/FAT16/FAT32 boot sector
    • Fix FAT tables
    • Rebuild NTFS boot sector
    • Recover NTFS boot sector from its backup
    • Fix MFT using MFT mirror
    • Locate ext2/ext3/ext4 Backup SuperBlock
    • Undelete files from FAT, exFAT, NTFS and ext2 filesystem
    • Copy files from deleted FAT, exFAT, NTFS and ext2/ext3/ext4 partitions.

1.) TestDisk를 이용한 파티션 테이블 복구

TestDisk를 실행할 서버는 vm-60-b(LV)를 export하고있는 storage4에서 실행한다.

Install testdisk.:

root@storage4:~# apt-get install testdisk

Start testdisk.:

root@storage4:~# testdisk

Next.:

TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org


TestDisk is free data recovery software designed to help recover lost
partitions and/or make non-booting disks bootable again when these symptoms
are caused by faulty software, certain types of viruses or human error.
It can also be used to repair some filesystem errors.

Information gathered during TestDisk use can be recorded for later
review. If you choose to create the text file, testdisk.log , it
will contain TestDisk options, technical information and various
outputs; including any folder/file names TestDisk was used to find and
list onscreen.

Use arrow keys to select, then press Enter key:
>[ Create ] Create a new log file
 [ Append ] Append information to log file
 [ No Log ] Don't record anything
  • Create 를 눌러 로그파일을 만든다.

Next.:

TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

  TestDisk is free software, and
comes with ABSOLUTELY NO WARRANTY.

Select a media (use Arrow keys, then press Enter):
 Disk /dev/mapper/pengrix_vg-vm--21 - 537 GB / 501 GiB
 Disk /dev/mapper/pengrix_vg-vm--25 - 171 GB / 160 GiB
 Disk /dev/mapper/pengrix_vg-vm--29 - 536 GB / 500 GiB
 Disk /dev/mapper/pengrix_vg-vm--3 - 10 GB / 10 GiB
 Disk /dev/mapper/pengrix_vg-vm--30 - 107 GB / 100 GiB
 Disk /dev/mapper/pengrix_vg-vm--31 - 10 GB / 10 GiB
 Disk /dev/mapper/pengrix_vg-vm--32 - 107 GB / 100 GiB
 Disk /dev/mapper/pengrix_vg-vm--32--mysql - 536 GB / 500 GiB
 Disk /dev/mapper/pengrix_vg-vm--34 - 536 GB / 500 GiB
 Disk /dev/mapper/pengrix_vg-vm--35 - 53 GB / 50 GiB
 Disk /dev/mapper/pengrix_vg-vm--36 - 214 GB / 200 GiB
 Disk /dev/mapper/pengrix_vg-vm--4 - 10 GB / 10 GiB
 Disk /dev/mapper/pengrix_vg-vm--40 - 107 GB / 100 GiB
 Disk /dev/mapper/pengrix_vg-vm--42 - 107 GB / 100 GiB
 Disk /dev/mapper/pengrix_vg-vm--44 - 10 GB / 10 GiB
 Disk /dev/mapper/pengrix_vg-vm--45 - 53 GB / 50 GiB
 Disk /dev/mapper/pengrix_vg-vm--45--backup - 53 GB / 50 GiB
 Disk /dev/mapper/pengrix_vg-vm--49--back - 11 GB / 11 GiB
 Disk /dev/mapper/pengrix_vg-vm--50--back - 12 GB / 12 GiB
 Disk /dev/mapper/pengrix_vg-vm--53 - 10 GB / 10 GiB
 Disk /dev/mapper/pengrix_vg-vm--60 - 32 GB / 30 GiB
 Disk /dev/mapper/pengrix_vg-vm--60--b - 8796 GB / 8192 GiB
 Disk /dev/mapper/pengrix_vg-vm--60--b--back - 8796 GB / 8192 GiB
 Disk /dev/mapper/pengrix_vg-vm--60--c - 1099 GB / 1024 GiB
 Disk /dev/mapper/pengrix_vg-vm--60--d - 1099 GB / 1024 GiB
 Disk /dev/mapper/pengrix_vg-vm--62 - 107 GB / 100 GiB
 Disk /dev/mapper/pengrix_vg-vm--64 - 536 GB / 500 GiB
 Disk /dev/mapper/pengrix_vg-vm--65 - 547 GB / 510 GiB
 Disk /dev/mapper/pengrix_vg-vm--66 - 536 GB / 500 GiB - SMC SMC2108
 Disk /dev/mapper/pengrix_vg-vm--68 - 2684 GB / 2500 GiB - SMC SMC2108
 Disk /dev/mapper/pengrix_vg-vm--70 - 10 GB / 10 GiB
 Disk /dev/mapper/pengrix_vg-vm--71 - 536 GB / 500 GiB - SMC SMC2108
 Disk /dev/mapper/pengrix_vg-vm--75 - 536 GB / 500 GiB - SMC SMC2108
>Disk /dev/mapper/pengrix_vg-vm--77 - 536 GB / 500 GiB - SMC SMC2108
>[Previous]  [  Next  ]  [Proceed ]  [  Quit  ]

Note: Disk capacity must be correctly detected for a successful recovery.
If a disk listed above has incorrect size, check HD jumper settings, BIOS
detection, and install the latest OS patches and disk drivers.
  • 상/하 방향키로 vm–60–b - 8796 GB / 8192 GiB 를 선택한다.
  • 좌/우 방향키로 Proceed를 선택하고 엔터를 누른다.

Next.:

TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org


Disk /dev/mapper/pengrix_vg-vm--60--b - 8796 GB / 8192 GiB

Please select the partition table type, press Enter when done.
 [Intel  ] Intel/PC partition
 [EFI GPT] EFI GPT partition map (Mac i386, some x86_64...)
 [Humax  ] Humax partition table
 [Mac    ] Apple partition map
>[None   ] Non partitioned media
 [Sun    ] Sun Solaris partition
 [XBox   ] XBox partition
 [Return ] Return to disk selection




Note: Do NOT select 'None' for media with only a single partition. It's very
rare for a drive to be 'Non-partitioned'.
  • EFI GPT를 선택하고 엔터를 누른다.

Next.:

TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org


Disk /dev/mapper/pengrix_vg-vm--60--b - 8796 GB / 8192 GiB - CHS 17179869184 1 1

>[ Analyse  ] Analyse current partition structure and search for lost partitions
 [ Advanced ] Filesystem Utils
 [ Geometry ] Change disk geometry
 [ Options  ] Modify options
 [ Quit     ] Return to disk selection








Note: Correct disk geometry is required for a successful recovery. 'Analyse'
process may give some warnings if it thinks the logical geometry is mismatched.
  • Analyes를 선택하여 디스크를 검사하여 손실된 파티션을 스캔한다.

Next.:

TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/mapper/pengrix_vg-vm--60--b - 8796 GB / 8192 GiB - CHS 17179869184 1 1
Current partition structure:
     Partition                  Start        End    Size in sectors

Bad GPT partition, invalid signature.




                P=Primary  D=Deleted
>[Quick Search]
                            Try to locate partition
  • 현재는 파티션이 없다.
  • 엔터를 눌러 Quick Search를 시작한다.

Next.:

TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/mapper/pengrix_vg-vm--60--b - 8796 GB / 8192 GiB - CHS 17179869184 1 1
     Partition               Start        End    Size in sectors
>P MS Data                     2048 17179867135 17179865088





Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
                P=Primary  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
EXT4 Large file Sparse superblock, 8796 GB / 8191 GiB
  • 파티션이 발견되었다.
  • 엔터를 눌러 다음을 이어간다.

Next.:

TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/mapper/pengrix_vg-vm--60--b - 8796 GB / 8192 GiB - CHS 17179869184 1 1

     Partition                  Start        End    Size in sectors

 1 P MS Data                     2048 17179867135 17179865088

 [  Quit  ] >[Deeper Search]  [ Write  ]
                          Try to find more partitions
  • Write를 눌러 복구한다.

Next.:

TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Write partition table, confirm ? (Y/N)
  • Y를 눌러 파티션 테이블을 복구한다.

Next.:

TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org


You will have to reboot for the change to take effect.
  • Ok를 눌러 마친다.
  • 리부팅해야 적용이 된다.
  • 여기까지가 TestDisk를 이용한 파티션테이블 작업이며, 성공한 것으로 보인다.

straoge4 서버를 리부팅하였다.

이후 파티션테이블을 확인하였다.:

root@storage4:~# parted /dev/pengrix_vg/vm-60-b
GNU Parted 2.3
Using /dev/dm-6
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? ok
Model: Linux device-mapper (linear) (dm)
Disk /dev/dm-6: 8796GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  8796GB  8796GB  ext4
  • Partition Table 라인을 보니 gpt로 정상 표시된다.
  • 파티션 테이블 복구에 성공하였다.

이대로 데이터가 잘 살아있길 바라며, 마운트하여 데이터를 확인한다.:

root@storage4:~# kpartx -a /dev/pengrix_vg/vm-60-b
Alternate GPT is invalid, using primary GPT.

root@storage4:~# mount /dev/mapper/pengrix_vg-vm--60--b1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/mapper/pengrix_vg-vm--60--b1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
  • 아 에러가 발생하였다.
  • 슈퍼블록이 손상되었단다.

로그를 확인하였다.:

root@storage4:~# dmesg |tail
...
[8569958.689594] EXT4-fs warning (device dm-54): ext4_fill_super:3551: fragment/cluster size (1024) != block size (4096)
[8569958.710147] EXT4-fs (dm-54): ext4_check_descriptors: Checksum for group 0 failed (20449!=44364)
[8569958.710217] EXT4-fs (dm-54): group descriptors corrupted!
[8573527.573250] EXT4-fs warning (device dm-54): ext4_fill_super:3551: fragment/cluster size (1024) != block size (4096)
[8573527.594039] EXT4-fs (dm-54): ext4_check_descriptors: Checksum for group 0 failed (20449!=44364)
[8573527.594104] EXT4-fs (dm-54): group descriptors corrupted!
  • fragment/cluster 사이즈가 block사이즈와 같지 않다.
  • 그룹 디스크립터도 손상되었다.

파티션 정보를 덤프하여 Fragment/cluster와 Block Size를 확인한다.:

root@storage4:~# dumpe2fs /dev/pengrix_vg/vm-60-b
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   <none>
Last mounted on:          /test
Filesystem UUID:          b19f1f0d-fb1e-4a78-a73b-04f9910b4c79
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              536870912
Block count:              2147483648
Reserved block count:     107374182
Free blocks:              1074310842
Free inodes:              350075079
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      512
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Fri Dec 14 11:08:19 2018
Last mount time:          Fri Dec 14 14:12:29 2018
Last write time:          Mon Feb 11 16:30:20 2019
Mount count:              3
Maximum mount count:      27
Last checked:             Fri Dec 14 11:08:19 2018
Check interval:           15552000 (6 months)
Next check after:         Wed Jun 12 11:08:19 2019
Lifetime writes:          131 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      6c22ff8c-01be-4367-9e63-d0de2edfef0b
Journal backup:           inode blocks
ext2fs_read_bb_inode: A block group is missing an inode table
  • Blcok size : 4096
  • Fragment size : 4096

결론

파티션 테이블을 복구에 성공하였으나, 슈퍼블록/그룹디스크립터가 손상되었다.

2.) 슈퍼블록/그룹 디스크립터 복구작업

슈퍼블록/그룹 디스크럽터 복구를 위해 fsck를 진행한다.:

root@storage4:~# fsck /dev/mapper/pengrix_vg-vm--60--b1
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
ext2fs_open2: The ext2 superblock is corrupt
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: The ext2 superblock is corrupt while trying to open /dev/mapper/pengrix_vg-vm--60--b1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
  • 위 로그를 설명하자면 아래와 같다.
  • 슈퍼블록이 손상되어 fsck를 진행하지 못한다.
  • ext4 슈퍼블록은 정해진 위치의 블록에 백업본을 저장한다.
  • 현재 블록그룹0의 슈퍼블록은 손상되었으니, 백업본 블록에서 복구하여 fsck를 시도해야 한다는 설명이다.

슈퍼블록의 백업본 위치는 어떻게 알 수 있을까?

아래는 e2fsck man page의 내용 이다.:

-b superblock
          Instead of using the normal superblock, use an alternative superblock specified by superblock.  This
          option is normally used when the primary superblock has been corrupted.  The location of the  backup
          superblock is dependent on the filesystem's blocksize.  For filesystems with 1k blocksizes, a backup
          superblock can be found at block 8193; for filesystems with 2k blocksizes, at block 16384;  and  for
          4k blocksizes, at block 32768.

          Additional  backup  superblocks can be determined by using the mke2fs program using the -n option to
          print out where the superblocks were created.   The -b option to mke2fs, which  specifies  blocksize
          of the filesystem must be specified in order for the superblock locations that are printed out to be
          accurate.

          If an alternative superblock is specified and the filesystem is not opened  read-only,  e2fsck  will
          make  sure  that  the  primary superblock is updated appropriately upon completion of the filesystem
          check.
  • 슈퍼블록 백업본의 위치는 파일시스템 블록크기에 따라 다르다.
  • block size 1k = 8193
  • block size 2k = 16384
  • block size 4k = 32768

현재 우리의 경우 Block Size는?.:

root@storage4:~# dumpe2fs /dev/pengrix_vg/vm-60-b
...
Block size:               4096
...
  • 그렇다면 32768 위치에 슈퍼블록의 백업본이 있다는 것이다.

슈퍼블록의 백업본으로 복구하자.:

root@storage4:~# e2fsck -b 32768 /dev/mapper/pengrix_vg-vm--60--b1
e2fsck 1.41.12 (17-May-2010)
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/pengrix_vg-vm--60--b1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
  • 32768 블록(슈퍼블록 백업)으로 복구가 불가하다…

모든 슈퍼블록의 백업 위치를 덤프한다.:

root@storage4# mke2fs -n -S /dev/mapper/pengrix_vg-vm--60--b1
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
536870912 inodes, 2147483136 blocks
107374156 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
65536 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
    102400000, 214990848, 512000000, 550731776, 644972544, 1934917632
  • -S 옵션은 슈퍼블록과 그룹디스크립터를 생성하는 명령이다.
  • -n 옵션은 실제로 생성하지 않고 초안을 보도록 하는 옵션이다.
  • 즉, -S 와 -n 옵션을 함께 사용하면 -S옵션이 실제로 적용되지 않으며, -n옵션으로 인해 초안을 볼 수 있어 슈퍼블록의 위치를 파악할 수 있다.

위 결과를 보니 슈퍼블록의 백업위치는 아래와 같다.:

Superblock backups stored on blocks:
   32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
   4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
   102400000, 214990848, 512000000, 550731776, 644972544, 1934917632
  • 첫 번째 위치인 32768 에서 복구를 실패했었다.

두 번째 백업본으로 한다.:

root@storage4:~# e2fsck -b 98304 /dev/mapper/pengrix_vg-vm--60--b1
e2fsck 1.41.12 (17-May-2010)
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/pengrix_vg-vm--60--b1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
  • 두 번째 슈퍼블록의 백업본으로 시도했지만 효과가 없다.

나는 모든 슈퍼블록의 백업본에서 복구를 시도하였다.:

root@storage4:~# e2fsck -b 163840 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 229376 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 294912 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 819200 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 884736 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 1605632 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 2654208 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 4096000 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 7962624 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 11239424 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 20480000 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 23887872 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 71663616 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 78675968 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 102400000 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 214990848 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 512000000 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 550731776 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 644972544 /dev/mapper/pengrix_vg-vm--60--b1
root@storage4:~# e2fsck -b 1934917632 /dev/mapper/pengrix_vg-vm--60--b1
  • 절망적이게도 모든 슈퍼블록에서 복구를 할 수 없었다.
  • 모든 슈퍼블록이 손상된 것 같다.

아래는 mke2fs의 man page의 -S옵션 내용이다.:

-S     Write superblock and group descriptors only.  This is useful if all of  the  superblock  and  backup
          superblocks  are corrupted, and a last-ditch recovery method is desired.  It causes mke2fs to reini‐
          tialize the superblock and group descriptors, while not touching the inode table and the  block  and
          inode bitmaps.  The e2fsck program should be run immediately after this option is used, and there is
          no guarantee that any data will be salvageable.  It is critical to specify  the  correct  filesystem
          blocksize when using this option, or there is no chance of recovery.
  • 위 내용을 설명하자면 아래와 같다.
  • -S 옵션은 슈퍼블록/그룹디스크립터만 생성한다. (다른것은 건들지 않는다.)
  • -S 옵션은 슈퍼블록이 모두 손상되었을 경우 사용한다.
  • -S 옵션을 사용한 후에 e2fsck 프로그램을 사용하여 데이터를 복구해야 한다.
  • 모든 데이터가 복구될 보장은 없다.

결국은 -S옵션이 최후의 수단이며, 모든 데이터가 복구될지 보장할 수 없다.

하지만 지금 이것 말고 다른 방법이 없다. 시도하자.:

root@storage4:~# mke2fs -S /dev/mapper/pengrix_vg-vm--60--b1
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
536870912 inodes, 2147483136 blocks
107374156 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
65536 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
    102400000, 214990848, 512000000, 550731776, 644972544, 1934917632

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

다음으로 fsck로 복구를 시도한다.:

root@storage4:~# nohup fsck.ext4 -y /dev/mapper/pengrix_vg-vm--60--b1 &
  • 이제야 fsck가 진행된다.!

하지만 시작한지 5분도 안되어 종료되었다.:

[1]+  Exit 9                  nohup efsck.ext4 -y /dev/mapper/pengrix_vg-vm--60--b1
  • 왜?

로그를 확인한다.:

root@storage4:~# tail nohup.out
Illegal block #4 (3935540716) in inode 116701.  CLEARED.
Inode 116701 is too big.  Truncate? yes

Block #2107580 (761606450) causes directory to be too big.  CLEARED.
Error storing directory block information (inode=116701, block=0, num=1855256): Memory allocation failed

/dev/mapper/pengrix_vg-vm--60--b1: ***** FILE SYSTEM WAS MODIFIED *****
e2fsck: aborted

/dev/mapper/pengrix_vg-vm--60--b1: ***** FILE SYSTEM WAS MODIFIED *****
  • 메모리가 부족하여 종료되었다.
  • 디스크가 8T로 크니 메모리도 많이 소모되는 듯하다. 메모리를 늘리자.

결론

  • 기존 슈퍼블록은 모두 손상되어 복구에 실패한다.
  • mke2fs -S 옵션으로 슈퍼블록/그룹디스크립터만 새로 만들었다.
  • 이후 fsck가 정상적으로 진행이 가능하다.
  • 하지만 fsck가 많은 메모리를 소모한다.
  • 스왑 메모리를 늘려 fsck를 진행해야 한다.

3.) fsck 진행을 위한 설정

메모리가 부족하므로 스왑을 늘려야 한다.

현재 메모리 양을 확인한다.:

root@storage4:/data# free -m
             total       used       free     shared    buffers     cached
Mem:          3925       2749       1175          0          0       2591
-/+ buffers/cache:        156       3768
Swap:         1023          9       1014
  • free 양을 보니 1175M 이다.
  • 하지만 8T디스크를 검사하는데 얼마나 많은 메모리를 필요로 하는지 감이 안온다.

스왑 파일을 만들 디스크 공간을 확인한다.:

root@storage4:~# df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
rootfs         rootfs    9.9G  2.0G  7.5G  21% /
udev           devtmpfs   10M     0   10M   0% /dev
tmpfs          tmpfs     393M  828K  392M   1% /run
/dev/md0       ext4      9.9G  2.0G  7.5G  21% /
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs          tmpfs     990M     0  990M   0% /run/shm
/dev/sdb3      xfs       455G  2.8G  452G   1% /data
  • sdb3 (로컬디스크)를 마운트한 /data 디렉토리에 여유 공간이 많다.
  • /data 디렉토리에 스왑파일을 만들면 되겠다.

스왑 메모리를 100G 늘린다.:

root@storage4:~# cd /data

root@storage4:~# dd if=/dev/zero of=swapfile bs=1024M count=100
100+0 records in
100+0 records out
107374182400 bytes (107 GB) copied, 540.786 s, 199 MB/s

root@storage4:/data# mkswap swapfile
Setting up swapspace version 1, size = 104857596 KiB
no label, UUID=9ab1dfa2-95f9-4d37-8e23-6bd87983a5d7

root@storage4:/data# swapon swapfile

root@storage4:/data# free -m
             total       used       free     shared    buffers     cached
Mem:          3925       2776       1148          0          1       2594
-/+ buffers/cache:        181       3744
Swap:       103423          9     103414

fsck를 다시 시작하자.:

root@storage4:~# nohup fsck.ext4 -y /dev/mapper/pengrix_vg-vm--60--bp1 &

root@storage4:~# date
Thu Feb 14 19:33:30 KST 2019
  • 1시간 뒤 fsck가 스왑 100G도 모두 사용하고, 동일한 문제로 fsck가 중단되었다.
  • 대체 fsck가 8T 디스크를 검사하는데 얼만큼의 메모리를 필요로 하는건가?

스왑을 489G로 늘렸다.:

root@storage4:~# fdisk -l /dev/sdc

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
2 heads, 4 sectors/track, 122096646 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x88209d7d

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048    20973567    10485760   fd  Linux raid autodetect
/dev/sdc2        20973568   976773167   477899800   82  Linux swap / Solaris
  • sdc2(사용하지 않던 로컬디스크) 489G를 스왑으로 파티셔닝 하였다.

swapon.:

root@storage4:~# mkswap /dev/sdc2

root@storage4:~# swapon /dev/sdc2

root@storage4:~# free -m
         total       used       free     shared    buffers     cached
Mem:          3925       2641       1283          0       2291         72
-/+ buffers/cache:        277       3647
Swap:       467723          6     467716

fsck를 다시 시작하자.:

root@storage4:~# nohup fsck.ext4 -y /dev/mapper/pengrix_vg-vm--60--bp1 &

2시간 뒤 또 같은 문제가 발생하였다.:

root@storage4:~# tail nohup.out
Illegal block #2 (3928012957) in inode 2016311.  CLEARED.
Illegal block #3 (2666302642) in inode 2016311.  CLEARED.
Illegal block #10 (2258103330) in inode 2016311.  CLEARED.
Illegal block #12585020 (3965693365) in inode 2016311.  CLEARED.
Error storing directory block information (inode=2016311, block=0, num=12410723): Memory allocation failed

/dev/mapper/pengrix_vg-vm--60--bp1: ***** FILE SYSTEM WAS MODIFIED *****
e2fsck: aborted

/dev/mapper/pengrix_vg-vm--60--bp1: ***** FILE SYSTEM WAS MODIFIED *****
  • inode 2016311 검사중 메모리 할당에 실패하였고, 실제로 스왑을 모두 사용한다.
  • 이거 무슨 버그인가? 489G의 메모리가 정말 필요한걸까?

나는 특정 디렉토리 안에 fsck를 캐싱하는 설정을 알아냈다.

설정하자.:

root@storage4:/data# vi /etc/e2fsck.conf
[scratch_files]
directory = /data/fsck

다시 시작하자.:

root@storage4:~# nohup fsck.ext4 -y /dev/mapper/pengrix_vg-vm--60--bp1 &

root@storage4:/data# ls -l fsck/
total 149956
-rw------- 1 root root  1789952 Feb 15 01:03 81ad740c-ba73-40f2-9c18-23f053d3bcec-dirinfo-4PQwfi
-rw------- 1 root root   528384 Feb 15 12:10 81ad740c-ba73-40f2-9c18-23f053d3bcec-dirinfo-Ce6vB3
-rw------- 1 root root 65290240 Feb 15 12:10 81ad740c-ba73-40f2-9c18-23f053d3bcec-icount-9UI241
-rw------- 1 root root 63852544 Feb 15 01:03 81ad740c-ba73-40f2-9c18-23f053d3bcec-icount-QoYqDT
  • /data/fsck/ 디렉토리 안에 fsck로 인한 파일들이 생성된다.
  • 이 파일이 캐싱을 위한 파일들이다.
  • 시작한 시각 2019.02.15 01:05

중간에 메모리 부족으로 중단되었지만 다시 시작한 후 처음부터 시작히지 않고 이어지는 것을 확인했다.:

root@storage4:/data# tail nohup.out

Inode 2446049 has a extra size (11298) which is invalid
Fix? yes

Inode 2446049 has a bad extended attribute block 540680226.  Clear? yes

Inode 2446049, i_size is 651063008960127520, should be 0.  Fix? yes

Inode 2446049, i_blocks is 2414551584, should be 0.  Fix? yes
  • Inode 값을 확인 했다.

결론

  • 8T 디스크를 검사하는데 많은 메모리가 소모된다.
  • 스왑 메모리를 489G 로 늘렸다.
  • fsck의 결과를 /data/fsck 디렉토리안에 캐싱하도록 하였다.
  • 이렇게 하면 fsck가 중간에 메모리 부족으로 끊어져도 다시 시작하면 이어서 검사를 한다.
  • 즉, 메모리가 부족해도 fsck를 이어서 검사할 수 있으니 어떻게든 모두 검사는 마칠 수 있다.
]]>
Tue, 12 Feb 2019 00:00:00 +0900
http://www.iorchard.net/2019/01/30/build_debian_packages_and_create_an_iso.html http://www.iorchard.net/2019/01/30/build_debian_packages_and_create_an_iso.html <![CDATA[Build Debian Packages And Create an ISO]]> Build Debian Packages And Create an ISO

데비안 패키지 안에있는 드라이버를 최신버전으로 업데이트 후 해당 패키지를 가진 ISO를 만든다.

내 개발 VM(debian stretch) 의 i40e버전을 확인했다.

root@devpython3:~/test# modinfo i40e
filename:       /lib/modules/4.9.0-7-amd64/kernel/drivers/net/ethernet/intel/i40e/i40e.ko
version:        1.6.16-k
license:        GPL
description:    Intel(R) Ethernet Connection XL710 Network Driver
author:         Intel Corporation, <e1000-devel@lists.sourceforge.net>
srcversion:     6A2F1CCADEAF07D132536A0
alias:          pci:v00008086d00001588sv*sd*bc*sc*i*
alias:          pci:v00008086d00001587sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D3sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D2sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D1sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D0sv*sd*bc*sc*i*
alias:          pci:v00008086d000037CFsv*sd*bc*sc*i*
alias:          pci:v00008086d000037CEsv*sd*bc*sc*i*
alias:          pci:v00008086d00001587sv*sd*bc*sc*i*
alias:          pci:v00008086d00001589sv*sd*bc*sc*i*
alias:          pci:v00008086d00001586sv*sd*bc*sc*i*
alias:          pci:v00008086d00001585sv*sd*bc*sc*i*
alias:          pci:v00008086d00001584sv*sd*bc*sc*i*
alias:          pci:v00008086d00001583sv*sd*bc*sc*i*
alias:          pci:v00008086d00001581sv*sd*bc*sc*i*
alias:          pci:v00008086d00001580sv*sd*bc*sc*i*
alias:          pci:v00008086d00001574sv*sd*bc*sc*i*
alias:          pci:v00008086d00001572sv*sd*bc*sc*i*
depends:        ptp
retpoline:      Y
intree:         Y
vermagic:       4.9.0-7-amd64 SMP mod_unload modversions
parm:           debug:Debug level (0=none,...,16=all) (int)

해당 드라이버의 버전은 Intel adapter X722을 지원하지 안는다.

지원하는 최신 드라이를 다운받아 업그레이드 시킨다.

root@devpython3:~/test/i40e-2.7.29/src# make
make[1]: 디렉터리 '/usr/src/linux-headers-4.9.0-7-common' 들어감
make[2]: 디렉터리 '/usr/src/linux-headers-4.9.0-7-amd64' 들어감
  CC [M]  /root/test/i40e-2.7.29/src/i40e_main.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_ethtool.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_adminq.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_common.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_hmc.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_lan_hmc.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_nvm.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_debugfs.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_diag.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_txrx.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_ptp.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_filters.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_ddp.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_client.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_virtchnl_pf.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_dcb.o
  CC [M]  /root/test/i40e-2.7.29/src/i40e_dcb_nl.o
  CC [M]  /root/test/i40e-2.7.29/src/kcompat.o
  CC [M]  /root/test/i40e-2.7.29/src/kcompat_vfd.o
  LD [M]  /root/test/i40e-2.7.29/src/i40e.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /root/test/i40e-2.7.29/src/i40e.mod.o
  LD [M]  /root/test/i40e-2.7.29/src/i40e.ko
make[2]: 디렉터리 '/usr/src/linux-headers-4.9.0-7-amd64' 나감
make[1]: 디렉터리 '/usr/src/linux-headers-4.9.0-7-common' 나감
root@devpython3:~/test/i40e-2.7.29/src# make install
make[1]: 디렉터리 '/usr/src/linux-headers-4.9.0-7-common' 들어감
make[2]: 디렉터리 '/usr/src/linux-headers-4.9.0-7-amd64' 들어감
  Building modules, stage 2.
  MODPOST 1 modules
make[2]: 디렉터리 '/usr/src/linux-headers-4.9.0-7-amd64' 나감
make[1]: 디렉터리 '/usr/src/linux-headers-4.9.0-7-common' 나감
Installing modules...
make[1]: 디렉터리 '/usr/src/linux-headers-4.9.0-7-common' 들어감
make[2]: 디렉터리 '/usr/src/linux-headers-4.9.0-7-amd64' 들어감
  INSTALL /root/test/i40e-2.7.29/src/i40e.ko
  DEPMOD  4.9.0-7-amd64
make[2]: 디렉터리 '/usr/src/linux-headers-4.9.0-7-amd64' 나감
make[1]: 디렉터리 '/usr/src/linux-headers-4.9.0-7-common' 나감
/sbin/depmod -e -F /boot/System.map-4.9.0-7-amd64  -a 4.9.0-7-amd64
Updating initramfs...

다시 i40e의 정보를 확인.

root@devpython3:~/test/i40e-2.7.29/src# modinfo i40e
filename:       /lib/modules/4.9.0-7-amd64/updates/drivers/net/ethernet/intel/i40e/i40e.ko
version:        2.7.29
license:        GPL
description:    Intel(R) 40-10 Gigabit Ethernet Connection Network Driver
author:         Intel Corporation, <e1000-devel@lists.sourceforge.net>
srcversion:     2212C8D31172FBDBC9A1647
alias:          pci:v00008086d0000158Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000158Asv*sd*bc*sc*i*
alias:          pci:v00008086d000037D3sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D2sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D1sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D0sv*sd*bc*sc*i*
alias:          pci:v00008086d000037CFsv*sd*bc*sc*i*
alias:          pci:v00008086d000037CEsv*sd*bc*sc*i*
alias:          pci:v00008086d00001588sv*sd*bc*sc*i*
alias:          pci:v00008086d00001587sv*sd*bc*sc*i*
alias:          pci:v00008086d000015FFsv*sd*bc*sc*i*
alias:          pci:v00008086d00001589sv*sd*bc*sc*i*
alias:          pci:v00008086d00001586sv*sd*bc*sc*i*
alias:          pci:v00008086d00001585sv*sd*bc*sc*i*
alias:          pci:v00008086d00001584sv*sd*bc*sc*i*
alias:          pci:v00008086d00001583sv*sd*bc*sc*i*
alias:          pci:v00008086d00001581sv*sd*bc*sc*i*
alias:          pci:v00008086d00001580sv*sd*bc*sc*i*
alias:          pci:v00008086d00001574sv*sd*bc*sc*i*
alias:          pci:v00008086d00001572sv*sd*bc*sc*i*
depends:        ptp
retpoline:      Y
vermagic:       4.9.0-7-amd64 SMP mod_unload modversions
parm:           debug:Debug level (0=none,...,16=all) (int)

최신드라이버로 설치되었다.

[실험1]

현재 상태에서 커널업데이트 시에 설치한 최신 드라이버가 유지될까?

이론대로라면 당연히 유지되면 안된다.

커널을 업데이트 시키고 리부팅한다.

root@devpython3:/home/orchard# apt install linux-image-4.9.0-8-amd64

orchard@devpython3:~$ uname -a
Linux devpython3 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux

정상적으로 업데이트된 버전으로 부팅되었다.

i40e의 드라이버 버전을 확인

orchard@devpython3:~$ sudo su
root@devpython3:/home/orchard# modinfo i40e
filename:       /lib/modules/4.9.0-8-amd64/kernel/drivers/net/ethernet/intel/i40e/i40e.ko
version:        1.6.16-k
license:        GPL
description:    Intel(R) Ethernet Connection XL710 Network Driver
author:         Intel Corporation, <e1000-devel@lists.sourceforge.net>
srcversion:     6A2F1CCADEAF07D132536A0
alias:          pci:v00008086d00001588sv*sd*bc*sc*i*
alias:          pci:v00008086d00001587sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D3sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D2sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D1sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D0sv*sd*bc*sc*i*
alias:          pci:v00008086d000037CFsv*sd*bc*sc*i*
alias:          pci:v00008086d000037CEsv*sd*bc*sc*i*
alias:          pci:v00008086d00001587sv*sd*bc*sc*i*
alias:          pci:v00008086d00001589sv*sd*bc*sc*i*
alias:          pci:v00008086d00001586sv*sd*bc*sc*i*
alias:          pci:v00008086d00001585sv*sd*bc*sc*i*
alias:          pci:v00008086d00001584sv*sd*bc*sc*i*
alias:          pci:v00008086d00001583sv*sd*bc*sc*i*
alias:          pci:v00008086d00001581sv*sd*bc*sc*i*
alias:          pci:v00008086d00001580sv*sd*bc*sc*i*
alias:          pci:v00008086d00001574sv*sd*bc*sc*i*
alias:          pci:v00008086d00001572sv*sd*bc*sc*i*
depends:        ptp
retpoline:      Y
intree:         Y
vermagic:       4.9.0-8-amd64 SMP mod_unload modversions
parm:           debug:Debug level (0=none,...,16=all) (int)

업데이트 되어있지 않음을 확인.

그렇다면 해당 방법이 유효할 수 있겠다.

  1. 커널 패키지를 풀어 i40e 최신버전 컴파일 버전으로 바꿔주고 다시 패키지 빌드하여 커스텀 커널 패키지를 만든다.
  2. 해당 커스텀 커널 패키지를 simple-cdd 로컬 패키지에 추가시켜 ISO 빌드시 로컬패키지에서 커스텀 커널 패키지를 가져오게 한다.

[시험2]

해당 커널 이미지를 받아서 패키지를 커스텀해보자.

3.16.0-6커널이 필요하므로 jessie를 소스리스트에 추가하였다.

orchard@devpython3:~$ sudo vi /etc/apt/sources.list

deb http://ftp.daumkakao.com/debian jessie main non-free
deb-src http://ftp.daumkakao.com/debian jessie main non-free

추가한 후에 같은 버전의 커널이미지를 다운.

root@devpython3:/home/orchard# apt download linux-image-3.16.0-6-amd64

다운받은 이미지를 임의의 폴더에 풀었다.

root@devpython3:/home/orchard# dpkg-deb -R linux-image-3.16.0-6-amd64_3.16.56-1+deb8u1_amd64.deb test

root@devpython3:/home/orchard/test# ls
DEBIAN  boot  lib  usr

같은 경로에 존재하는 i40e드라이버를 최신버전 컴파일된 버전으로 변경한다.

개발머신 i40e드라이버 최신버전 업데이트 완료

root@devpython3:/home/orchard/i40e-2.7.29/src# modinfo i40e
filename:       /lib/modules/4.9.0-8-amd64/updates/drivers/net/ethernet/intel/i40e/i40e.ko
version:        2.7.29
license:        GPL
description:    Intel(R) 40-10 Gigabit Ethernet Connection Network Driver
author:         Intel Corporation, <e1000-devel@lists.sourceforge.net>
srcversion:     2212C8D31172FBDBC9A1647
alias:          pci:v00008086d0000158Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000158Asv*sd*bc*sc*i*
alias:          pci:v00008086d000037D3sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D2sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D1sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D0sv*sd*bc*sc*i*
alias:          pci:v00008086d000037CFsv*sd*bc*sc*i*
alias:          pci:v00008086d000037CEsv*sd*bc*sc*i*
alias:          pci:v00008086d00001588sv*sd*bc*sc*i*
alias:          pci:v00008086d00001587sv*sd*bc*sc*i*
alias:          pci:v00008086d000015FFsv*sd*bc*sc*i*
alias:          pci:v00008086d00001589sv*sd*bc*sc*i*
alias:          pci:v00008086d00001586sv*sd*bc*sc*i*
alias:          pci:v00008086d00001585sv*sd*bc*sc*i*
alias:          pci:v00008086d00001584sv*sd*bc*sc*i*
alias:          pci:v00008086d00001583sv*sd*bc*sc*i*
alias:          pci:v00008086d00001581sv*sd*bc*sc*i*
alias:          pci:v00008086d00001580sv*sd*bc*sc*i*
alias:          pci:v00008086d00001574sv*sd*bc*sc*i*
alias:          pci:v00008086d00001572sv*sd*bc*sc*i*
depends:        ptp
retpoline:      Y
vermagic:       4.9.0-8-amd64 SMP mod_unload modversions
parm:           debug:Debug level (0=none,...,16=all) (int)

i40e.ko 파일을 이미지파일의 경로에 복사.

root@devpython3:/home/orchard/i40e-2.7.29/src# cp /lib/modules/4.9.0-8-amd64/updates/drivers/net/ethernet/intel/i40e/i40e.ko /home/orchard/test/lib/modules/3.16.0-6-amd64/kernel/drivers/

복사된 이미지를 다시 패키징

root@devpython3:/home/orchard# dpkg-deb -b test linux-image-3.16.0-6-amd64_3.16.56-1+deb8u1_amd64.deb
dpkg-deb: building package 'linux-image-3.16.0-6-amd64' in 'linux-image-3.16.0-6-amd64_3.16.56-1+deb8u1_amd64.deb'.
root@devpython3:/home/orchard#

이제 커스텀 커널 패키지가 완성되었다.

해당 커널로 부팅시에 i40e가 최신 드라이버면 된다.

[시험3]

debian8.11(jessie) VM을 생성하고 해당 VM의 커널을 만든 커스텀 커널로 변경한다.

변경 후에 i40e 최신 버전인지 확인한다.

vm의 커널버전 확인.

orchard@hostname:~$ uname -a
Linux hostname 3.16.0-6-amd64 #1 SMP Debian 3.16.57-2 (2018-07-14) x86_64 GNU/Linux

설치한 패키지 커널버전 확인.

rchard@hostname:~$ ls
linux-image-3.16.0-6-amd64_3.16.56-1+deb8u1_amd64.deb

설치.

root@hostname:/home/orchard# dpkg -i linux-image-3.16.0-6-amd64_3.16.56-1+deb8u1_amd64.deb
dpkg: 경고: downgrading linux-image-3.16.0-6-amd64 from 3.16.57-2 to 3.16.56-1+deb8u1
(데이터베이스 읽는중 ...현재 21028개의 파일과 디렉터리가 설치되어 있습니다.)
Preparing to unpack linux-image-3.16.0-6-amd64_3.16.56-1+deb8u1_amd64.deb ...
Unpacking linux-image-3.16.0-6-amd64 (3.16.56-1+deb8u1) over (3.16.57-2) ...
linux-image-3.16.0-6-amd64 (3.16.56-1+deb8u1) 설정하는 중입니다 ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-3.16.0-6-amd64
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.16.0-6-amd64
Found initrd image: /boot/initrd.img-3.16.0-6-amd64
done

신기하게도 같은 버전의 커널상태에서 커스텀 패키지를 설치하니

root@hostname:/home/orchard# modinfo i40e
filename:       /lib/modules/3.16.0-6-amd64/kernel/drivers/net/ethernet/intel/i40e/i40e.ko
version:        2.7.29
license:        GPL
description:    Intel(R) 40-10 Gigabit Ethernet Connection Network Driver
author:         Intel Corporation, <e1000-devel@lists.sourceforge.net>
srcversion:     2212C8D31172FBDBC9A1647
alias:          pci:v00008086d0000158Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000158Asv*sd*bc*sc*i*
alias:          pci:v00008086d000037D3sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D2sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D1sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D0sv*sd*bc*sc*i*
alias:          pci:v00008086d000037CFsv*sd*bc*sc*i*
alias:          pci:v00008086d000037CEsv*sd*bc*sc*i*
alias:          pci:v00008086d00001588sv*sd*bc*sc*i*
alias:          pci:v00008086d00001587sv*sd*bc*sc*i*
alias:          pci:v00008086d000015FFsv*sd*bc*sc*i*
alias:          pci:v00008086d00001589sv*sd*bc*sc*i*
alias:          pci:v00008086d00001586sv*sd*bc*sc*i*
alias:          pci:v00008086d00001585sv*sd*bc*sc*i*
alias:          pci:v00008086d00001584sv*sd*bc*sc*i*
alias:          pci:v00008086d00001583sv*sd*bc*sc*i*
alias:          pci:v00008086d00001581sv*sd*bc*sc*i*
alias:          pci:v00008086d00001580sv*sd*bc*sc*i*
alias:          pci:v00008086d00001574sv*sd*bc*sc*i*
alias:          pci:v00008086d00001572sv*sd*bc*sc*i*
depends:        ptp
retpoline:      Y
vermagic:       4.9.0-8-amd64 SMP mod_unload modversions
parm:           debug:Debug level (0=none,...,16=all) (int)

최신버전의 드라이버가 설치되었다.

즉, 해당 커널에 덮어씌어진것이다.

실제로 menuentry에서 확인해도 커널이 더 추가되어 있지 않았다.

less /boot/grub/grub.cfg

submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 'gnulinux-advanced-8a7ff91c-4fdf-48e4-801b-63d634a36a36' {
        menuentry 'Debian GNU/Linux, with Linux 3.16.0-6-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-6-amd64-advanced-8a7ff91c-4fdf-48e4-801b-63d634a36a36' {
                load_video
                insmod gzio
                if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
                insmod part_msdos
                insmod ext2
                if [ x$feature_platform_search_hint = xy ]; then
                  search --no-floppy --fs-uuid --set=root  8a7ff91c-4fdf-48e4-801b-63d634a36a36
                else
                  search --no-floppy --fs-uuid --set=root 8a7ff91c-4fdf-48e4-801b-63d634a36a36
                fi
                echo    'Loading Linux 3.16.0-6-amd64 ...'
                linux   /boot/vmlinuz-3.16.0-6-amd64 root=UUID=8a7ff91c-4fdf-48e4-801b-63d634a36a36 ro  quiet
                echo    'Loading initial ramdisk ...'
                initrd  /boot/initrd.img-3.16.0-6-amd64
        }
        menuentry 'Debian GNU/Linux, with Linux 3.16.0-6-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-6-amd64-recovery-8a7ff91c-4fdf-48e4-801b-63d634a36a36' {
                load_video
                insmod gzio
                if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
                insmod part_msdos
                insmod ext2
                if [ x$feature_platform_search_hint = xy ]; then
                  search --no-floppy --fs-uuid --set=root  8a7ff91c-4fdf-48e4-801b-63d634a36a36
                else
                  search --no-floppy --fs-uuid --set=root 8a7ff91c-4fdf-48e4-801b-63d634a36a36
                fi
                echo    'Loading Linux 3.16.0-6-amd64 ...'
                linux   /boot/vmlinuz-3.16.0-6-amd64 root=UUID=8a7ff91c-4fdf-48e4-801b-63d634a36a36 ro single
                echo    'Loading initial ramdisk ...'
                initrd  /boot/initrd.img-3.16.0-6-amd64
        }
}

결론은 커스텀한 패키지로 설치하니 최신버전의 드라이버가 되었다!

이제 이 커스텀 커널 패키지를 이용해서 ISO를 만드는 일만 남았다.

해당 커스텀 패키지는 스트래치 기반인 내 개발 VM에서 만들었다.

이게 문제가 될수도 있다는 전광석 연구원님의 말을 들어 jessie머신에서 다시 패키징한다.

최신 드라이버 다운.

root@hostname:~# wget https://downloadmirror.intel.com/24411/eng/i40e-2.7.29.tar.gz
--2019-01-31 22:29:05--  https://downloadmirror.intel.com/24411/eng/i40e-2.7.29.tar.gz
Resolving downloadmirror.intel.com (downloadmirror.intel.com)... 23.212.12.6
Connecting to downloadmirror.intel.com (downloadmirror.intel.com)|23.212.12.6|:443... connected.
ERROR: The certificate of ‘downloadmirror.intel.com’ is not trusted.
ERROR: The certificate of ‘downloadmirror.intel.com’ hasn't got a known issuer.

인증서를 신뢰할수 없다구요?

인증서를 체크하지 않는 옵션을 넣어서 받았다.

root@hostname:~# wget --no-check-certificate  https://downloadmirror.intel.com/24411/eng/i40e-2.7.29.tar.gz
--2019-01-31 22:31:37--  https://downloadmirror.intel.com/24411/eng/i40e-2.7.29.tar.gz
Resolving downloadmirror.intel.com (downloadmirror.intel.com)... 23.212.12.6
Connecting to downloadmirror.intel.com (downloadmirror.intel.com)|23.212.12.6|:443... connected.
WARNING: The certificate of ‘downloadmirror.intel.com’ is not trusted.
WARNING: The certificate of ‘downloadmirror.intel.com’ hasn't got a known issuer.
HTTP request sent, awaiting response... 200 OK
Length: 543977 (531K) [application/x-gzip]
Saving to: ‘i40e-2.7.29.tar.gz’

i40e-2.7.29.tar.gz            100%[================================================>] 531.23K  --.-KB/s   in 0.1s

2019-01-31 22:31:38 (5.42 MB/s) - ‘i40e-2.7.29.tar.gz’ saved [543977/543977]

컴파일한다.

root@hostname:~/i40e-2.7.29/src# make install
bash: make: command not found

make라는 명령어를 찾을 수 없다.

어떤 패키지가 누락되어 있을것이다.

root@hostname:~/i40e-2.7.29/src# apt install build-essential

설치 후 다시 컴파일 시도.

root@hostname:~/i40e-2.7.29/src# make install
common.mk:81: *** Kernel header files not in any of the expected locations.
common.mk:82: *** Install the appropriate kernel development package, e.g.
common.mk:83: *** kernel-devel, for building kernel modules and try again.  멈춤.

이번엔 헤더를 찾을 수 없다.

헤더를 설치.

::
root@hostname:~/i40e-2.7.29/src# apt install linux-headers-3.16.0-6-amd64

컴파일.

root@hostname:~/i40e-2.7.29/src# make install
make[1]: Entering directory '/usr/src/linux-headers-3.16.0-6-common'
make[1]: Entering directory `/usr/src/linux-headers-3.16.0-6-amd64'
  CC [M]  /root/i40e-2.7.29/src/i40e_main.o
  CC [M]  /root/i40e-2.7.29/src/i40e_ethtool.o
  CC [M]  /root/i40e-2.7.29/src/i40e_adminq.o
  CC [M]  /root/i40e-2.7.29/src/i40e_common.o
  CC [M]  /root/i40e-2.7.29/src/i40e_hmc.o
  CC [M]  /root/i40e-2.7.29/src/i40e_lan_hmc.o
  CC [M]  /root/i40e-2.7.29/src/i40e_nvm.o
  CC [M]  /root/i40e-2.7.29/src/i40e_debugfs.o
  CC [M]  /root/i40e-2.7.29/src/i40e_diag.o
  CC [M]  /root/i40e-2.7.29/src/i40e_txrx.o
  CC [M]  /root/i40e-2.7.29/src/i40e_ptp.o
  CC [M]  /root/i40e-2.7.29/src/i40e_filters.o
  CC [M]  /root/i40e-2.7.29/src/i40e_ddp.o
  CC [M]  /root/i40e-2.7.29/src/i40e_client.o
  CC [M]  /root/i40e-2.7.29/src/i40e_virtchnl_pf.o
  CC [M]  /root/i40e-2.7.29/src/i40e_dcb.o
  CC [M]  /root/i40e-2.7.29/src/i40e_dcb_nl.o
  CC [M]  /root/i40e-2.7.29/src/kcompat.o
  CC [M]  /root/i40e-2.7.29/src/kcompat_vfd.o
  LD [M]  /root/i40e-2.7.29/src/i40e.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /root/i40e-2.7.29/src/i40e.mod.o
  LD [M]  /root/i40e-2.7.29/src/i40e.ko
make[1]: Leaving directory '/usr/src/linux-headers-3.16.0-6-common'
Installing modules...
make[1]: Entering directory '/usr/src/linux-headers-3.16.0-6-common'
make[1]: Entering directory `/usr/src/linux-headers-3.16.0-6-amd64'
  INSTALL /root/i40e-2.7.29/src/i40e.ko
  DEPMOD  3.16.0-6-amd64
make[1]: Leaving directory '/usr/src/linux-headers-3.16.0-6-common'
/sbin/depmod -e -F /boot/System.map-3.16.0-6-amd64  -a 3.16.0-6-amd64
Updating initramfs...
update-initramfs: Generating /boot/initrd.img-3.16.0-6-amd64
make mandocs_install
make[1]: Entering directory '/root/i40e-2.7.29/src'
Copying manpages...
make[1]: Leaving directory '/root/i40e-2.7.29/src'

컴파일 완료되었다. VM을 한번 리부팅 해주자.

드라이버의 버전을 확인.

root@hostname:/home/orchard# modinfo i40e
filename:       /lib/modules/3.16.0-6-amd64/updates/drivers/net/ethernet/intel/i40e/i40e.ko
version:        2.7.29
license:        GPL
description:    Intel(R) 40-10 Gigabit Ethernet Connection Network Driver
author:         Intel Corporation, <e1000-devel@lists.sourceforge.net>
srcversion:     2212C8D31172FBDBC9A1647
alias:          pci:v00008086d0000158Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000158Asv*sd*bc*sc*i*
alias:          pci:v00008086d000037D3sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D2sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D1sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D0sv*sd*bc*sc*i*
alias:          pci:v00008086d000037CFsv*sd*bc*sc*i*
alias:          pci:v00008086d000037CEsv*sd*bc*sc*i*
alias:          pci:v00008086d00001588sv*sd*bc*sc*i*
alias:          pci:v00008086d00001587sv*sd*bc*sc*i*
alias:          pci:v00008086d000015FFsv*sd*bc*sc*i*
alias:          pci:v00008086d00001589sv*sd*bc*sc*i*
alias:          pci:v00008086d00001586sv*sd*bc*sc*i*
alias:          pci:v00008086d00001585sv*sd*bc*sc*i*
alias:          pci:v00008086d00001584sv*sd*bc*sc*i*
alias:          pci:v00008086d00001583sv*sd*bc*sc*i*
alias:          pci:v00008086d00001581sv*sd*bc*sc*i*
alias:          pci:v00008086d00001580sv*sd*bc*sc*i*
alias:          pci:v00008086d00001574sv*sd*bc*sc*i*
alias:          pci:v00008086d00001572sv*sd*bc*sc*i*
depends:        ptp,vxlan
retpoline:      Y
vermagic:       3.16.0-6-amd64 SMP mod_unload modversions
parm:           debug:Debug level (0=none,...,16=all) (int)

어제와 같은 방법으로 드라이버를 바꾸고 패키징한다.

root@hostname:~# mkdir test
root@hostname:~# dpkg-deb -R linux-image-3.16.0-6-amd64_3.16.57-2_amd64.deb test
root@hostname:~# cd test
root@hostname:~/test# cp /lib/modules/3.16.0-6-amd64/updates/drivers/net/ethernet/intel/i40e/i40e.ko lib/modules/3.16.0-6-amd64/kernel/drivers/net/ethernet/intel/i40e/i40e.ko
root@hostname:~# dpkg-deb -b test linux-image-3.16.0-6-amd64_3.16.57-2_amd64.deb

이러면 이제 제시의 제시에 의한 제시를 위한 최신커널을 탑재한 커스텀 커널 패키지가 완성되었다.

curry에서 구동중인 custom-jessie VM으로 이동한다.

[ISO 생성]

custom-jessie VM의 로컬패키지 폴더를 확인했다.

orchard@customcd-jessie:~/custom-cd/jessie/profiles/pengx3_localpkg$ ls
libxen-4.6_4.6.0-1+nmu2_amd64.deb        splash.png
libxen-dev_4.6.0-1+nmu2_amd64.deb        uxenapi.deb
libxenstore3.0_4.6.0-1+nmu2_amd64.deb    xen-hypervisor-4.6-amd64_4.6.0-1+nmu2_amd64.deb
pengxconf.deb                            xenstore-utils_4.6.0-1+nmu2_amd64.deb
qemu-system-common_2.5+dfsg-5_amd64.deb  xen-system-amd64_4.6.0-1+nmu2_amd64.deb
qemu-system-x86_2.5+dfsg-5_amd64.deb     xen-utils-4.6_4.6.0-1+nmu2_amd64.deb
qemu-utils_2.5+dfsg-5_amd64.deb          xen-utils-common_4.6.0-1+nmu2_all.deb

이론대로라면 여기에 해당 커널이미지를 넣어두면 미러가아닌 이곳에서 커널패키지를 가져와야 한다.

먼저 이곳에 커스텀 커널 패키지를 이동시키자.

root@hostname:~# scp -P 42544 linux-image-3.16.0-6-amd64_3.16.57-2_amd64.deb 110.45.238.92:/home/orchard/custom-cd/jessie/profiles/pengx3_localpkg

잘 도착한 것을 확인했다.

orchard@customcd-jessie:~/custom-cd/jessie/profiles/pengx3_localpkg$ ls
libxen-4.6_4.6.0-1+nmu2_amd64.deb               splash.png
libxen-dev_4.6.0-1+nmu2_amd64.deb               uxenapi.deb
libxenstore3.0_4.6.0-1+nmu2_amd64.deb           xen-hypervisor-4.6-amd64_4.6.0-1+nmu2_amd64.deb
linux-image-3.16.0-6-amd64_3.16.57-2_amd64.deb  xenstore-utils_4.6.0-1+nmu2_amd64.deb
pengxconf.deb                                   xen-system-amd64_4.6.0-1+nmu2_amd64.deb
qemu-system-common_2.5+dfsg-5_amd64.deb         xen-utils-4.6_4.6.0-1+nmu2_amd64.deb
qemu-system-x86_2.5+dfsg-5_amd64.deb            xen-utils-common_4.6.0-1+nmu2_all.deb
qemu-utils_2.5+dfsg-5_amd64.deb

이제 만들기만 하면 되는건가??

받아올 패키지를 저장하는 uxen3.package파이을 봤다.

orchard@customcd-jessie:~/custom-cd/jessie/profiles$ less uxen3.packages

# Kernel related packages. (kernel version 3.16.0-6-amd64)
linux-headers-amd64
linux-kbuild-3.16
initramfs-tools

# Xen essential packages. (Xen Version 4.6)
linux-image-amd64
xen-hypervisor-4.6-amd64
libxenstore3.0
xenstore-utils
libxen-4.6
libxen-dev
xen-utils-4.6
xen-system-amd64

커스텀 커널의 이름을 바꿔서 혼동되지 않도록 해보자.

이름변경.

orchard@customcd-jessie:~/custom-cd/jessie/profiles/pengx3_localpkg$ mv linux-image-3.16.0-6-amd64_3.16.57-2_amd64.deb linux-image-custom-3.16.0-6-amd64_3.16.57-2_amd64.deb

그룹과 소유자가 root root이다 혹시모르니 이것도 맞춰두자.

orchard@customcd-jessie:~/custom-cd/jessie/profiles/pengx3_localpkg$ ls -al
total 52956
drwxr-xr-x 2 orchard orchard     4096 Jan 31 14:35 .
drwxr-xr-x 4 orchard orchard     4096 Oct  8 14:48 ..
-rw-r--r-- 1 orchard orchard   362856 Sep  6 19:22 libxen-4.6_4.6.0-1+nmu2_amd64.deb
-rw-r--r-- 1 orchard orchard   574588 Sep  6 19:23 libxen-dev_4.6.0-1+nmu2_amd64.deb
-rw-r--r-- 1 orchard orchard    31054 Sep  6 19:23 libxenstore3.0_4.6.0-1+nmu2_amd64.deb
-rw-r--r-- 1 root    root    35962048 Jan 31 14:22 linux-image-custom-3.16.0-6-amd64_3.16.57-2_amd64.deb
-rw-r--r-- 1 orchard orchard     2062 Oct  1 12:02 pengxconf.deb
-rw-r--r-- 1 orchard orchard   326130 Sep  6 19:25 qemu-system-common_2.5+dfsg-5_amd64.deb
-rw-r--r-- 1 orchard orchard  3480820 Sep  6 19:27 qemu-system-x86_2.5+dfsg-5_amd64.deb
-rw-r--r-- 1 orchard orchard   625228 Sep  6 19:28 qemu-utils_2.5+dfsg-5_amd64.deb
-rw-r--r-- 1 orchard orchard    80944 Sep 12 13:56 splash.png
-rw-r--r-- 1 orchard orchard 10263046 Sep 27 02:33 uxenapi.deb
-rw-r--r-- 1 orchard orchard  1737314 Sep  6 19:28 xen-hypervisor-4.6-amd64_4.6.0-1+nmu2_amd64.deb
-rw-r--r-- 1 orchard orchard    26768 Sep  6 19:29 xenstore-utils_4.6.0-1+nmu2_amd64.deb
-rw-r--r-- 1 orchard orchard    20124 Sep  6 19:28 xen-system-amd64_4.6.0-1+nmu2_amd64.deb
-rw-r--r-- 1 orchard orchard   469116 Sep  6 19:29 xen-utils-4.6_4.6.0-1+nmu2_amd64.deb
-rw-r--r-- 1 orchard orchard   230726 Sep  6 19:29 xen-utils-common_4.6.0-1+nmu2_all.deb

orchard@customcd-jessie:~/custom-cd/jessie/profiles/pengx3_localpkg$ sudo chown -R orchard:orchard linux-image-custom-3.16.0-6-amd64_3.16.57-2_amd64.deb

패키지 파일에서 가져올 커널이미지의 이름을 변경한다.

# Kernel related packages. (kernel version 3.16.0-6-amd64)
linux-headers-amd64
linux-kbuild-3.16
initramfs-tools

# Xen essential packages. (Xen Version 4.6)
linux-image-custom
xen-hypervisor-4.6-amd64
libxenstore3.0
xenstore-utils
libxen-4.6
libxen-dev
xen-utils-4.6
xen-system-amd64

이렇게 하면 어떻게 될까?

한번 시험해본다.

xen 패키지에 왜 커널이 있는지도 의문이지만 일단 넘긴다.

빌드 시작!!

orchard@customcd-jessie:~/custom-cd/jessie$ build-simple-cdd -p uxen3

...

ERROR: '/home/orchard/custom-cd/jessie/profiles/pengx3_localpkg/linux-image-custom-3.16.0-6-amd64_3.16.57-2_amd64.deb' cannot be included as 'pool/main/l/linux/linux-image-3.16.0-6-amd64_3.16.57-2_amd64.deb'.
Already existing files can only be included again, if they are the same, but:
md5 expected: 3630686f4e62a48fc3c3a77ac605de18, got: 10c67185f75f2a432010824b13b1efdb
sha1 expected: 363298eef94d4b610e2157ff1e83b40e1684d31c, got: 2bf616beec78603af0e4bd8a9d2246b3e3ea1692
sha256 expected: ff5b674f8dd7273678e7784204828ea652c59a618876ab613c11120117ab099f, got: 3eb371bf79ec7d938848a802ec585e80dd3c857be584c13371794261f4565e6d
size expected: 34522160, got: 35962048
There have been errors!

...

WARNING: missing optional packages from profile default:  console-tools
ERROR: missing required packages from profile uxen3:  linux-image-custom

에러가 발생한다.

메세지의 내용을 보니 이전설정으로 돌려두면 될것 같다.

이전설정으로 돌린 후 다시 빌드 시작.

xorriso : UPDATE :  2.14% done
xorriso : UPDATE :  3.81% done, estimate finish Thu Jan 31 15:00:26 2019
xorriso : UPDATE :  3.81% done, estimate finish Thu Jan 31 15:00:52 2019
xorriso : UPDATE :  5.20% done, estimate finish Thu Jan 31 15:00:47 2019
xorriso : UPDATE :  7.62% done, estimate finish Thu Jan 31 15:00:32 2019
xorriso : UPDATE :  11.43% done, estimate finish Thu Jan 31 15:00:16 2019
xorriso : UPDATE :  15.24% done, estimate finish Thu Jan 31 15:00:09 2019
xorriso : UPDATE :  16.83% done, estimate finish Thu Jan 31 15:00:10 2019
xorriso : UPDATE :  19.05% done, estimate finish Thu Jan 31 15:00:10 2019
xorriso : UPDATE :  22.45% done, estimate finish Thu Jan 31 15:00:07 2019
xorriso : UPDATE :  26.67% done, estimate finish Thu Jan 31 15:00:03 2019
xorriso : UPDATE :  30.48% done, estimate finish Thu Jan 31 15:00:01 2019
xorriso : UPDATE :  34.29% done, estimate finish Thu Jan 31 14:59:59 2019
xorriso : UPDATE :  38.10% done, estimate finish Thu Jan 31 14:59:58 2019
xorriso : UPDATE :  41.90% done, estimate finish Thu Jan 31 14:59:57 2019
xorriso : UPDATE :  49.52% done, estimate finish Thu Jan 31 14:59:49 2019
xorriso : UPDATE :  56.89% done, estimate finish Thu Jan 31 14:59:47 2019
xorriso : UPDATE :  61.67% done, estimate finish Thu Jan 31 14:59:47 2019
xorriso : UPDATE :  65.05% done, estimate finish Thu Jan 31 14:59:47 2019
xorriso : UPDATE :  70.08% done, estimate finish Thu Jan 31 14:59:47 2019
xorriso : UPDATE :  75.43% done, estimate finish Thu Jan 31 14:59:46 2019
xorriso : UPDATE :  79.93% done, estimate finish Thu Jan 31 14:59:46 2019
xorriso : UPDATE :  82.78% done, estimate finish Thu Jan 31 14:59:47 2019
xorriso : UPDATE :  84.55% done, estimate finish Thu Jan 31 14:59:47 2019
xorriso : UPDATE :  87.62% done, estimate finish Thu Jan 31 14:59:48 2019
xorriso : UPDATE :  91.43% done, estimate finish Thu Jan 31 14:59:48 2019
xorriso : UPDATE :  95.24% done
ISO image produced: 215040 sectors
Written to medium : 215040 sectors at LBA 0
Writing to 'stdio:/home/orchard/custom-cd/jessie/images/uxen-3.2.0-amd64-CD-1.iso' completed successfully.

일단은 완성은 된 모양인데 내 커스텀 커널을 잘 가져간건지 확인이 필요하다.

orchard@yb:/home$ sudo scp -P 42544 110.45.238.92:/home/orchard/custom-cd/jessie/images/uxen-3.2.0-amd64-CD-1.iso .
root@110.45.238.92's password:
uxen-3.2.0-amd64-CD-1.iso                                                          100%  420MB   5.2MB/s   01:21

만든 이미지를 내 로컬로 가지고 왔다.

또 부팅 USB를 만들어서 설치해보는건 너무 시간이 오래걸릴거 같다.

iso를 read-only로 마운트해서 안에 있는 패키지를 확인한다.

1. 새로만든 uxen3.2-iso

[iso 마운트]

root@yb:/home# mount -t iso9660 -o loop uxen-3.2.0-amd64-CD-1.iso /mnt

[풀에 있는 deb 확인]

root@yb:/mnt# cd pool/main/l/linux/
btrfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
crc-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
crypto-dm-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
crypto-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
efi-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
event-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
ext4-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
firewire-core-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
fuse-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
hyperv-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
i2c-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
jfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
linux-compiler-gcc-4.9-x86_3.16.59-1_amd64.deb
linux-headers-3.16.0-7-amd64_3.16.59-1_amd64.deb
linux-headers-3.16.0-7-common_3.16.59-1_amd64.deb
linux-image-3.16.0-7-amd64_3.16.59-1_amd64.deb
linux-libc-dev_3.16.59-1_amd64.deb
loop-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
md-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
mmc-core-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
multipath-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nbd-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-pcmcia-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-shared-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-usb-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-wireless-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
ntfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
pata-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
pcmcia-storage-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
ppp-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
scsi-extra-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
sound-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
squashfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
udf-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
uinput-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
virtio-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
xfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb

커널버전 3.16.0.7

2. 기존 uxen3.2-iso

[iso 마운트]

orchard@yb:~$ sudo mount -t iso9660 -o loop uxen-3.2.0-amd64-CD-1.iso /tmp
mount: /dev/loop1 is write-protected, mounting read-only

[풀에 있는 deb 확인]

orchard@yb:/tmp$ cd pool/main/l/linux/
btrfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
crc-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
crypto-dm-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
crypto-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
efi-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
event-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
ext4-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
firewire-core-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
fuse-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
hyperv-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
i2c-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
jfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
linux-compiler-gcc-4.9-x86_3.16.57-2_amd64.deb
linux-headers-3.16.0-6-amd64_3.16.57-2_amd64.deb
linux-headers-3.16.0-6-common_3.16.57-2_amd64.deb
linux-image-3.16.0-6-amd64_3.16.57-2_amd64.deb
linux-libc-dev_3.16.57-2_amd64.deb
loop-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
md-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
mmc-core-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
multipath-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nbd-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-pcmcia-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-shared-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-usb-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-wireless-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
ntfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
pata-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
pcmcia-storage-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
ppp-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
scsi-extra-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
sound-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
squashfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
udf-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
uinput-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
virtio-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
xfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb

커널버전 3.16.0.6

3. 결론

내가 만든 uxen3.2는 로컬 패키지에서 커널 패키지를 가져오지않고 원격 미러에서 가져왔다.

잘못만든 것이다. 어디서 잘못된걸까?

자꾸 뭔가 비교하여 이전과 다르니 넣을수 없다는 내용이 있어 전광석 연구원님께 문의해본 결과

“tmp파일에 캐시가 남아있어서” 그럴것 같다는 언질을 받을 수 있었다.

지우고 빌드를 시작했더니 일단 같은 오류는 발생하지 않는다. 그런데 빌드시간이 엄청 오래걸린다…

[ISO 생성2]

이제는 잘 생성될 것 이라고 믿고 만들어지면 풀확인 후에 부팅디스크로 만들어서 직접설치하고 드라이버를 확인하면 될것이다.

분명 잘 들어갔다는 로그를 확인했다.

/home/orchard/custom-cd/jessie/profiles/pengx3_localpkg/linux-image-3.16.0-6-amd64_3.16.57-2_amd64.deb: component guessed as 'main'
Skipping inclusion of 'linux-image-3.16.0-6-amd64' '3.16.57-2' in 'jessie|main|amd64', as it has already '3.16.57-2'.

이전 로그와는 확실히 상반되게 풀로 들어갔음을 알수있었다.

하지만 완성된 ISO에 접근하여 풀을 확인해보니 이전과 같이 3.16.0-7 커널을 받아왔다.

풀 확인.

root@yb:/mnt# cd pool/main/l/linux/
btrfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
crc-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
crypto-dm-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
crypto-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
efi-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
event-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
ext4-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
firewire-core-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
fuse-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
hyperv-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
i2c-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
jfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
linux-compiler-gcc-4.9-x86_3.16.59-1_amd64.deb
linux-headers-3.16.0-7-amd64_3.16.59-1_amd64.deb
linux-headers-3.16.0-7-common_3.16.59-1_amd64.deb
linux-image-3.16.0-7-amd64_3.16.59-1_amd64.deb
linux-libc-dev_3.16.59-1_amd64.deb
loop-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
md-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
mmc-core-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
multipath-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nbd-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-pcmcia-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-shared-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-usb-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
nic-wireless-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
ntfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
pata-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
pcmcia-storage-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
ppp-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
scsi-extra-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
sound-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
squashfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
udf-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
uinput-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
virtio-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb
xfs-modules-3.16.0-6-amd64-di_3.16.56-1+deb8u1_amd64.udeb

무엇이 문제일까?

“헤더등 다른 3.16.0-7 버전의 패키지와의 의존성때문에” 해당커널을 필수로 받아오는것은 아닌가

라는 추측을 기반으로 “3.16.0-7커널에 최신드라이버를 적용” 시켜 다시 빌드해보았다.

이전 글에 최신패칠가 적용된 uxenapi.deb를 만든적이 있다.

이 패키지도 추가하여 ISO를 만든다.

1. uxen3.conf 수정

orchard@customcd-jessie:~/custom-cd/jessie/profiles$ vi uxen3.conf
profiles="uxen3 uxenapi3"
locale="ko_KR"
keyboard="us"


debian_mirror="ftp://ftp.us.debian.org/debian/"
security_mirror="http://security.debian.org/"
mirror_components="main contrib non-free"


local_packages="$simple_cdd_dir/profiles/pengx3_localpkg/"
#all_extras="$all_extras \
# $simple_cdd_dir/profiles/pengx3_extras/RELEASE.rst"


export SPLASHPNG="$simple_cdd_dir/profiles/pengx3_localpkg/splash.png"
export CDNAME="uxen"
export DEBVERSION="3.2.1"
export ARCHES="amd64"

DEBVERSION을 3.2.1로 변경하였다.

2. pengx3_localpkg에 패키지 추가

orchard@customcd-jessie:~/custom-cd/jessie/profiles/pengx3_localpkg$ ls
libxen-4.6_4.6.0-1+nmu2_amd64.deb
libxen-dev_4.6.0-1+nmu2_amd64.deb
libxenstore3.0_4.6.0-1+nmu2_amd64.deb
linux-image-3.16.0-7-amd64_3.16.59-1_amd64.deb
pengxconf.deb
qemu-system-common_2.5+dfsg-5_amd64.deb
qemu-system-x86_2.5+dfsg-5_amd64.deb
qemu-utils_2.5+dfsg-5_amd64.deb
splash.png
uxenapi.deb
xen-hypervisor-4.6-amd64_4.6.0-1+nmu2_amd64.deb
xenstore-utils_4.6.0-1+nmu2_amd64.deb
xen-system-amd64_4.6.0-1+nmu2_amd64.deb
xen-utils-4.6_4.6.0-1+nmu2_amd64.deb
xen-utils-common_4.6.0-1+nmu2_all.de

최신 uxenapi.deb와 linux-image-3.16.0-7을 커스텀하여 추가했다.

3. ISO 빌드

orchard@customcd-jessie:~/custom-cd/jessie$ build-simple-cdd -p uxen3

4. 빌드된 이미지로 UXEN설치 및 확인.

드라이버 확인.

root@test:~# modinfo i40e
filename:       /lib/modules/3.16.0-6-amd64/updates/drivers/net/ethernet/intel/i40e/i40e.ko
version:        2.7.29
license:        GPL
description:    Intel(R) 40-10 Gigabit Ethernet Connection Network Driver
author:         Intel Corporation, <e1000-devel@lists.sourceforge.net>
srcversion:     2212C8D31172FBDBC9A1647
alias:          pci:v00008086d0000158Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000158Asv*sd*bc*sc*i*
alias:          pci:v00008086d000037D3sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D2sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D1sv*sd*bc*sc*i*
alias:          pci:v00008086d000037D0sv*sd*bc*sc*i*
alias:          pci:v00008086d000037CFsv*sd*bc*sc*i*
alias:          pci:v00008086d000037CEsv*sd*bc*sc*i*
alias:          pci:v00008086d00001588sv*sd*bc*sc*i*
alias:          pci:v00008086d00001587sv*sd*bc*sc*i*
alias:          pci:v00008086d000015FFsv*sd*bc*sc*i*
alias:          pci:v00008086d00001589sv*sd*bc*sc*i*
alias:          pci:v00008086d00001586sv*sd*bc*sc*i*
alias:          pci:v00008086d00001585sv*sd*bc*sc*i*
alias:          pci:v00008086d00001584sv*sd*bc*sc*i*
alias:          pci:v00008086d00001583sv*sd*bc*sc*i*
alias:          pci:v00008086d00001581sv*sd*bc*sc*i*
alias:          pci:v00008086d00001580sv*sd*bc*sc*i*
alias:          pci:v00008086d00001574sv*sd*bc*sc*i*
alias:          pci:v00008086d00001572sv*sd*bc*sc*i*
depends:        ptp,vxlan
retpoline:      Y
vermagic:       3.16.0-6-amd64 SMP mod_unload modversions
parm:           debug:Debug level (0=none,...,16=all) (int)

완료

]]>
Wed, 30 Jan 2019 00:00:00 +0900
http://www.iorchard.net/2019/01/15/zabbix_support_for_mdadm.html http://www.iorchard.net/2019/01/15/zabbix_support_for_mdadm.html <![CDATA[Zabbix support for mdadm]]> Zabbix support for mdadm

개요

최근 curry의 디스크 불량으로 디스크를 교체했다.

mdraid1 으로 구성되어 있어 데이터의 손실은 없었다.

디스크 고장을 수동으로 발견하여, 조치하였지만 이에대한 방지대책이 필요하다.

생각

mdraid에 대한 모니터링이 필요하다고 생각한다.

방법은 두가지로 간추렸다.

  1. zabbix 템플릿 추가하기.
  2. mdadm 에 내장된 Email-alert 기능 사용하기.

1번으로 진행하기로 하였다.

이유는 우리는 Zabbix 모니터링 서버를 운영하므로 Zabbix가 모니터링 하는게 낫다고 생각하였다.

만약 2번으로 진행하게 된다면 mail alerting을 위해 25번 포트를 열어야 하며 MUA(Mail User Agent), MTA(Mail Trasport Agent)가 필요하기 때문에 추가적인 패키지 설치가 필요하다. 때문에 1번으로 진행하는게 낫다고 생각하였다.

Zabbix용 mdraid 모니터링 템플릿?

zabbix용 mdraid 템플릿에서 지원하는 모니터링 기능은 아래와 같다. * md.discover - LLD(Low Level Discovery) 데이터 (MD RAID 및 디스크) 감지 * md.degraded [*] - 특정 RAID에 대한 성능이 저하 된 디스크 수 * md.sync_action [*] - 특정 RAID의 현재 동기화 상태 * md.raid_disks [*] - 특정 RAID에 대한 모든 디스크 수

Reference

Zabbix 템플릿 적용

mdraid 모니터링 템플릿을 적용하기 위해 Zabbix Client/Zabbix Server 설정을 나누어 기록한다.

Zabbix Client 설정

root@mdadm:~# curl -Ls https://git.io/fN9H5 | sudo tee /etc/zabbix/zabbix_agentd.conf.d/userparameter_md.conf
UserParameter=md.discover,ls /sys/class/block | awk 'BEGIN{printf "{\"data\":["}; /^md[0-9]+$/ {printf c"{\"{#MDNAME}\":\""$1"\"}";c=","}; END{print "]}"}'
UserParameter=md.degraded[*],cat /sys/block/$1/md/degraded
UserParameter=md.sync_action[*],cat /sys/block/$1/md/sync_action
UserParameter=md.raid_disks[*],cat /sys/block/$1/md/raid_disks

root@mdadm:~# /etc/init.d/zabbix-agent restart
[ ok ] Restarting zabbix-agent (via systemctl): zabbix-agent.service.

Zabbix Server 설정

템플릿 파일을 내 로컬PC에 저장하기 위해 git clone하였다.:

gwangseok@gwangbian:~$ git clone https://github.com/krom/zabbix_template_md.git

프로젝트 디렉토리를 살펴보자.:

gwangseok@gwangbian:~$ ls -l zabbix_template_md/
합계 92
-rw-r--r-- 1 gwangseok gwangseok 35141  1월 16 13:09 LICENSE
-rw-r--r-- 1 gwangseok gwangseok   990  1월 16 13:09 Makefile
-rw-r--r-- 1 gwangseok gwangseok  1993  1월 16 13:09 README.md
drwxr-xr-x 2 gwangseok gwangseok   108  1월 16 13:09 dist
-rw-r--r-- 1 gwangseok gwangseok 12108  1월 16 13:09 template_md_2.0.xml
-rw-r--r-- 1 gwangseok gwangseok 12595  1월 16 13:09 template_md_2.4.xml
-rw-r--r-- 1 gwangseok gwangseok 12783  1월 16 13:09 template_md_3.0.xml
-rw-r--r-- 1 gwangseok gwangseok   343  1월 16 13:09 userparameter_md.conf
  • 우리 Zabbix는 3.2버전 이므로 내가 필요한 파일은 template_md_3.0.xml 이다.

이제 zabbix 웹페이지로 접속하여 admin으로 로그인한다.

  • 상단메뉴의 Configuration -> Templates 를 클릭한다.
  • 상단 우측 메뉴의 Import를 클릭한다.
  • 파일선택 -> 홈-> zabbix_template_md -> template_md_3.0.xml을 선택한다.
  • Import를 클릭한다. 이렇게 하면 MD-RAID 모니터링을 위한 템플릿이 추가된 것이다.

이제 MD-RAID 템플릿을 특정 호스트(나의경우 mdadm)에게 적용해보자. * 상단메뉴의 Configuration -> Host 클릭 * mdadm 클릭 -> Templates 로 이동 * Select -> Template MD Soft RAID 클릭 -> Add -> Update

이렇게 하면 zabbix서버가 mdadm호스트의 MD_RAID장치 모니터링을 시작한다.

검증

mdadm의 레이드 디스크 중 하나를 detact 하여 zabbix가 이를 감지하는지 확인한다.

(in jennings).:

root@jennings:~# xl block-detach 29 xvdc
libxl: error: libxl_device.c:952:device_backend_callback: unable to remove device with path /local/domain/0/backend/qdisk/29/51744
libxl: error: libxl.c:1995:device_addrm_aocomplete: unable to remove vbd with id 51744
libxl_device_disk_remove failed.
  • block detach에 실패하였다.

xenstore 장치를 확인하였다.:

root@jennings:~# xenstore-ls /local/domain/29/device/vbd
51712 = ""
 backend = "/local/domain/0/backend/qdisk/29/51712"
 backend-id = "0"
 state = "4"
 virtual-device = "51712"
 device-type = "disk"
 ring-ref = "9"
 event-channel = "18"
 protocol = "x86_64-abi"
 feature-persistent = "1"
51728 = ""
 backend = "/local/domain/0/backend/qdisk/29/51728"
 backend-id = "0"
 state = "4"
 virtual-device = "51728"
 device-type = "disk"
 ring-ref = "364"
 event-channel = "21"
 protocol = "x86_64-abi"
 feature-persistent = "1"
  • xvdc가 detach되었다.

xl list –long으로 확인하였다.:

root@jennings:~# xl list -l 29 |less
...
"disks": [
{
    "pdev_path": "/localdisk/96c9d35a-9db9-4899-9594-76dfde0c42bf",
    "vdev": "xvda",
    "format": "qcow2",
    "readwrite": 1
},
{
    "pdev_path": "/localdisk/d964b17b-87f1-4f7b-8750-326c819cc66e",
    "vdev": "xvdb",
    "format": "qcow2",
    "readwrite": 1
  • xvdc가 detach되었다. 그럼 왜 xl은 실패 로그를 띄웠을까..

(in mdadm) VM에서 확인하였다.:

root@mdadm:~# fdisk -l

Disk /dev/xvda: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc3617af3

Device     Boot   Start      End  Sectors  Size Id Type
/dev/xvda1         2048  1953791  1951744  953M 82 Linux swap / Solaris
/dev/xvda2 *    1953792 21485567 19531776  9.3G 83 Linux

Disk /dev/xvdb: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x820dbc44

Device     Boot Start      End  Sectors Size Id Type
/dev/xvdb1       2048 20971519 20969472  10G fd Linux raid autodetect

Disk /dev/md0: 10 GiB, 10727981056 bytes, 20953088 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

root@mdadm:~# dmesg |tail -n 3
[72695.244176] vbd vbd-51744: 16 Device in use; refusing to close
[72695.245583] vbd vbd-51744: failed to write error node for device/vbd/51744 (16 Device in use; refusing to close)
[72705.258492] block xvdc: device/vbd/51744 was hot-unplugged, 1 stale handles
  • VM에서도 xvdc가 detach되었다.

RAID 상태를 보았다.:

root@mdadm:~# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 xvdc1[1] xvdb1[0]
      10476544 blocks super 1.2 [2/2] [UU]

unused devices: <none>
  • mdstat에는 여전히 xvdc가 존재하는 것으로 본다.
  • block-detach가 문제가 있는 것 같다.
  • xen을 통하지 않고 미러 디스크 중 하나의 디스크만 장착한 상태로 부팅하자.

미러 디스크 2개중 하나의 디스크만 장착한 상태로 부팅하였다.:

root@mdadm:~# cat /proc/mdstat
Personalities : [raid1]
md0 : active (auto-read-only) raid1 xvdb1[0]
      10476544 blocks super 1.2 [2/1] [U_]

unused devices: <none>

Zbbix서버에서 확인 결과 Issue에 아래와 같이 잘 감지한다.:

mdadm-test  MD md0 is degraded on mdadm-test    2019-01-16 23:13:51 1m 21s      No
  • 모니터링이 잘 된다.
]]>
Tue, 15 Jan 2019 00:00:00 +0900
http://www.iorchard.net/2019/01/10/resize_disk_partition.html http://www.iorchard.net/2019/01/10/resize_disk_partition.html <![CDATA[Resize Disk Partition]]> Resize Disk Partition

디스크 파티션 크기 늘리기.

[개요]

VM의 OS파티션이 10G인 VM이 있다. 이 VM의 qcow2이미지는 30G이다.

os파티션의 크기를 30G로 늘리고 싶다면 어떻게 해야할까.

먼저 해당 VM을 종료한다.

root@thomas:/home/orchard# xl list
Name                                        ID   Mem VCPUs  State   Time(s)
Domain-0                                     0  4071     2     r-----  573560.3
nextmkt-apm                                 23  1024     1     -b----   42417.3
ppms                                        26  5109     8     -b----  704284.1
tinydns                                     28  1019     2     -b----   35981.9
wingwings                                   30  1020     1     -b----   40479.9
odom                                       527  2048     2     -b----  230738.5
asp                                        528  2044     2     -b----  296544.6
youjin1                                    529  4092     8     r-----  841041.0
swrc                                       535  7168     8     r-----  2537291.7
pm                                         538  2048     2     -b----      84.5

root@thomas:/home/orchard# xl shutdown 538

디스크에 접근

root@thomas:/data/domu# qemu-nbd -c /dev/nbd0 pm.qcow2
Failed to open /dev/nbd0: No such file or directory
/build/qemu-1000/qemu-2.5+dfsg/nbd.c:nbd_receive_request():L857: read failed

실패. 모듈 업로드 후 다시 접근

root@thomas:/data/domu# modprobe nbd
root@thomas:/data/domu# lsmod |grep nbd
nbd                    16851  0
root@thomas:/data/domu# qemu-nbd -c /dev/nbd0 pm.qcow2

성공

Disk /dev/nbd0: 30 GiB, 32212254720 bytes, 62914560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5d03c8ba

Device      Boot   Start      End  Sectors  Size Id Type
/dev/nbd0p1         2048  1953791  1951744  953M 82 Linux swap / Solaris
/dev/nbd0p2 *    1953792 21485567 19531776  9.3G 83 Linux

파티트 명령어로 파티션 리사이즈

root@thomas:/data/domu# parted /dev/nbd0
GNU Parted 3.2
Using /dev/nbd0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Unknown (unknown)
Disk /dev/nbd0: 32.2GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  1000MB  999MB   primary  linux-swap(v1)
 2      1000MB  11.0GB  10.0GB  primary  ext4            boot
(parted) resize 2
Error: The resize command has been removed in parted 3.0
????

(parted) resizepart 2
End?  [11.0GB]? 32.2GB

(parted) p
Model: Unknown (unknown)
Disk /dev/nbd0: 32.2GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  1000MB  999MB   primary  linux-swap(v1)
 2      1000MB  32.2GB  31.2GB  primary  ext4            boot

resize명령어가 3.0 버전 부터는 없어졌음에 주의.

파티션 테이블 매핑.

root@thomas:/dev# kpartx -dv /dev/nbd0

리사이즈 명령어로 늘린 부분에 파일시스템 적용.

root@thomas:/data/domu# resize2fs /dev/mapper/nbd0p2
resize2fs 1.42.12 (29-Aug-2014)
resize2fs: Filesystem has unsupported read-only feature(s) while trying to open /dev/mapper/nbd0p2
Couldn't find valid filesystem superblock.

알수없는 오류 발생.

마운트를 시켜주고 해당 명령어를 실행

root@thomas:/dev# mount /dev/mapper/nbd0p2 /mnt

root@thomas:/dev# resize2fs /dev/mapper/nbd0p2
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/mapper/nbd0p2 is mounted on /mnt; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 4
The filesystem on /dev/mapper/nbd0p2 is now 7617104 (4k) blocks long.

용량 확인.

root@thomas:/dev# df -h
Filesystem          Size  Used Avail Use% Mounted on
/dev/md0            146G  3.9G  135G   3% /
udev                 10M     0   10M   0% /dev
tmpfs               790M   82M  708M  11% /run
tmpfs               2.0G     0  2.0G   0% /dev/shm
tmpfs               5.0M     0  5.0M   0% /run/lock
tmpfs               2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/md127          3.7T  1.3T  2.4T  35% /data
/dev/mapper/nbd0p2   29G 1023M   27G   4% /mnt

디스크 해제.

root@thomas:/dev# umount /mnt
root@thomas:/dev# kpartx -dv /dev/ndb0
failed to stat() /dev/ndb0
root@thomas:/dev# kpartx -dv /dev/nbd0
del devmap : nbd0p2
del devmap : nbd0p1
root@thomas:/dev# qemu-nbd -d /dev/nbd0
/dev/nbd0 disconnected

해당 vm실행.

root@thomas:/data/config.bak/config.new# xl create pm.cfg
Parsing config from pm.cfg

접속 후 디스크 용량 확인.

dev/mapper/nbd0p2   29G 1023M   27G   4% /mnt
root@pm:/home/orchard# fdisk -l
Disk /dev/xvda: 30 GiB, 32212254720 bytes, 62914560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5d03c8ba

Device     Boot   Start      End  Sectors  Size Id Type
/dev/xvda1         2048  1953791  1951744  953M 82 Linux swap / Solaris
/dev/xvda2 *    1953792 62890625 60936834 29.1G 83 Linux

정상적으로 29기가 확장 확인.

완료.

]]>
Thu, 10 Jan 2019 00:00:00 +0900
http://www.iorchard.net/2019/01/04/zabbix와_telegram_연동.html http://www.iorchard.net/2019/01/04/zabbix와_telegram_연동.html <![CDATA[zabbix와 telegram 연동]]> zabbix와 telegram 연동

zabbix가 보낸 메일을 좀 더 빠르게 확인을 하기위해

zabbix와 telegram을 연동해보려고 한다.

1. 시나리오

서초 IDC에 있는 zabbix-server와 똑같이 VM을 하나 생성 하고

zabbix-server를 똑같은 버전으로 설치한다.

그리고 agent로 내부 서버를 추가하고

zabbix와 telegram을 연동 설정을 한다.

그리고 test를 진행한다.

agent에서 disk 사용량 문제를 발생하여 경고메일을 보낼때

telegram에도 문자를 보내는지 확인한다.

문자를 받으면 성공

문자를 성공적으로 받으면 서초에 있는 zabbix-server에 똑같이 적용한다.

그리고

2. zabbix test서버 구성

일단 zabbix test서버를 구성해보자.

기존 서버와 비슷하게 구성하겠다.

debian_version = 8.6
zabbix_version = 3.2.4
cpu = 1
ram = 1
disk = 1G : swap
      10G : /
       9G : 나머지
network = xenbr0 : 192.168.0.246 (외부)
          xenbr1 : 10.0.0.246 (내부,zabbix)
hostname = zabbix

vm 설치를 완료하였으면

zabbix를 설치해보자.

패키지 파일은

https://repo.zabbix.com/zabbix/

위 사이트에서 다운받을 수 있다.

3.2.4버전을 찾을 수 없어서

3.2-1 버전을 설치하도록 하겠다.

1 - deb패키지 다운로드
zabbix:~$ sudo wget --no-check-certificate https://repo.zabbix.com/zabbix/3.2/debian/pool/main/z/zabbix-release/zabbix-release_3.2-1%2Bjessie_all.deb

2 - deb패키지 설치
zabbix:~$ sudo dpkg -i zabbix-release_3.2-1+jessie_all.deb

3 - deb패키지 설치 확인
zabbix:~$ dpkg -l |grep zabbix
ii  zabbix-release     3.2-1+jessie      all      Zabbix official repository configuration

4 - zabbix 서버 설치
zabbix:~$ sudo apt update
zabbix:~$ sudo apt install zabbix-server-mysql zabbix-frontend-php zabbix-agent
* 설치 중간에 zabbix DB password 설정이 나온다
* 나는 사내 패스워드로 등록

5 - DB 생성
zabbix:~$ mysql -uroot -p
Enter password: 설정한 패스워드
mysql> create database zabbix character set utf8 collate utf8_bin;
Query OK, 1 row affected (0.00 sec)
mysql> grant all privileges on zabbix.* to zabbix@localhost identified by '패스워드 설정';
Query OK, 0 rows affected (0.00 sec)
mysql> quit;
Bye

6 - 초기 스키마와 데이터 가져오기
zabbix:~$ zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix

위 방법이 안된다면 다른 방법을 쓴다.
zabbix:~$ cd /usr/share/zabbix-server-mysql/
zabbix:/usr/share/zabbix-server-mysql$ ls
data.sql.gz  images.sql.gz  schema.sql.gz  zabbix_server.conf

data.sql.gz  images.sql.gz  schema.sql.gz 3개의 파일로 설정을 해주자.
zcat ./schema.sql.gz | mysql -uzabbix -p zabbix
zcat ./images.sql.gz | mysql -uzabbix -p zabbix
zcat ./data.sql.gz | mysql -uzabbix -p zabbix


7 - zabbix server 파일 편집
zabbix:~$ sudo vi /etc/zabbix/zabbix_server.conf
DBPassword='설정 패스워드 입력'

8 - zabbix 시작
zabbix:~$ sudo systemctl start zabbix-server zabbix-agent
zabbix:/$ sudo systemctl enable zabbix-server zabbix-agent

9 - zabbix 확인
zabbix:/$ sudo ss -nltp |grep zabbix
LISTEN     0      128                       *:10050                    *:*      users:(("zabbix_agentd",pid=10852,fd=5),("zabbix_agentd",pid=10851,fd=5),("zabbix_agentd",pid=10850,fd=5),("zabbix_agentd",pid=10849,fd=5),("zabbix_agentd",pid=10848,fd=5),("zabbix_agentd",pid=10846,fd=5))
LISTEN     0      128                      :::10050                   :::*      users:(("zabbix_agentd",pid=10852,fd=6),("zabbix_agentd",pid=10851,fd=6),("zabbix_agentd",pid=10850,fd=6),("zabbix_agentd",pid=10849,fd=6),("zabbix_agentd",pid=10848,fd=6),("zabbix_agentd",pid=10846,fd=6))

10 - PHP 설정
zabbix:~$ sudo vi /etc/zabbix/apache.conf
# php_value date.timezone Europe/Riga
php_value date.timezone Asia/Seoul     <--- 추가

11 - 아파치 시작
zabbix:~$ sudo systemctl start apache2
zabbix:~$ sudo systemctl enable apache2

apache 시작까지 하면 모든 작업이 완료되었다.

이제 zabbix frontend로 접속해보자.

http://server ip//zabbix

접속하면 zabbix 웹 페이지가 뜬다.

next를 누르면 다음 화면으로 넘어간다.

../../../_images/2.png

/etc/zabbix/apache.conf 설정이 잘 됐는지 확인하는 창인것 같다.

위에 10번 PHP 설정을 안하면 date관련 오류가 하나 발생한다.

오류가 없으면 next

../../../_images/3.png

DB설정하는 창이다.

따로 password만 입력해주고 넘어가자.

../../../_images/4.png

name만 zabbix로 입력해주고 넘어가자.

../../../_images/5.png

지금까지 구성한 설정을 보여준다.

확인 후 next

../../../_images/6.png

설치완료!!!

finish를 누르면 로그인창으로 넘어간다.

../../../_images/7.png

기본 ID : Admin PW: zabbix

A를 대문자로 해야한다 안그럼 로그인 실패!

../../../_images/8.png

접속까지 완료!

3. zabbix agent설정

server를 설치했으니 관리할 대상 서버가 필요하다.

설정을 해보자.

agent는 기존에 있던 VM으로 하겠다.

agent 설치부터 해보자.

~$ sudo apt install zabbix-agent

설치 후 이제 설정파일을 수정해보자.

~$ sudo vi /etc/zabbix/zabbix_agentd.conf
Server=192.168.0.246 <-- zabbix 서버 IP

이제 zabbix와 telegram연동을 해보자!

참조

https://www.zabbix.com/download?zabbix=3.0&os_distribution=debian&os_version=jessie&db=MySQL

https://www.zabbix.com/documentation/3.0/manual/installation/install#installing_frontend

4. telegram bot 생성 및 설정

https://github.com/ableev/Zabbix-in-Telegram

위 github를 참조해서 연동하도록 하겠다.

1) pip 설치

python pip를 설치해자.

# sudo apt install python-pip

2) pip upgrade

pip upgrade를 하자.

# sudo pip install --upgrade pip

3) requsets 설치

requsets를 설치하자.

# sudo pip install requests

4) zabbix_server.conf 파일에 alertscript 경로 설정

zabbix_server.conf 파일에 alertscript 경로 설정을 해주자.

# sudo vi /etc/zabbix/zabbix_server.conf

AlertScriptsPath=/etc/zabbix/bin
- 경로는 아무대나 지정해줘도 상관이 없다.

5) telegram bot 설정

이제 텔레그램을 켜서 botfather를 대화상대로 찾자.

  • 외쪽 상단의 메뉴 > Contacts > botfather 검색
../../../_images/17.png

대화를 시작하면 하단에 start가 보인다. 눌러주자.

../../../_images/18.png

start를 누르면 채팅창이 뜬다.

거기서 /newbot을 클릭해주자.

../../../_images/19.png

사용할 봇의 이름을 적어주면 된다. ( 끝에 bot만 들어가면 된다 )

그러면 토큰을 받을 수 있다.

그 토큰을 다른데다 저장해 놓자.

../../../_images/20.png

이제 인터넷 주소창에 다음과 같은 형식으로 들어가보자.

https://api.telegram.org/< bot에게 받은 token >/getUpdates

예제 : https://api.telegram.org/bot737469595:AAHh0rOzGn0CEmhjB3vE405Kxa2BmhYAghg/getUpdates

그러면 다음과 같은 메시지를 가진 페이지로 넘어간다.

../../../_images/21.png

6) zabbix user생성

zabbix user를 생성해주자.

../../../_images/22.png

Administrator > Users > create User

유저는 test용이기 때문에 간단하게 만든다.

../../../_images/23.png

7) zbxtg 스크립트 다운 및 설정

zbxtg 스크립트를 다운받아야 한다.

https://github.com/ableev/Zabbix-in-Telegram 가면 받을 수 있다.

다운받고 아까 alertscript경로로 지정한

/etc/zabbix/bin에 넣는다.

그리고 zbxtg_setting.example.py의 이름을 zbxtg_setting.py로 변경하고

vi를 이용하여 열어준다.

# mv zbxtg_setting.example.py zbxtg_settings.py
# vi zbxtg_settings.py

telegram bot token설정
- tg_key = "XYZ"
+ tg_key = "799857259:AAG9WaApwtBiIPqq-nQFSLsuIMGg-XXmGkM"

zabbix server설정
- zbx_server = "http://127.0.0.1/zabbix/"
+ zbx_server = "http://192.168.0.246/zabbix/"

zabbix user 설정
- zbx_api_user = "api"
- zbx_api_pass = "api"
+ zbx_api_user = "test"
+ zbx_api_pass = "123"

저장

8) bot 작동 확인

위에 설정을 다 마쳤으면 이제 bot이 제대로 작동을 하는지 확인을 해보자.

/etc/zabbix/bin/zbxtg.py "binogood" "hello" "how are you?"
- binogood : telegram username ( 만드는  : settings > Edit profile > add username )

오류1
만약에 아래와 같은 에러가 발생하다면 zbxtg_settings의 이름이 제대로 되어있는지 확인해라.
Traceback (most recent call last):
  File "/etc/zabbix/bin/zbxtg.py", line 17, in <module>
    import zbxtg_settings
ImportError: No module named zbxtg_settings

오류2
No such file or directory 오류가 발생한다면
zbxtg.py파일을 열어서
:set fileformat:unix  <---  명령어로 파일의 포맷을 변경해줘라.

위 명령어를 입력하면

zbxtg.py: User 'binogood' needs to send some text bot in private

와 같은 에러를 출력한다.

그러면 telegram을 열고 아까 봇으로 만들었던 telegram bot을 찾아본다.

../../../_images/24.png

start 클릭

../../../_images/25.png

그리고 다시 한번 입력하면!!

../../../_images/26.png

나한테 쪽지가 온다.

성공이다.

이제 zabbix에 연동시켜보자.

5. zabbix, telegram 연동

1) media type생성

media type란 ?

어떻게 알람을 받을 것인지 설정하는 것이다.

Email,SMS,script등 다양하게 선택이 가능하다.

Administration > Media types 탭으로 가면 생성이 가능하다.

../../../_images/12.png

Create media type를 눌러서 생성을 해보자.

../../../_images/13.png

위 와 같이 설정하였다.

그리고 저장

2) media type설정

설정하는 법은 간단하다.

../../../_images/27.png ../../../_images/28.png

Adminstrator > Users > admin > Media로 들어가서 추가해주면 된다.

../../../_images/29.png

3) action 생성

Configuration > Action을 누르면 Action을 생성이 가능하다.

../../../_images/15.png

오른쪽 상단에 Create action을 눌러 Action을 생성해보자.

지금 부터 조금 복잡하다 잘 따라와야 한다.

../../../_images/30.png ../../../_images/31.png

그리고 하단에 select을 누른다.

hostname이 바뀌면 알려주는 트리거이다.

이제 Operations로 넘어가서

../../../_images/32.png ../../../_images/33.png

다 했으면 Recorvery operations로 넘어가자

../../../_images/34.png ../../../_images/35.png

Default message 부분이다.

Last value:{ITEM.LASTVALUE1} ({TIME})
zbxtg;graphs
zbxtg;graphs_period=10800
zbxtg;itemid:{ITEM.ID1}
zbxtg;title:{HOST.HOST} - {TRIGGER.NAME}

다 설정을 하였으면 add를 눌러서 생성을 해주자.

../../../_images/36.png

그럼 생성이 된 것을 확인이 가능하다.

좀 더 빨리 확인을 하기위해 몇가지 설정을 해보자.

../../../_images/38.png ../../../_images/39.png ../../../_images/40.png ../../../_images/41.png ../../../_images/42.png ../../../_images/43.png

위 설정을 마치면…

../../../_images/37.png

telegram으로 메시지가 온다!

완료!

6. zabbix-server에 적용

이제 우리가 사용하는 zabbix 서버에 적용을 시켜보자.

1) 설치 전 확인

먼저 패키지를 확인해보자.

zabbix-server:/# pip freeze
requests==2.18.4

패키지는 설치되어 있다.

2) script 가져오기

이제 script를 가져오자.

zabbix:/usr/lib/zabbix/alertscripts$ sudo scp -P42544 zbxtg* orchard@zabbix-server.iorchard.co.kr:~orchard/
zbxtg.py                                      100%   36KB  36.5KB/s   00:00
zbxtg_settings.py                             100% 1916     1.9KB/s   00:00

가져왔으면 /usr/lib/zabbix/alertscripts에 넣어주자.

mv zbxtg* /usr/lib/zabbix/alertscripts/

3) bot 생성

이제 봇을 생성하고!

../../../_images/44.png

zbxtg_settings.py 설정을 해보자.

tg_key = "771295100:AAEpdlS90krA3B3YatS6f83zRZI4p3KjSSo"
zbx_server = "zabbix-server.iorchard.co.kr/zabbix"
zbx_api_user = "api"
zbx_api_pass = "api"

위 설정을 했으면 이제 test를 해보자.

./zbxtg.py "binogood" "Hello" "How are you?"
../../../_images/45.png

잘 된다.

이제 zabbix에서 설정을 해보자.

4) media 생성

telegram에 대한 media를 생성하자.

../../../_images/46.png

다 했으면 저장

5) action 생성

action을 생성하자

../../../_images/47.png ../../../_images/48.png ../../../_images/49.png

6) admin 계정에 적용

이제 만든 media를 admin 계정에 적용시키자.

../../../_images/50.png

7) test

마지막으로 test를 진행해보자.

gitlab VM의 zabbix-agent를 내리고 기다려보자.

../../../_images/51.png

잘 된다.

good!

]]>
Fri, 04 Jan 2019 00:00:00 +0900
http://www.iorchard.net/2018/05/04/궁합이_좋지_않은_centos_7과_xen.html http://www.iorchard.net/2018/05/04/궁합이_좋지_않은_centos_7과_xen.html <![CDATA[궁합이 좋지 않은 CentOS 7과 Xen]]> 궁합이 좋지 않은 CentOS 7과 Xen

서초 UCloud에서 기술지원 요청이 왔다. DomU CentOS 7 커널을 최신으로 업데이트 하니 부팅이 안된다고 한다.

Xen과 CentOS 7 커널간 무슨 문제가 발생한 걸까?

실험 서버

  • Hardware

    • Vendor: Dell

    • Model: PowerEdge R730

    • CPU model: Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz

    • CPUs: 6 cores * 2 sockets * HT = 24 cores

    • RAM:

    • RAID: MegaRAID SAS-3 3108

    • HDD: 600GB 15k rpm SAS Disk (found out using smartmontools)

      $sudo smartctl -i /dev/sda -d megaraid,0
      smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build)
      Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
      
      === START OF INFORMATION SECTION ===
      Vendor:               SEAGATE
      Product:              ST600MP0005
      Revision:             VT31
      Compliance:           SPC-4
      User Capacity:        600,127,266,816 bytes [600 GB]
      Logical block size:   512 bytes
      Formatted with type 2 protection
      LB provisioning type: unreported, LBPME=0, LBPRZ=0
      Rotation Rate:        15000 rpm
      Form Factor:          2.5 inches
      Logical Unit id:      0x5000c5008eb88c07
      Serial number:        S7M0JDDF
      Device type:          disk
      Transport protocol:   SAS (SPL-3)
      Local Time is:        Sat May  5 20:25:37 2018 KST
      SMART support is:     Available - device has SMART capability.
      SMART support is:     Enabled
      Temperature Warning:  Disabled or Not Supported
      
  • Xen Dom0

    • hostname: orchard (별로 좋지 않은 호스트명, 사용자명과 혼동된다.)
    • IP: 117.52.152.103
  • CentOS 7 DomU

    • hostname: localhost (내가 아주 싫어하는 호스트명)
    • IP: 117.52.152.104

증상

CentOS 7.2를 iso로 설치하여 부팅하면 문제없이 부팅이 된다. 이 때 커널 버전은 3.10.0-327.el7.x86_64.

yum install kernel 하여 최신 커널로 업그레이드한 후 리부팅하면 grub 화면에서 5초가 흐른 후 검은 화면이 나오고 부팅이 진행되지 않는다.

최신 커널 버전은 3.10.0-693.21.1.el7.x86_64.

직원 말로는 우리 회사 실험 서버(사실 PC)에서는 최신 커널에서도 부팅이 잘 된다고 한다. 그렇다면 서초 UCloud에 있는 서버 하드웨어와의 문제라고 할 수 있다.

실험 1. 문제 확인

grub에서 rhgb와 quiet 옵션을 제거하고 커널 부트 로그를 보자.

grub 화면에서 해당 커널을 선택한 후 e 를 치면 inline edit mode가 된다. kernel line에서 rhgb와 quiet을 삭제하고 Ctrl-x 를 눌러 부팅을 진행한다. 커널 부트 로그가 다음 그림처럼 나온다.

../../../_images/centos7_domu_boot_stop.png

실험 2. 작동 커널을 찾아서

최신 커널이 문제가 있으니 바로 이전 커널도 같은 문제가 있는 지 확인하자.

http://rpmfind.net/ 에서 kernel을 검색해 보니 최신 커널 3.10.0-693.21.1.el7.x86_64 바로 전 커널 패키지는

3.10.0-693.17.1.el7.x86_64 이다.

이 커널을 설치하여 부팅해 보자.

$ wget http://rpmfind.net/linux/centos/7.4.1708/updates/x86_64/Packages/kernel-3.10.0-693.17.1.el7.x86_64.rpm

$ sudo rpm -Uvh kernel-3.10.0-693.17.1.el7.x86_64.rpm

이제 3.10.0-693.17.1.el7.x86_64로 부팅해 보니 잘 부팅된다.

그렇다면 최신 3.10.0-693.21.1.el7.x86_64과 이전 패키지 간 이 서버에 대해 문제가 있다는 것이다.

실험 3. ACPI, APIC 커널 옵션

위 실험 1. 문제 확인에서 보면 마지막 커널 로그 메세지가 ACPI 관현 메세지였다. 그래서 CentOS 7 최신 커널에서 현 서버의 ACPI 시스템과 문제가 있는 건 아닌지 의심스러웠다. grub 커널 옵션에서 acpi를 꺼볼까?

CentOS 7에서의 grub 커널 옵션 변경법은 다음과 같다.

#. /etc/default/grub파일을 편집한다.

$ sudo vi /etc/default/grub
...
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet"
...

위 GRUB_CMDLINE_LINUX에 원하는 커널 옵션을 추가한다.

#. grub.cfg파일을 생성한다.

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

ACPI 관련해서 3개의 커널 옵션이 있다.

  • acpi=off
  • noapic
  • nolapic

각각의 의미를 살펴보자.

acpi=off

ACPI는 Advanced Configuration and Power Interface의 약자로 번역하면 “고급 구성 및 전원 인터페이스”이다.

ACPI위키백과 에 의하면 1996월 12월 공개된 표준으로 하드웨어 감지, 메인보드 및 장치 구성, 전원 관리를 담당하는 일반적인 인터페이스를 정의한단다.

예를 들면 ACPI가 enable된 시스템에서는 리눅스에서 poweroff 또는 shutdown 명령으로 종료하면 ACPI가 시스템 전원을 종료한다. ACPI를 disable하면 리눅스가 종료되어도 시스템 전원은 꺼지지 않는다. 수동으로 전원버튼을 눌러 꺼야 한다.

커널 옵션에 acpi=off를 주면 ACPI기능을 사용하지 않겠다는 것이다.

noapic/nolapic

APIC은 Advanced Programmable Interrupt Controller의 약자로 번역하면 “고급 프로그램가능한 인터럽트 제어기” 아~~ 번역이 이상하다.

역시 APIC위키백과 에 의하면 더 많은 출력, 더 복잡한 우선 순위 계획, 고급 IRQ 관리를 한다고 한다.

APIC은 split architecture design(Local and System bus IO)으로 LAPIC(Local APIC)은 CPU에 통합되어 있고 시스템 버스에 IOAPIC은 선택사항이다.

noapic 옵션은 시스템 버스의 IOAPIC을 disable한다는 것이다.

nolapic 옵션은 CPU의 LAPIC을 disable한다는 것이다.

각 옵션을 켜고 끄면서 부팅이 되는 지 실험해 보았다.

options Boot OK
acpi=off NO
noapic NO
nolapic YES

acpi=off와 noapic 옵션은 각각 따로 설정해도 또는 함께 설정해도 부팅에 실패했다. nolapic 옵션은 다른 옵션없이 이 옵션만 설정해도 부팅에 성공했다.

안 되는 것과 되는 것 비교

dmesg를 비교해 보았다.

[    0.096000] pinctrl core: initialized pinctrl subsystem
[    0.097000] RTC time: 18:26:10, date: 05/05/18
[    0.098000] NET: Registered protocol family 16
[    0.099000] ACPI: bus type PCI registered
[    0.100000] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.101000] PCI: Using configuration type 1 for base access
안되는 것은 여기서 멈춘다.
되는 것은 아래와 같이 부팅이 진행된다.
[    0.102000] ACPI: Added _OSI(Module Device)
[    0.103000] ACPI: Added _OSI(Processor Device)
[    0.104000] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.105000] ACPI: Added _OSI(Processor Aggregator Device)
[    0.107000] ACPI: SCI (ACPI GSI 9) not registered
[    0.108000] ACPI: EC: Look up EC in DSDT

nolapic 옵션의 문제

VM에 4개의 CPU를 할당했으나 nolapic 옵션을 주면 CPU가 한 개로 제한된다.

dmesg를 보면

[    0.000000] Processors: 4
[    0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
...
[    0.084000] Brought up 1 CPUs
[    0.215000] ACPI: NR_CPUS/possible_cpus limit of 4 reached.  Processor 4/0x2 ignored.
[    0.217000] ACPI: Unable to map lapic to logical cpu number
[    0.218000] ACPI: NR_CPUS/possible_cpus limit of 4 reached.  Processor 5/0x4 ignored.
[    0.219000] ACPI: Unable to map lapic to logical cpu number
[    0.220000] ACPI: NR_CPUS/possible_cpus limit of 4 reached.  Processor 6/0x6 ignored.
[    0.222000] ACPI: Unable to map lapic to logical cpu number

따라서 nolapic 옵션은 부팅에는 성공하나 CPU가 한 개로 제한되므로 해결책은 아니다.

실험 4. ELRepo의 최신 커널

ELRepo는 Enterprise Linux Repository의 약자로 최신 패키지들로 구성되어 있다. CentOS 7의 ELRepo를 enable하여 최신 커널을 설치, 시험해 보자.

Enable ELRepo:

$ sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
$ sudo rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm

Check ELRepo:

$ yum repolist enabled
repo id           repo name                                               status
...
elrepo            ELRepo.org Community Enterprise Linux Repository - el7    235

Show all available packages in elrepo channel:

$ yum --disablerepo="*" --enablerepo="elrepo" list available

Show all available packages in elrepo-kernel channel:

$ yum --disablerepo="*" --enablerepo="elrepo-kernel" list available
...
Available Packages
kernel-lt.x86_64                        4.4.131-1.el7.elrepo       elrepo-kernel
...
kernel-ml.x86_64                        4.16.7-1.el7.elrepo        elrepo-kernel

kernel-it? kernel-ml? 무슨 차이일까?

두 패키지 모두 Linux Kernel Archives에서 소스를 가져도 빌드한 패키지이다. kernel-lt는 Long Term support branch 커널이고 kernel-ml은 Mainline Stable branch 커널이다.

kernel-lt 패키지를 설치하자.

$ sudo yum --disablerepo="*" --enablerepo="elrepo-kernel" install kernel-lt

$ sudo grub2-set-default 0
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
$ sudo reboot

리부팅해 보니 잘 부팅된다.

$ uname -a
Linux localhost.localdomain 4.4.131-1.el7.elrepo.x86_64 #1 SMP Wed May 2 13:09:02 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux

Pick your pill

Matrix영화에서 Morpheus가 Neo에게 한 말:

This is your last chance. After this, there is no turning back. You take the blue pill—the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill—you stay in Wonderland, and I show you how deep the rabbit hole goes. Remember: all I’m offering is the truth. Nothing more.

지금까지의 실험을 요약하자.

  • CentOS 기본 패키지 저장소의 최신 커널은 Dell커뮤니티 에서 논의되는 것처럼 Dell R730 장비와 호환성이 의심된다. 물리머신에서도 CentOS 7 최신 커널을 설치하면 유사한 증상이 재연된다.
  • CentOS 7 최신 커널에 nolapic 커널 옵션을 주면 정상 부팅되나 CPU가 한 개로 제한된다.
  • CentOS 7 최신 커널 패키지(3.10.0-693.21.1.el7.x86_64) 바로 이전 커널 패키지(3.10.0-693.17.1.el7.x86_64)로 부팅하면 문제없이 정상 부팅된다. 난 이것을 Blue Pill 이라 하겠다.
  • ELrepo의 최신 Long Term Support 커널 (kernel-lt)를 설치하여 부팅하면 문제없이 정상 부팅된다. 난 이것을 Red Pill 이라 하겠다.

그래서 결론은? 우리는 파란 약을 선택할 지, 빨간 약을 선택할 지 결정해야 한다.

Blue Pill or Red Pill?

Pick your pill.

]]>
Fri, 04 May 2018 00:00:00 +0900
http://www.iorchard.net/2018/03/28/vlan_tagging_on_uxen3.html http://www.iorchard.net/2018/03/28/vlan_tagging_on_uxen3.html <![CDATA[VLAN tagging on uxen3]]> VLAN tagging on uxen3

개요

VLAN id를 Tag 하는 방법 알아보기.

간략하게 설명하자면 A라는 스위치가 B라는 스위치와 Trunking을 하려면 VLAN 정보를 공유해야 하는데,

이때 사용하는 방식이 Tagging이다. 발신지 쪽에서 프레임에 vlan id을 tag하여 보내야 한다.

즉, 서버에서 L2로 프레임을 보낼때 vlan id를 tag 하여 보내는 설정을 해야 한다.

UXEN3(Xen hypervisor)에서 ovs(openvswitch) port에 연결된 모든 vif의 트래픽에 vlan id 를 tagging하여 L2로 전송하여 보자.

  • ISL(Inter-switch link) : 시스코 전용 트렁킹 프로토콜. 카탈리스트 1700과 같이 예전 스위치 모델에서만 지원합니다.
  • IEEE 802.1Q : IEEE 표준 트렁킹프로토콜. 대부분의 카탈리스트 스위치 모델에서 지원합니다.

UXEN3에서 vlan tgging 지원가능 여부

  1. Trunking protocol을 사용할 수 있는 모듈이 있을까? YES
# modinfo 8021q
filename:       /lib/modules/3.16.0-4-amd64/kernel/net/8021q/8021q.ko
version:        1.8
license:        GPL
alias:          rtnl-link-vlan
srcversion:     594EBB6763374BE3D856132
depends:        mrp,garp
intree:         Y
vermagic:       3.16.0-4-amd64 SMP mod_unload modversions
  1. VLAN 패키지가 설치 되어 있을까? NO..
root@gordon:/home/orchard# dpkg -l |grep vlan
  1. VLAN 패키지를 설치 가능 ? YES
# apt show vlan
Package: vlan
Version: 1.9-3.2
Installed-Size: 150 kB
Maintainer: Ard van Breemen <ard@kwaak.net>
Depends: libc6 (>= 2.14), iproute2
Tag: interface::commandline, network::configuration, role::program,
 scope::utility
Section: misc
Priority: extra
Download-Size: 36.5 kB
APT-Sources: http://ftp.daumkakao.com/debian/ jessie/main amd64 Packages
Description: user mode programs to enable VLANs on your ethernet devices
 This package contains the user mode programs you need to add and remove
 VLAN devices from your ethernet devices.
 A typical application for a VLAN enabled box is a single wire firewall,
 router or load balancer.
 You need a VLAN Linux kernel for this.  Linux kernel versions >= 2.4.14
 have VLAN support.

# dpkg -l |grep libc6 |grep ^ii
ii  libc6:amd64                     2.19-18+deb8u10                amd64        GNU C Library: Shared libraries

# dpkg -l |grep iproute2 |grep ^ii
ii  iproute2                        3.16.0-2                       amd64        networking and traffic control tools

# uname -r
3.16.0-4-amd64

시나리오

UXEN3에서 eth0 인터페이스가 추가되었다.

eth0 인터페이스를 통해 나가는 모든 프레임은 vlan id=700을 태그 하도록 설정한다.

xenbr0 브릿지를 만들고 xenbr0 브릿지 포트에 연결된 모든 vif들의 트래픽에도 vlan id=700을 태그 하도록 해야 한다.

아래 토폴로지중 LAN0에 대한 설정을 다루어 보기로 한다.

LAN0 <ㅡ eth0 <ㅡ eth.700 <ㅡ xenbr0 <ㅡ vif1.0 <ㅡ eth0(VM) 통신 과정과 실제 vlan id를 어디서 tagging하는지 살펴보자.

토폴로지)

Xen Networking with VLANs

(참조 : https://wiki.xenproject.org/wiki/Xen_Networking)

     LAN0                                                  LAN1
      |                                                     |
+-----+-----------------------------------------------------+-----+
|     |                                                     |     |
|   eth0                                                  eth1    |
|     |                                                     |     |
| +---+-------------------------+ +-------------------------+---+ |
| |   |                         | |                         |   | |
| | eth0.700                    | |                    eth1.200 | |
| |                             | |                             | |
| | xenbr0       vif1.0  vif2.0 | |  vif1.1  vif2.1      xenbr1 | |
| |                |       \    | |    /       |                | |
| +---^------------+---------\--+ +--/---------+------------^---+ |
|     |            |           \   /           |            |     |
|     |     +------+-------------X-------------+------+     |     |
|     |     |      |           /   \           |      |     |     |
|     |     | +----+---------/--+ +--\---------+----+ |     |     |
|     |     | |    |       /    | |    \       |    | |     |     |
|     |     | |  eth0    eth1   | |   eth0   eth1   | |     |     |
|     |     | |    |       |    | |    |       |    | |     |     |
|   +-+-+   | |  +-+-+   +-+-+  | |  +-+-+   +-+-+  | |   +-+-+   |
|   |   |   | |  |   |   |   |  | |  |   |   |   |  | |   |   |   |
|  www ssh  | | www ssh ftp pop | | www ssh ftp pop | |  ftp pop  |
|           | |                 | |                 | |           |
|  Domain0  | |     Domain1     | |     Domain2     | |  Domain0  |
+-----------+ +-----------------+ +-----------------+ +-----------+

UXEN3에서 VLAN Tagging 설정 방법

  1. Trunk를 사용하기 위한 모듈을 load 한다.
# modprobe 8021q

# lsmod |grep 8021q                             ##확인.
8021q                  27844  0
garp                   13117  1 8021q
mrp                    17343  1 8021q

# echo "8021q" >> /etc/modules                  ##리부팅을 하여도 해당 모듈이 load되도록 추가한다.
  1. vlan 패키지를 설치한다. 외부 통신이 된다면 apt로 설치 가능하지만, dpkg로 설치를 진행하였다.
# wget http://ftp.daumkakao.com/debian/pool/main/v/vlan/vlan_1.9-3.2%2bb1_amd64.deb
converted 'http://ftp.daumkakao.com/debian/pool/main/v/vlan/vlan_1.9-3.2%2bb1_amd64.deb' (ANSI_X3.4-1968) -> 'http://ftp.daumkakao.com/debian/pool/main/v/vlan/vlan_1.9-3.2+b1_amd64.deb' (UTF-8)
--2018-03-27 14:58:38--  http://ftp.daumkakao.com/debian/pool/main/v/vlan/vlan_1.9-3.2+b1_amd64.deb
Resolving ftp.daumkakao.com (ftp.daumkakao.com)... 113.29.189.165
Connecting to ftp.daumkakao.com (ftp.daumkakao.com)|113.29.189.165|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 36900 (36K) [application/x-debian-package]
Saving to: 'vlan_1.9-3.2+b1_amd64.deb'

vlan_1.9-3.2+b1_amd64.deb  100%[=======================================>]  36.04K  --.-KB/s   in 0s

2018-03-27 14:58:38 (224 MB/s) - 'vlan_1.9-3.2+b1_amd64.deb' saved [36900/36900]

# dpkg -i vlan_1.9-3.2+b1_amd64.deb
Selecting previously unselected package vlan.
(Reading database ... 45932 files and directories currently installed.)
Preparing to unpack vlan_1.9-3.2+b1_amd64.deb ...
Unpacking vlan (1.9-3.2+b1) ...
Setting up vlan (1.9-3.2+b1) ...
Processing triggers for man-db (2.7.0.2-5) ...

# dpkg -l |grep vlan |grep ii
ii  vlan                            1.9-3.2+b1                     amd64        user mode programs to enable VLANs on your ethernet devices
  1. vlan id를 지정하여 물리 NIC과 binding한다. 2번째 인자값은 vlan id이다.
    이렇게 하면 eth0과 eth0.700이 binding되어 eth0은 eth0.700에게 전달받은 모든 프레임에 vlan id 700을 tag 하여 L2로 전달된다.
# vconfig add eth0 700
Added VLAN with VID == 700 to IF -:eth0:-

# cat /proc/net/vlan/config
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth0.700       | 700  | eth0

# ip a|grep eth0.700
17: eth0.700@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
link/ether 00:e3:3d:e8:00:be brd ff:ff:ff:ff:ff:ff
  1. interface 설정파일 작성. (openvswitch)
    reboot 하여도 모든 interface가 정상적으로 up된 것을 확인하였다.
기존 물리 NIC인 eth0을 xenbr0 bridge port에 연결하지 않고 eth0.700을 연결한다.
# vi /etc/network/interfaces

auto eth0
iface eth0 inet manual
post-up ethtool -K eth0 tx off

allow-xenbr0 eth0.700
iface eth0.700 inet manual
        vlan-raw-device eth0
        ovs_type OVSPort
        ovs_bridge xenbr0

allow-ovs xenbr0
iface xenbr0 inet manual
        ovs_type OVSBridge
        ovs_ports eth0.700
        birdge_maxwait 5
        up ip link set xenbr0 up

# ifup xenbr0

# ovs-vsctl list-ports xenbr0
eth0.700

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:e3:3d:e8:00:be brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2e3:3dff:fee8:be/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 1000
    link/ether 00:1e:90:ac:2b:3c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::21e:90ff:feac:2b3c/64 scope link
       valid_lft forever preferred_lft forever
12: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
    link/ether 82:af:ab:a6:9b:12 brd ff:ff:ff:ff:ff:ff
16: xenbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether 00:1e:90:ac:2b:3c brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.150/24 brd 192.168.0.255 scope global xenbr1
       valid_lft forever preferred_lft forever
    inet6 fe80::21e:90ff:feac:2b3c/64 scope link
       valid_lft forever preferred_lft forever
19: xenbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether 00:e3:3d:e8:00:be brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2e3:3dff:fee8:be/64 scope link
       valid_lft forever preferred_lft forever
20: eth0.700@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP group default
    link/ether 00:e3:3d:e8:00:be brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2e3:3dff:fee8:be/64 scope link
   valid_lft forever preferred_lft forever
  1. VM을 만들어 xenbr0 브릿지에 vif가 추가 되도록 하였다. (vm 생성 과정 생략)
    이렇게 설정이 되면 VM은 vlan의 존재를 모르고 모든 VM의 트래픽의 tagging은 dom0에서 처리한다.
# xl create bino-debian.cfg

# ovs-vsctl list-ports xenbr0
eth0.700
vif3.0
  1. 검증. 실제 프레임이 vlan id = 700 을 tag하여 L2로 전송되는지 확인해보자. 실제 스위치를 준비하여 Trunk설정 하지는 않았고, 패킷을 분석하여 vlan id를 Tag하는지 확인할 것이다.

아래 4개의 인터페이스를 각각 tcpdump로 모니터링하여 비교 분석 해보기로 한다.

  • PM에서 eth0 인터페이스
  • PM에서 eth0.700 인터페이스
  • PM에서 vif3.0 인터페이스
  • VM에서 eth0 인터페이스

흐름도

eth0(VM) —-> vif3.0 —> xenbr0 —> eth0.700 —> eth0 —> LAN0

PM과 VM의 인터페이스 정보는 아래와 같다.

  1. PM의 정보
root@bino:/home/orchard# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:e3:3d:e8:00:be brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2e3:3dff:fee8:be/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 1000
    link/ether 00:1e:90:ac:2b:3c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::21e:90ff:feac:2b3c/64 scope link
       valid_lft forever preferred_lft forever
4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
    link/ether 76:1b:e1:60:64:a6 brd ff:ff:ff:ff:ff:ff
5: xenbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether 00:1e:90:ac:2b:3c brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.150/24 brd 192.168.0.255 scope global xenbr1
       valid_lft forever preferred_lft forever
    inet6 fe80::21e:90ff:feac:2b3c/64 scope link
       valid_lft forever preferred_lft forever
6: xenbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether 00:e3:3d:e8:00:be brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2e3:3dff:fee8:be/64 scope link
       valid_lft forever preferred_lft forever
7: eth0.700@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP group default
    link/ether 00:e3:3d:e8:00:be brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2e3:3dff:fee8:be/64 scope link
       valid_lft forever preferred_lft forever
16: vif3.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
17: vif3.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
  1. VM의 정보
VM:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:16:3e:62:cc:65 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.185/24 brd 10.1.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe62:cc65/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:16:3e:55:61:36 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.185/24 brd 192.168.0.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe55:6136/64 scope link
       valid_lft forever preferred_lft forever

각각의 인터페이스를 모니터링준비

PM:~# tcpdump -i eth0 -e
PM:~# tcpdump -i eth0.700 -e
PM:~# tcpdump -i vif3.0 -e
VM:~# tcpdump -i eth0 -e

VM에서 ping으로 1개의 패킷을 보내 L2로 전송될때 vlan id가 어디서 찍히는지 보자.

VM:~# ping -c 1 10.1.1.152
PING 10.1.1.152 (10.1.1.152) 56(84) bytes of data.

--- 10.1.1.152 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
  1. VM에서의 eth0 인터페이스
VM:~# tcpdump -i eth0 -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:13:49.368364 00:16:3e:62:cc:65 (oui Unknown) > 00:20:78:12:19:f1 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.1.1.185 > 10.1.1.152: ICMP echo request, id 2238, seq 1, length 64
16:13:54.444131 00:16:3e:62:cc:65 (oui Unknown) > 00:20:78:12:19:f1 (oui Unknown), ethertype ARP (0x0806), length 42: Request who-has 10.1.1.152 tell 10.1.1.185, length 28
16:13:54.444881 00:20:78:12:19:f1 (oui Unknown) > 00:16:3e:62:cc:65 (oui Unknown), ethertype ARP (0x0806), length 56: Reply 10.1.1.152 is-at 00:20:78:12:19:f1 (oui Unknown), length 42

3 packets captured
3 packets received by filter
0 packets dropped by kernel
  1. PM에서의 vif3.0 인터페이스
PM:~# tcpdump -i vif3.0 -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vif3.0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:13:49.361134 00:16:3e:62:cc:65 (oui Unknown) > 00:20:78:12:19:f1 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.1.1.185 > 10.1.1.152: ICMP echo request, id 2238, seq 1, length 64
16:13:54.436979 00:16:3e:62:cc:65 (oui Unknown) > 00:20:78:12:19:f1 (oui Unknown), ethertype ARP (0x0806), length 42: Request who-has 10.1.1.152 tell 10.1.1.185, length 28
16:13:54.437615 00:20:78:12:19:f1 (oui Unknown) > 00:16:3e:62:cc:65 (oui Unknown), ethertype ARP (0x0806), length 56: Reply 10.1.1.152 is-at 00:20:78:12:19:f1 (oui Unknown), length 42

3 packets captured
3 packets received by filter
0 packets dropped by kernel
  1. PM에서의 eth0.700 인터페이스
PM:~# tcpdump -i eth0.700 -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.700, link-type EN10MB (Ethernet), capture size 262144 bytes
16:13:49.361291 00:16:3e:62:cc:65 (oui Unknown) > 00:20:78:12:19:f1 (oui Unknown), ethertype IPv4 (0x0800), length 98: 10.1.1.185 > 10.1.1.152: ICMP echo request, id 2238, seq 1, length 64
16:13:54.437103 00:16:3e:62:cc:65 (oui Unknown) > 00:20:78:12:19:f1 (oui Unknown), ethertype ARP (0x0806), length 42: Request who-has 10.1.1.152 tell 10.1.1.185, length 28
16:13:54.437527 00:20:78:12:19:f1 (oui Unknown) > 00:16:3e:62:cc:65 (oui Unknown), ethertype ARP (0x0806), length 56: Reply 10.1.1.152 is-at 00:20:78:12:19:f1 (oui Unknown), length 42

3 packets captured
3 packets received by filter
0 packets dropped by kernel
  1. PM에서의 eth0 인터페이스
PM:~# tcpdump -i eth0 -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:13:49.361297 00:16:3e:62:cc:65 (oui Unknown) > 00:20:78:12:19:f1 (oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 700, p 0, ethertype IPv4, 10.1.1.185 > 10.1.1.152: ICMP echo request, id 2238, seq 1, length 64
16:13:49.361664 00:20:78:12:19:f1 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.1.1.185 tell 10.1.1.152, length 46
16:13:50.361181 00:20:78:12:19:f1 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.1.1.185 tell 10.1.1.152, length 46
16:13:51.361190 00:20:78:12:19:f1 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.1.1.185 tell 10.1.1.152, length 46
16:13:54.437113 00:16:3e:62:cc:65 (oui Unknown) > 00:20:78:12:19:f1 (oui Unknown), ethertype 802.1Q (0x8100), length 46: vlan 700, p 0, ethertype ARP, Request who-has 10.1.1.152 tell 10.1.1.185, length 28
16:13:54.437527 00:20:78:12:19:f1 (oui Unknown) > 00:16:3e:62:cc:65 (oui Unknown), ethertype 802.1Q (0x8100), length 60: vlan 700, p 0, ethertype ARP, Reply 10.1.1.152 is-at 00:20:78:12:19:f1 (oui Unknown), length 42

6 packets captured
6 packets received by filter
0 packets dropped by kernel

결과 분석

L2:Ethernet 헤더는 Destination MAC Address, Source MAC Address 그리고 Ethernet Type으로 구성된다.

eth0(PM) 패킷의 헤더를 설명하자면 첫 번째 필드에는 시간이 담겨있고, 두 번째 필드부터 DA(00:16:3e:62:cc:65), 세 번째 필드는 SA(00:20:78:12:19:f1), 원래라면(Untagged) 네 번째 필드에 L3패킷의 타입을 담는다. (PM의 eth0을 제외한 나머지는 모두 그렇다.) 하지만 해당 패킷은 네번째 필드부터 vlan 정보가 담긴다. 802.1q(0x8100)와 다섯번째 필드에 vlan 700 인 vlan id가 담기고, 다시 L3의 타입이 담기게 된다.

eth(VM), vif3.0, eth0.700 모두 동일하게 vlan id를 tag하지 않는다. 즉 PM의 물리NIC인 eth0인터페이스를 거쳐 패킷이 L2로 흐를 때 vlan id가 tag된다.

이해를 돕기 위한 이미지

../../../_images/vlan_header.png

만약 xenbr0에 vif가 많다면 모두 eth0 NIC을 거치기 때문에 VLAN id가 tag된다.

]]>
Wed, 28 Mar 2018 00:00:00 +0900
http://www.iorchard.net/2018/02/26/uefi_vs_bios_and_gpt_vs_mbr.html http://www.iorchard.net/2018/02/26/uefi_vs_bios_and_gpt_vs_mbr.html <![CDATA[UEFI vs BIOS and GPT vs MBR]]> UEFI vs BIOS and GPT vs MBR

이 글은 머신에서 사용하는 두 개의 다른 디자인(firmware 디자인과 partitioning 디자인)에 관한 이야기다.

후반부에는 FAI를 이용한 BIOS와 GPT partition 방법을 소개한다.

  • Firmware designs
    • UEFI: Unified Extensible Firmware Interface
    • BIOS: Basic Input Output System
  • Partitioning designs
    • GPT: GUID Partition Table
    • MBR: Master Boot Record

BIOS firmware and MBR partitioning are old and legacy designs.

UEFI firmware and GPT partitioning are new and latest designs.

위 기술들을 공부하자.

UEFI

UEFI는 EFI(Extensible Firmware Interface)의 계승자이다. 1990년대 중반 인텔은 IBM의 BIOS 방식의 firmware 인터페이스는 너무 제한적이라고 생각했다.

그래서 인텔은 1998년에 EFI spec.을 개발하기 시작했다. 2005년 인텔은 EFI 개발을 중단하고 소유권은 유지한 채 Unified EFI Forum에 개발해온 EFI를 넘긴다. 그래서 현재까지도 인텔은 EFI 라이선스를 가지고 있다. 그러나 UEFI Spec.은 Forum이 소유하고 있다.

UEFI가 BIOS보다 나은 점

  • 애플리케이션을 실행할 수 있는 강력한 pre-boot 환경
  • 모듈라 디자인
  • CPU 독립적인 아키텍처(Itanium, x86, x86-64, ARM Arch32, Arm Arch64)
  • BIOS 인터페이스 호환, 레거시 부팅 지원
  • Secure Boot 가능 (Windows용. 리눅스에서는 오히려 장애가 됨)

GPT가 MBR보다 나은 점

  • 2TiB 보다 더 큰 디스크 부팅 가능(MBR은 2TiB까지만 부팅 가능)
  • 부팅가능한 파티션의 수 제한
  • 8ZiB add(512B sectors), 64ZiB (4KiB sectors)
    • ZiB: Zebibyte, <- Exbibyte <- Pebibyte <-Tebibyte <- Gibibyte
    • ZB: Zettabyte, <- Exabyte <- Petabyte <-Terabyte <- Gigabyte
  • boot code와 partition table을 분리(MBR은 boot code가 boot sector에 존재)

GPT에서 사용하는 특별 파티션 ESP(EFI System Partition)가 있다. 이 파티션은 FAT32로 포맷되고 partition type code는 EF00이다. 이 파티션에는 .efi 확장자를 가진 bootloaders와 boot manager파일들이 있다. 부팅할 때 mainboard의 UEFI compliant firmware는 모든 디스크의 ESP파티션의 EFI파일들을 검색한다.

우리는 리눅스에서 다음과 같은 의문이 생긴다.

BIOS firmware로 부팅한 머신에서 GPT를 사용할 수 있는가?

UEFI만 지원하는 머신이 점점 나오고 있다.

BIOS만 지원하는 또는 UEFI/BIOS 모두 지원하지만 BIOS로 부팅하고 싶은데 머신이 2TiB가 넘는 디스크를 가지고 있으면 우리는 GPT를 사용할 수 밖에 없다.

  • UEFI machine + GPT partition: need an ESP partition(Code EF00)
  • BIOS machine + GPT partition: need a BIOS boot partition(Code EF02)
  • BIOS + MBR(BIOS-MBR) = OK
  • BIOS + GPT(BIOS-GPT) = OK
  • UEFI + GPT(UEFI-GPT) = OK
  • UEFI + MBR = NO

Layout of GPT partition

The beginning of a GPT partitioned disk

Protective MBR | 512B |
Primary GPT Header | 512B |
Primary Partition Table entries | up to 16KiB (max. of 128 partitions)|

17KiB가 사용된다.

The end of a GPT-partitioned disk

Secondary Partition Table entries | Up to 16KiB (max. of 128 partitions) |
Secondary GPT Header | 512B |

16.5KiB가 사용된다.

위 두 개의 unpartitioned space 사이에 GPT partition이 최대 128개까지 만들어 질 수 있다. 그 중 한 파티션(주로 첫번째 파티션)은 특별한 ESP 파티션이다. ESP 파티션은 FAT32로 포맷되어야 하고 esp와 boot 플래그 설정을 가지고 code는 EF02이다. FAT32 파티션의 최소 크기는 약 32MiB이다. ESP 파티션의 필요 크기는 가변적이나 100 ~ 200 MiB 사이로 할당하는 것을 권장한다.

가장 좋은 것은 BIOS든 UEFI든 GPT로 파티션된 디스크를 부팅할 수 있도록 하면 된다. 그럼 어떻게 그렇게 할 수 있을까?

BIOS boot partition와 EFI System Partition(ESP)모두 만들자.

  • 1MB BIOS boot partition (type EF02) grub는 여기에 core image를 저장.
  • 100MB EFI System Partition (type EF00). FAT32 포맷. EFI boot 이미지 저장
  • 나머지 공간에 원하는 대로 파티션

위와 같은 설정은 나중에 시험하고 지금은 BIOS boot partition을 생성하여 BIOS-GPT 조합을 FAI에서 사용하는 법을 설명한다.

FAI의 setup-storage대로 설정하려면 다음과 같이 하면 된다.

$ cat porch/porch/templates/dpt-kubeminion.j2
disk_config disk1 disklabel:gpt-bios bootable:1 fstabkey:uuid
primary swap   10G       swap  sw
primary /      30G      ext4  rw,noatime,errors=remount-ro
primary -      50G       -       -
primary /data  10G-     xfs     rw

disklabel에 gpt-bios로 지정하면 BIOS boot partition을 자동으로 만들어준다.

다음은 FAI로 설치 후에 본 disk partition 정보이다.

# parted /dev/sda print
Model: IBM ServeRAID M5210 (scsi)
Disk /dev/sda: 2398GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name     Flags
 5      1049kB  2097kB  1049kB                  primary  bios_grub
 1      2097kB  10.7GB  10.7GB  linux-swap(v1)  primary  boot
 2      10.7GB  43.0GB  32.2GB  ext4            primary
 3      43.0GB  96.6GB  53.7GB                  primary
 4      96.6GB  2398GB  2301GB  xfs             primary

다섯번째 파티션으로 bios_grub flag를 가진 약 1MiB 크기의 BIOS boot partition이 생성되었다.

]]>
Mon, 26 Feb 2018 00:00:00 +0900
http://www.iorchard.net/2018/01/24/kt_gigawire_multi_vbd_support.html http://www.iorchard.net/2018/01/24/kt_gigawire_multi_vbd_support.html <![CDATA[KT GiGAWire Multi-VBD Support]]> KT GiGAWire Multi-VBD Support

We, at iOrchard, are developing the cloud-based VBCE management system. While developing, there are some problems with the data files in VBCE report directory as below.

Problem 1. No support for multi-VBD data

The current directory heirarchy only supports one VBD data since portGhn_<mac> file is in the top directory.

if <mac> in VBD1 is the same as <mac> in VBD2, VBD1 and VBD2 will overwrite to the same file - very dangerous.

Problem 2. No way to know Domain Master(DM)-EndPoint(EP) pairs

With data files in measures directory, there is no way to know which DM port links to which EP port.

I know I can find out the pairs if I connect to the console but I want to know the pairs using only data files. I want to show each link in management system.

So I’m asking for your help to change directory heirarchy in data directory as follows.

Desired Directory Heirarchy for Cloud VBCE

report_engine is the top directory to store VBD, VBCE data files.

Here is the current heirarchy.

report_engine/
    vbDriverStatus_<driver_id> (f)
    vbEngineStatus_<driver_id> (f)
    vbDriverVersion_<driver_id> (f)
    vbEngineVersion (f)
    portGhn_<mac> (f)
    measures/ (d)
        <YYYY_MM_DD_Time_HH_mm_ss>/ (d)
            Measures_Device_MAC_<mac>.csv (f)

And this is the new heirarchy I suggest.

report_engine/
    vbDriverStatus_<driver_id> (f)
    vbEngineStatus_<driver_id> (f)
    vbDriverVersion_<driver_id> (f)
    vbEngineVersion (f)
    <driver_id>/ (d)
        portGhn_<mac> (f)
        measures/ (d)
            <YYYY_MM_DD_Time_HH_mm_ss>/ (d)
                Measures_Device_MAC_<mac>.csv (f)
  • (f): file
  • (d): directory

With this heirarchy, we can distinguish every VBD data and there is no overwriting files since VBD <driver_id> directory is under the top directory and every data will be written under <driver_id>.

You guys can suggest the better heirarchy as you know better than me.

How to know DM-EP pairs

For the 2nd problem, you can put a pair information in measures data file.

Here is the current measure data file.

Measures_Device_MAC_00_13_9D_10_00_01.csv

MAC Measurer: 00 13 9D 10 00 01
First Carriers: 73
Spacing: 1
Flags: 0
MIMO Ind: 0
CFR 70 30 5D 20 BA 9D; MIMO Ind 0
CFR 70 30 5D 1F BC 28; MIMO Ind 0
bgn rx1 49;cfr own rx1 48;cfr xtalk rx1 80;

Just put EP info there like this.

EndPoint: 70 30 5D 1F BC 28

Then, we can parse that data and we know DM-EP relationship.

Again, I think you have the better idea on this, too. Let me know your thoughts and share the idea.

Problem 3. vb_engine.ini is not structured to support multi-VBD

This is the current vb_engine.ini structure.

--- begin vb_engine.ini snip ----
  <DriversList>
    <Driver>
        <IP>125.158.129.18</IP>
        <Port>40011</Port>
    </Driver>
  </DriversList>
  <UserProfiles>
    <UserProfile>
      <MAC>AA:BB:CC:DD:EE:FF</MAC>
      <SLAName>SLAHighPrio</SLAName>
      <Weight>1</Weight>
    </UserProfile>
  </UserProfiles>
--- end vb_engine.ini snip ---

The problem is there is no way to support multi-VBD with this xml structure. UserProfiles should be inside of Driver xml node to support multi-VBD.

My suggestion is like below.

--- begin suggested vb_engine.ini snip ----
  <DriversList>
    <Driver>
      <IP>125.158.129.18</IP>
      <Port>40011</Port>
      <UserProfiles>
        <UserProfile>
          <MAC>AA:BB:CC:DD:EE:FF</MAC>
          <SLAName>SLAHighPrio</SLAName>
          <Weight>1</Weight>
        </UserProfile>
      </UserProfiles>
    </Driver>
  </DriversList>
--- end suggested vb_engine.ini snip ---

In this way, each Driver can has UserProfiles in multi-VBD environment.

Thanks,

Heechul Kim @iOrchard.

]]>
Wed, 24 Jan 2018 00:00:00 +0900
http://www.iorchard.net/2018/01/15/uxen_meltdown_vulnerability.html http://www.iorchard.net/2018/01/15/uxen_meltdown_vulnerability.html <![CDATA[UXEN: Meltdown vulnerability]]> UXEN: Meltdown vulnerability

Meltdown vulnerability에 대한 UXEN의 입장

안녕하세요. 아이오차드 김 희 철 입니다.

최근 Intel CPU Meltdown 취약점으로 인한 UXEN의 보안 문의에 대한 설명을 드리겠습니다.

Meltdown 취약점을 한 줄로 요약하자면,

user space program이 kernel space memory에 접근할 수 있어 민감한 정보를 취득할 수 있다.

질문과 답변 형식으로 진행하겠습니다.

일반 질문 답변

Q> Meltdown 공격은 원격에서도 가능한가요?

A> 원론적으로는 불가능합니다. 이 취약점은 로컬 호스트 영역에서 일어나는 취약점입니다. 즉, 호스트에 로그인하여 프로세스를 실행할 수 있는 권한이 있어야 합니다.

그러나 원격에서 불가능하다고 말할 수는 없습니다.

예를 들면, 웹 서비스를 하는데 웹 서버의 어떤 취약점으로 인해 공격자가 로컬 프로세스를 실행할 수 있게 된다면, Meltdown 공격이 가능하게 됩니다.

그러나 이것은 웹 서버의 취약점부터가 문제입니다. 이 경우 Meltdown이 아니더라도 다른 공격이 가능하게 됩니다.

Q> Meltdown 공격을 받으면 어떤 문제가 있나요?

A> Meltdown 공격은 메모리 읽기만 허용하지 변경을 할 수는 없습니다. 그러므로 Meltdown은 직접적으로 시스템 장애를 발생시키는 취약점은 아닙니다. 그러나 간접적으로 시스템 장애를 일으킬 가능성도 있습니다.

공격자가 Meltdown 공격에 성공하면 시스템의 민감한 정보를 취득할 수 있습니다. 민감한 정보란 비밀번호, 인증서 등이 되겠지요.

공격 방식의 특성 상 메모리 읽는 속도는 2KB/s 입니다. 그러니 meltdown 취약점 공격은 상당한 시간이 걸립니다.

UXEN 관련 질문 답변

Q> DomU의 사용자 프로세스가 Hypervisor에 Meltdown 공격을 할 수 있나요?

A> 64bit PV DomU만 공격이 가능합니다. HVM DomU는 Meltdown 취약점으로 공격할 수 없습니다. UXEN은 HVM으로만 DomU를 생성하기 때문에 DomU의 사용자 프로세스가 Hypervisor에 Meltdown 공격을 할 수 없습니다.

Q> DomU의 사용자 프로세스가 같은 DomU 커널에 Meltdown 공격을 할 수 있나요?

A> 예. 이것은 가능합니다.

따라서 DomU의 OS 커널을 업그레이드하여 Meltdown 공격으로부터 보호하는 것이 좋습니다.

각 배포판 별로 커널 업데이트를 해야 합니다. 그러나 speculative execution을 하지 못하니 성능은 떨어집니다.

다시 말씀드리지만 Meltdown은 로컬 호스트 영역의 취약점입니다.

  1. trusted user(공격자가 아닌 선량한 사용자)의 로그인 정보를 유출하지 않고,
  2. trusted user외에는 로그인할 수 없고,
  3. 원격 접속 취약점이 없다면,

Meltdown 취약점 공격을 할 수 있는 프로세스는 구동될 수 없습니다.

Q> DomU의 사용자 프로세스가 다른 DomU 커널에 Meltdown 공격을 할 수 있나요?

A> 아니오. UXEN은 HVM으로 DomU를 생성하기 때문에 DomU간 메모리는 격리됩니다. 따라서 다른 DomU의 메모리 영역을 접근할 수는 없습니다.

결론

  • UXEN에서 DomU를 HVM으로 생성하기 때문에 DomU가 hypervisor를 공격 할 수 없습니다.
  • UXEN에서 DomU는 HVM으로 생성하기 때문에 다른 DomU를 공격 할 수 없습니다.
]]>
Mon, 15 Jan 2018 00:00:00 +0900