Архів рубрики: Файлові системи

Все що стосується файлових систем та роботи з файлами

Монтування спільної директорії в VirtualBox

Тимчасове припинення публікацій в моєму блозі пов’язане з тим, що на новому робочому місці я користуюсь Window 7. Я не роблю з цього великої трагедії, але час від часу сумую за Linux. Особливо не вистачає консолі та віртуальних робочих столів.

Проте необхідність у використанні Лінукс не зникла. Так для одного проекту, мені потрібно мати тестову віртуальну машину з Лінукс. Встановити її у VirtualBox дуже просто, а от щоб налагодити доступ до спільних каталогів треба додати кілька команд.

Першим кроком створюємо спільну директорію у параметрах віртуальної машини. Нехай її ім’я буде Common. Тепер монтуємо цю директорію від рута для перевірки:

# mount -t vboxsf Common /mnt/share

Якщо все вірно, то у директорію /mnt/share гостьової Лінукс буде змонтована спільна директорія з назвою Common.

Тепер залишається налагодити автоматичне монтування цієї спільної директорії при завантаженні Лінукс. Простіше за все, це зробити через додавання рядка у файл /etc/fstab:

Common /mnt/share vboxsf uid=1000,gid=1000 0 0

Використайте власні значення для ID користувача та групи, яким буде належати змонтована директорія. Останні два нульових параметра, означають, що файлова система не потребує архівації та перевірки на помилки.

Заміна IP адреси у файлах зон BIND

Є такі люди, що люблять подорожувати. Іноді сайти та сервіси теж зриваються з насидженого місця та вирушають у дорогу. Така міграція – справжній головний біль для системного адміністратора. Коли мова йде про 1-2 сервіси, це не проблема, а от коли переїжджає цілий хостінг.

Задача: є сервер імен BIND в якому треба поміняти всі записи зі старим IP на новий. Справу ускладнює те, що не всі зони треба міняти (оновлювати serial). Зміни мають зачепити лише ті файли зон, в яких дійсно змінюється IP. Як правило, я роблю такі зміни за допомогою Perl сценарію, але сьогодні спробував вичавити по максимуму командний рядок Лінукс.

У каталозі /etc/bing/db були зібрані файли зон, але були вкладені каталоги та символічні посилання. Тому на першому етапі відбираємо лише файли з каталогу та не чіпаємо підкаталоги:

find /etc/bind/db -maxdepth 1 -type f

Через xargs направляємо файл до grep

grep -H -m 1 '75.147.252.194'

Аргумент -H обов’язково додасть ім’я файлу до виводу, а -m 1 – покаже лише перше згадування старої IP-адреси.

Тепер залишаємо лише ім’я потрібного файлу зони (перший стовпець):

cut -d: -f1

Цю конструкцію я додав до Perl сценарію і на виході мав перелік файлів, в яких потрібно було зробити заміну IP та serial номер зони:

my $db_dir = "/etc/bind/db";
my $old_ip = '75.147.252.194';

my @files = `find $db_dir -maxdepth 1 -type f |
 xargs grep -H -m 1 '$old_ip' |
 cut -d: -f1`;

Як поставити пароль на архів tar у Лінукс

Виявляється це на так просто. Команда tar не має вбудованої підтримки шифрування. Тому робимо це у “юнікс”-way:

Шифруємо дані:

$ tar cfz - ФАЙЛ | openssl enc -aes-256-cbc -e > АРХІВ.tar.gz
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

Розшифровуємо:

$ openssl enc -in АРХІВ.tar.gz -aes-256-cbc -d | tar -zxvf -
enter aes-256-cbc decryption password:

Звичайно замість файлу може бути і директорія.

Масове перекодування файлів з cp1251 у utf8

Пересаджуючи старий проект на Twitter Bootstrap я стикнувся з необхідністю перекодування шаблонів HTML з кодової сторінки window-1251 у UTF-8. Шаблони всі були в одному каталозі, мали розширення *.tmpl і їх було не багато, але запускати для кожного файлу iconv було якось не по лінуксоїдські. Проблема була ще й у методі конвертації утиліти iconv – вона не перезаписувала файл, а робила вивід у новий. Тобто для кожного файлу треба було зробити такі дії:

  1. Перевести з cp1251 у utf8 та зберегти у новому файлі
  2. Замінити старий файл новим

Писати сценарій для такої простої операції не варто, тому я зробив це у 3 команди, але потім трохи подумав і зменшив їх до 2:

$ ls *.tmpl | sed s/tmpl$/tmp/ | xargs -I '{}'
 iconv -f cp1251 -t utf8 -o '{}' '{}'l

Знаходимо в поточній директорії всі файли шаблонів (з розширенням tmpl), змінюємо розширення на tmp, конвертуємо файл *.tmpl у *.tmp. Тепер tmp-файли містять шаблони в UTF-8 кодуванні.

А тепер у старі tmpl-файли кладемо новий зміст:

$ ls *.tmp | xargs -I '{}' mv '{}' '{}'l

Якщо вам треба перекодувати файли, що розташовані в піддиректоріях, то змініть команду ls на find.

Форматування флешки після інсталятора Debian

Після встановлення операційної системи з USB флешки, мені вона знадобилась як засіб перенесення інформації на інші комп’ютери. Але образ інсталяційного ISO диску змінив її розмір, тобто треба було повернути її первісний стан та файлову систему FAT32.

Порядок роботи такий:

Вставляємо флешку до USB порту. Запускаємо команду fdisk -l, щоб зрозуміти який це пристрій. Як видно з виводу команди в мене він має назву /dev/sdc:

# fdisk -l
WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util
 fdisk doesn't support GPT. Use GNU Parted.
...
Disk /dev/sdc: 1021 MB, 1021125120 bytes
...
Disk /dev/sdc1: 232 MB, 232783872 bytes
32 heads, 61 sectors/track, 232 cylinders, total 454656 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
Disk identifier: 0x00000000

 Device Boot      Start         End      Blocks   Id  System

Видно що таблиця розділів містить нестандартний розділ /dev/sdc1 232 Mb. Треба його позбутися. Але спершу потрібно цей розділ відмонтувати:

# umount /dev/sdc1

Запускаємо fdisk /dev/sdc

У режимі діалогу виконуємо 2 команди: o [Enter] та w [Enter]

o   create a new empty DOS partition table
w   write table to disk and exit

Після цього можна створювати файлову систему FAT32:

# mkdosfs -F 32 -I /dev/sdc

Порівняння вмісту директорій

Більшість користувачів Лінукс знають, що команда diff застосовується для порівняння вмісту файлів, але вона також може порівнювати директорії.

Для цього достатньо викликати її з параметром -r

$ diff -r dir1 dir2

Мені вона стала у пригоді, коли треба було визначити розбіжності між двома WAR-файлами. Я розпакував їх вміст у дві директорії та порівняв їх.

Зручно те, що за умовчанням вона не показує розбіжності у двійкових файлах, а лише інформує, що файли різні.

Як полагодити (видалити) смітник у Gnome з командного рядка

Якось в мене перестали видалятися файли зі смітника, що на робочому столі. В принципі і не проблема, але це неправильно.  Писало помулку про неможливість видалити файл.

Думаю причина в тому, що я видаляв директорії вміст яких мені не належав. Система Gnome перемістила їх до смітника, а видалити забороняє, бо там є не мої файли.

Вирішити проблему можно якщо присвоїти ці файли собі, але спочатку треба знайти корзину у файловій системі. Колись, вона була у каталозі ~/.Trash, але зараз чомусь переїхала до ~/.local/share/Trash

Отже, переходимо до потрібного каталогу та стаємо рутом:

$ cd ~/.local/share
$ sudo -s
# chown -R ЛОГІН_КОРИСТУВАЧА Trash
# exit
$ rm -fr Trash

Відновлення програмного RAID в Лінукс. Завершення.

Дані я не втратив, тому настрій в мене відмінний. Але треба відновити роботу системи так, щоб все було зручно і без несподіванок. А наразі в мене є такі претензії:

  • під час завантаження доводиться завжди редагувати Grub вказуючи вірний розділ root
  • не завантажується з меню Grub щойно-встановлена Windows XP
  • система працює без swap-розділу

Перші 2 проблеми пов’язані з Grub, тому час відредагувати меню завантажувача. Це файл /boot/grub/menu.lst.

В мене він такого змісту (тільки важливе):

# menu.lst - See: grub(8), info grub, update-grub(8)
...

title       Debian GNU/Linux, kernel 2.6.26-2-amd64
root        (hd0,1)
kernel      /vmlinuz-2.6.26-2-amd64 root=/dev/md2 ro quiet
initrd      /initrd.img-2.6.26-2-amd64

title       Debian GNU/Linux, kernel 2.6.26-2-amd64 (single-user mode)
root        (hd0,1)
kernel      /vmlinuz-2.6.26-2-amd64 root=/dev/md2 ro single
initrd      /initrd.img-2.6.26-2-amd64

# This is a divider, added to separate the menu items below from the
# Debian ones.
title        Other operating systems:
root

# This entry automatically added by the Debian installer for
# a non-linux OS on /dev/sda1
title        Microsoft Windows XP Professional RU
root        (hd0,0)
savedefault
makeactive
chainloader    +1

Гадаю root (hd0,1) треба замінити на root (hd0,2), адже саме розділ /dev/sda3 – в нас входить у RAID пристрій завантаження.

Для Windows XP параметри (hd0,0) виглядають правильними, тому проблем із завантаженням не має бути.

Але слід перезапустити комп’ютер та пересвідчитись. Перезапуск пройшов на ура, тому перші два пункти виправлені. Та все ж зауважу, що у разі проблем з першим диском мені знову прийдеться правити у ручну меню Grub-завантажувача :( тому що розподіл розділів першого диску відрізняється від 3-х інший. Зараз бачу тільки один спосіб запобігти цьому – додати 3-й пункт меню Grub для завантаження Лінукс з резервних дисків (2-го, 3-го чи 4-го). Виглядати у файлі grub/menu.lst він буде приблизно так:

title       Rescue (if RAID master boot disk failed)
root        (hd0,0)
kernel      /vmlinuz-2.6.26-2-amd64 root=/dev/md2 ro single
initrd      /initrd.img-2.6.26-2-amd64

Переходимо до роботи зі свопом (swap розділ).

Якщо пам’ятаєте, розділ RAID-0 повністю зруйновано, але це не страшно, адже він використовувався як область підкачки (swap). Треба відтворити його та задіяти у системі. За нього відповідає RAID пристрій /dev/md0. Ось які відомості є у системи при цей RAID:

# mdadm --detail /dev/md1
/dev/md1:
Version : 00.90
Creation Time : Sun Jan 31 16:13:45 2010
Raid Level : raid0
Raid Devices : 2
Total Devices : 1
Preferred Minor : 1
Persistence : Superblock is persistent

Update Time : Sun Jan 31 16:13:45 2010
State : active, degraded, Not Started
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
Chunk Size : 64K
UUID : c77a68cb:56309d8e:84c426df:55d8644d (local to host c2d)
Events : 0.1

Number   Major   Minor   RaidDevice State
0       0        0        0      removed
1       8       21        1      active sync   /dev/sdb5

Було б непогано створити його не з 2-х розділів, а з 4-х. Тоді теоретично швидкість роботи зі swap підвищилась би у 4 рази.

Спроба збільшити кількість активних пристроїв закінчилась невдачею:

# mdadm --grow /dev/md1 -n 4
mdadm: raid0 array /dev/md1 cannot be reshaped.

Мабуть треба створити цей пристрій з нуля. В нього слід додати пристрої /dev/sdb5 (він єдиний там), /dev/sda6, /dev/sdc5 та /dev/sdd5.

Видаляємо /dev/sdb5 зі старого масиву:

# mdadm /dev/md1 -f /dev/sb5
# mdadm /dev/md1 -r /dev/sb5

Але ці команди закінчуються невдачею. Пристрій зайнятий.

Не слід забувати, що справу маємо з RAID-0, тобто режимом, в якому дискові пристрою чергуються, а тому він не призначений для “гарячої” заміни пристроїв. Система програмного RAID Лінукса  наче чекає, коли ми “знайдемо” та додамо справжній робочий розділ. При додаванні порожніх розділів, система їх приймає – але помічає як “запасні” (spare).

Для того, щоб мати змогу створити з нуля RAID-0, треба смусити систему забути про розділи які до нього колись входили. Для цього слід стерти на цих розділах так звані “супер-блоки”. Для цього можна використати команду:

# mdadm /dev/md1 --zero-superblock /dev/sdb5

Але коли RAID масив хоча б частково ініціалізовано, вона (команда) закінчується помилкою, бо пристрій зайнято. Тобто треба або зупинити роботу демона підтримки програмного RAID у Лінукс (mdadm), або завантажити комп’ютер з “живого” DVD. Другий спосіб простіший, тому я перегрузив комп’ютер з DVD та у консолі виконав такі команди (супер-блоки дисків sdc5, sdd5 та sda6 прийшлось також обнуляти, тому що я їх помилково додав у “запас” підчас спроб оживити цей RAID):

# mdadm --zero-superblock /dev/sdb5
# mdadm --zero-superblock /dev/sdc5
# mdadm --zero-superblock /dev/sdd5
# mdadm --zero-superblock /dev/sda6

Потім, перегрузивши комп’ютер, я виявив, що список RAID-пристроїв скоротився (/dev/md1 – зник!). Це добрий знак:

md3 : active raid5 sda8[0] sdc7[2] sdb7[1]
md2 : active raid1 sdd6[0] sdc6[2](S) sdb6[3](S) sda7[1]
md0 : active raid1 sdd1[0] sdc1[2](S) sdb1[3](S) sda3[1]

Спробуємо створити знову RAID-0. Але цього разу не з 2-х, а вже одразу з 4-х пристроїв. Резервні диски використовувати не будемо, бо як показав практичний досвід, на рівні RAID-0 від них ніякої користі.

# mdadm --create /dev/md1 --raid-devices=4 --level=raid0 /dev/sda6
 /dev/sdb5 /dev/sdc5 /dev/sdd5
mdadm: array /dev/md1 started.

# cat /proc/mdstat
...
md1 : active raid0 sdd5[3] sdc5[2] sdb5[1] sda6[0]
 7839232 blocks 64k chunks

Наче все добре, але тепер /dev/md1 слід спробувати задіяти як розід підкачки. За інформаціює з файлу /etc/fstab він і так використовується як swap:

# cat /etc/fstab
# /etc/fstab: static file system information.
# <file system> <mount point>   <type>  <options>    <dump>  <pass>
/dev/md1        none            swap    sw           0       0

Та він не задіяний:

$ free -m
        total       used       free     shared    buffers     cached
Mem:     3968       1590       2377          0        216        469
-/+ buffers/cache:        903       3064
Swap:            0          0          0

Так не виходить:

# swapon -a
swapon: /dev/md1: Invalid argument

Мабуть це тому, що на пристрої /dev/md1 не створено відповідну файлову систему. Але команда mkswap /dev/md1 теж повернула негативну відповідь. Чому – незнаю. Може для правильної роботи нового пристрою RAID слід повністю перезапустити його демон, або просто рестартанути комп’ютер. Але наступного разу, коли я завантажив Лінукс, ця команда спрацювала значно краще:

# mkswap /dev/md1
Setting up swapspace version 1, size = 8027369 kB
no label, UUID=0c1e26c3-8f75-4ab9-b08d-874694d33138

# swapon -a

# free -m
             total     used     free    shared   buffers    cached
Mem:          3968     3936       31         0       544      1027
-/+ buffers/cache:     2364     1603
Swap:         7655        0     7655

Заради чистого сумління треба ще раз перезавантажити Лінукс і на власні очі пересвідчитись, що помилки ініціалізації своп-розділу на програмному RAID-0 під час завантаження щезли.

Є ще одна задача, про яку часто забувають: це оновлення конфігураційного файлу /etc/mdadm/mdadm.conf. Зараз він містить точно не правдиві відомості про наш RAID-0 swap-розділ:

# definitions of existing MD arrays
ARRAY /dev/md1 level=raid0 num-devices=2
 UUID=c77a68cb:56309d8e:84c426df:55d8644d
...

А ми пам’ятаємо, що в нас він з 4-х пристроїв. Для того, щоб оновити цей файл достатньо виконати команду:

# mdadm --detail --scan
ARRAY /dev/md1 level=raid0 num-devices=4 metadata=00.90
 UUID=80b00a54:db3afd7e:999f1de2:f9c3448a
ARRAY /dev/md0 level=raid1 num-devices=2 metadata=00.90 spares=2
 UUID=0707ba7a:8a57b581:999f1de2:f9c3448a
ARRAY /dev/md2 level=raid1 num-devices=2 metadata=00.90 spares=2
 UUID=8bc941a1:d84faa98:008d3785:384a6334
ARRAY /dev/md3 level=raid5 num-devices=3 metadata=00.90 spares=1
 UUID=f82eca2a:4dadcb8a:84c426df:55d8644d

І відповідно виводу на екран відредагувати файл /etc/mdadm/mdadm.conf

Встановлення SETGID для усіх директорій рекурсивно

Іноді треба встановити SETGID (sticky-біт каталогу) для усіх директорій та піддиректорій. Така ситуація може виникнути, якщо необхідно забезпечити спільний доступ до певної файлової структури групі користувачів.

Поясню на прикладі. Уявімо, що є необхідність у спільній праці над проектами, які знаходяться у каталозі /var/local/Share. Усі задіяні у проектах належать групі workers.  Для цього каталогу встановлена група ‘workers’ та права 775, які дозволяють членам групи читати та записувати дані. Але якщо будь-хто з членів групи створить у ній каталог, то він буде належати не групі ‘workers’, а групі користувача за умовчанням.

Звичайно можна примусити користувачів змінювати власника групи, на те і команда chgrp існує, але біт SETGID позбавляє нас від цієї рутини. Якщо ми створюємо каталог у директорії зі встановленим SETGID, то автоматично маємо того самого власника групи, що і для батьківського каталогу. Тобто всі підкаталоги Share будуть належати групі ‘workers’. Більше того, вони також унаслідують і SETGID-біт, тому їх підкаталогу теж будуть належати до цієї групи.

Гадаю, що з новим каталогом усе зрозуміло, а як встановити SETGID біт для вже існуючої ієрархії каталогів?

Перше, що спадає на думку, це рекурсивна заміна власників групи та встановлення SETGID:

# chgrp -R workers /var/local/Share
# chmod -R g+s /var/local/Share     <-- НЕВІРНО!

Але друга команда неправильна. Бо вона встановлює SETGID не тільки для каталогів, але і для файлів, що зовсім не бажане. Відміняємо наслідки цієї команди протилежною:

# chmod -R g-s /var/local/Share

Та встановлюємо SETGID лише для каталогів:

# find /var/local/Share -type d -exec chmod g+s {} ;

Для нових дистрибутивів команда закінчується на плюс (+) замість крапки з комою (;)

# find /var/local/Share -type d -exec chmod g+s {} +