https://wiki.welard.com/api.php?action=feedcontributions&feedformat=atom&user=192.168.51.51&*Wiki Welard - Внесок користувача [uk]2026-10-27T23:41:03ZВнесок користувачаMediaWiki 1.34.1https://wiki.welard.com/index.php?title=Fstab&diff=2089Fstab2011-12-08T21:27:59Z<p>192.168.51.51: </p>
<hr />
<div>== Монтирование разделов по меткам в fstab (fstab mount linux label) ==<br />
<br />
Оригинал: http://ru.gentoo-wiki.com/wiki/Fstab<br />
[http://planetsecurity.org.ua/notes/sintaksis-fayla-fstab.html Синтаксис файла fstab] <br />
<br />
Введение<br />
--------<br />
<br />
/etc/fstab Конфигурационный файл с указанием партиции и ее точки<br />
монтирования в структуре файловой системы.<br />
<br />
Классическая схема конфигурации на основе шины описана в статье О<br />
монтировании файловых систем<br />
<br />
<br />
Уникальные идентификаторы<br />
<br />
<br />
Уникальная идентификация партиции и точное указание точки монтирования<br />
стало возможным при наличии udev и имеет некоторое превосходство над<br />
обозначением по положению на шине ide/scsi.<br />
<br />
Развитие Linux и udev увеличивает надежность опознания различных<br />
устройств, но в тоже время появляются новые проблемы.<br />
<br />
1. Если у вас больше одного sata/scsi или ide контроллера, то их<br />
обозначение при загрузке будет случайным. В результате после<br />
перезагрузки диск sdX может выглядеть как sdY или для ide дисков -<br />
hdX и hdY. Уникальная идентификация позволяет забыть о подобных<br />
мелочах.<br />
2. Введение новой libata pata поддержки, все ваши ide hdX диски будут<br />
видны как sdX устройства. Уникальная идентификация дисков и<br />
партиций позволит вам безболезненный переход.<br />
3. В компьютерах с наличием sata и ide контроллеров переход от hdX к<br />
sdX может внести путаницу, которую можно избежать при<br />
использовании идентификаторов.<br />
<br />
<br />
Четыре схемы уникальной идентификации<br />
<br />
<br />
Идентификация по UUID<br />
<br />
UUID это сокращение от слов Universally Unique IDentifier и описывает<br />
механизм выдачи каждой файловой системе уникального идентификатора.<br />
Все файловые системы в линуксе, включая swap, поддерживают UUID. FAT и<br />
NTFS не поддерживают UUID изначально, и тем не менее в линуксе им так<br />
же назначается UUID.<br />
<br />
ls -al /dev/disk/by-uuid/<br />
total 0<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 2f6e40d0-83b5-42dc-a102-b95bc32073dc<br />
-> ../../sda1<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 84e7c2c9-f26e-4e3f-98b8-93eec152cd5a<br />
-> ../../hdc5<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 867a5afb-f266-4a85-900f-efcc86004370<br />
-> ../../sda3<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 9542be4e-fe40-4ca9-9522-f5222d32ac84<br />
-> ../../sdb1<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 b15f438d-b4b7-4536-a8cc-46128f440c7c<br />
-> ../../hdc6<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 AF92-3DDB -> ../../sdd1<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 B0JC190ODC193954 -> ../../sdd6<br />
<br />
<br />
Как вы видите, FAT и NTFS разделы имеют укороченный идентификатор.<br />
<br />
Для определения UUID так же можно воспользоватся командой<br />
<br />
tune2fs -l /dev/sda1 | grep UUID<br />
<br />
Filesystem UUID: 2f6e40d0-83b5-42dc-a102-b95bc32073dc<br />
<br />
<br />
* Преимущества использования UUID: уникальность каждого раздела по<br />
идентификатору позволяет избежать ошибок при монтировании.<br />
<br />
<br />
* Недостаток использования UUID: трудно запомнить ;)<br />
<br />
<br />
<br />
Идентификация по LABEL<br />
<br />
<br />
Практически любой файловой системе или партиции можно присвоить LABEL<br />
(метку)<br />
<br />
ls -l /dev/disk/by-label/<br />
total 0<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 250gig -> ../../sdb1<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 b00t -> ../../sda1<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 level0 -> ../../sda3<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 p2p -> ../../hdc6<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 swap -> ../../hdc5<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 fat -> ../../sdd1<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 ntfs -> ../../sdd6<br />
<br />
<br />
Посмотреть названия так же можно командой cfdisk /dev/sda<br />
<br />
Для изменения label для каждой файловой системы выполните подходящие<br />
команды:<br />
swap: Создание новой swap партиции:<br />
mkswap -L <label> /dev/XXX<br />
<br />
<br />
ext2/ext3:<br />
e2label /dev/XXX <label><br />
<br />
<br />
reiserfs:<br />
reiserfstune -l <label> /dev/XXX<br />
<br />
jfs:<br />
jfs_tune -L <label> /dev/XXX<br />
<br />
<br />
xfs:<br />
xfs_admin -L <label> /dev/XXX<br />
<br />
<br />
fat/vfat: Изменить метку диска в Windows, или при создании раздела в линуксе<br />
<br />
mkdosfs -n <label> <other options>.<br />
<br />
назначение метки диску <br />
tune2fs -L HOME /dev/sda1 <br />
<br />
ntfs: Изменить метку диска в Windows или<br />
<br />
ntfslabel /dev/XXX <label><br />
<br />
<br />
Предупреждение: Будте внимательны при обозначении партиций. LABEL<br />
должен быть уникальным для каждого диска.<br />
<br />
<br />
Идентификация по id<br />
<br />
В данном случае id образуется из производственного серийного номера<br />
вашего диска.<br />
<br />
<br />
<br />
Идентификация по path<br />
<br />
<br />
Создание имени по кратчайшему пути (path) в соответствии с sysfs и<br />
содежит информацию о шине на которой расположен жесткий диск. Что не<br />
подходит для наших целей и решения вышеобозначенных проблем. Более<br />
подробно в статье О монтировании файловых систем<br />
<br />
<br />
Использование уникальных идентификаторов<br />
<br />
<br />
Я надеюсь вы уже определились какой метод вам понравился.<br />
Использование данных методов достаточно просто.<br />
<br />
<br />
fstab<br />
<br />
<br />
В /etc/fstab замените обозначение диска в первой колонке на ваш<br />
идентификатор к примеру, я закомментировал обозначение дисков по id<br />
знаком # и записал обозначение двух партиций по разным<br />
идентификационным схемам.<br />
<br />
/etc/fstab<br />
#/dev/sda1 /boot ext2 noauto,noatime 1 2<br />
LABEL=b00t /boot ext2 noauto,noatime 1 2<br />
#/dev/hdc5 none swap sw 0 0<br />
UUID=84e7c2c9-f26e-4e3f-98b8-93eec152cd5a none swap sw 0 0<br />
<br />
<br />
Так же можно заменить /dev/sda1 на /dev/disk/by-label/b00t или<br />
/dev/disk/by-uuid/2f6e40d0-83b5-42dc-a102-b95bc32073dc<br />
<br />
<br />
grub<br />
<br />
<br />
Предупреждение: Данное описание -- для Arch Linux. В Gentoo надо<br />
использовать genkernel и работает только указание корня через LABEL=<br />
(на данный момент)<br />
<br />
Для использования уникальных идентификаторов при загрузке необходимо:<br />
1. Использовать mkinitcpio initramfs образ<br />
2. Разрешить использование udev в /etc/mkinitcpio.conf<br />
3. Пересоздать initramfs образ до перезагрузки компьютера.<br />
<br />
Примечание: В версиях klibc-udev до 101-3 уникальное обозначение<br />
устройств не работает<br />
<br />
В приведенном выше примере партиция /dev/sda3 LABEL=level0 является<br />
root партицией и в файле /boot/grub/menu.lst запись<br />
<br />
/boot/grub/menu.lst<br />
<br />
kernel /boot/vmlinuz26 root=/dev/sda3 vga=0x318 ro<br />
<br />
<br />
надо поменять на<br />
/boot/grub/menu.lst<br />
<br />
kernel /boot/vmlinuz root=/dev/disk/by-label/level0 vga=0x318 ro<br />
<br />
<br />
или<br />
/boot/grub/menu.lst<br />
<br />
kernel /boot/vmlinuz root=LABEL=level0 vga=0x318 ro</div>192.168.51.51https://wiki.welard.com/index.php?title=Mtu&diff=2080Mtu2011-10-11T22:09:41Z<p>192.168.51.51: </p>
<hr />
<div>1. PPTP<br />
<br />
PPTP это полезный_TCP -> IP -> PPP -> GRE -> IP -> Ethernet<br />
Для Ethernet MTU=1500; заголовки IP -20 байт, заголовок GRE -4 байта, заголовок PPP -2 байта.<br />
<br />
Итого, MTU=1500-20-4-2=1474; MSS=MTU-40=1434<br />
<br />
2. Незашифрованный L2TP поверх IP<br />
<br />
L2TP это полезный_TCP -> IP -> PPP -> L2TP -> UDP -> IP -> Ethernet<br />
Для Ethernet MTU=1500; заголовки IP -20 байт, заголовки UDP -8 байт, заголовки L2TP -16 байт, заголовок PPP -2 байта.<br />
<br />
Итого, MTU=1500-20-8-16-2=1454; MSS=MTU-40=1414<br />
<br />
3. L2TP поверх IPSEC<br />
<br />
L2TP поверх IPSEC это полезный_TCP -> IP -> PPP -> L2TP -> UDP -> ESP -> IP -> Ethernet<br />
Получается то же самое, что и пункт 2, за вычетом размера заголовков ESP -20 байт.<br />
<br />
Итого, MTU=1454-20=1434; MSS=MTU-40=1394<br />
<br />
<br />
4. L2TP поверх IPSEC с NAT-Traversal<br />
Это полезный_TCP -> IP -> PPP -> L2TP -> UDP -> ESP -> IP -> UDP -> IP -> Ethernet<br />
<br />
Получается то же самое, что и пункт 3, за вычетом размера заголовков UDP -8 байт и IP -20 байт.<br />
<br />
Итого, MTU=1434-28=1406; MSS=MTU-40=1366<br />
<br />
[http://www.wandin.net/dotclear/index.php?post/2009/01/08/OpenVPN-MTU-Size OpenVPN-MTU-Size]<br />
<br />
[http://forum.ixbt.com/topic.cgi?id=14:49725 ixbt]</div>192.168.51.51https://wiki.welard.com/index.php?title=Mtu&diff=2079Mtu2011-10-11T22:07:32Z<p>192.168.51.51: </p>
<hr />
<div>1. PPTP<br />
<br />
PPTP это полезный_TCP -> IP -> PPP -> GRE -> IP -> Ethernet<br />
Для Ethernet MTU=1500; заголовки IP -20 байт, заголовок GRE -4 байта, заголовок PPP -2 байта.<br />
<br />
Итого, MTU=1500-20-4-2=1474; MSS=MTU-40=1434<br />
<br />
2. Незашифрованный L2TP поверх IP<br />
<br />
L2TP это полезный_TCP -> IP -> PPP -> L2TP -> UDP -> IP -> Ethernet<br />
Для Ethernet MTU=1500; заголовки IP -20 байт, заголовки UDP -8 байт, заголовки L2TP -16 байт, заголовок PPP -2 байта.<br />
<br />
Итого, MTU=1500-20-8-16-2=1454; MSS=MTU-40=1414<br />
<br />
3. L2TP поверх IPSEC<br />
<br />
L2TP поверх IPSEC это полезный_TCP -> IP -> PPP -> L2TP -> UDP -> ESP -> IP -> Ethernet<br />
Получается то же самое, что и пункт 2, за вычетом размера заголовков ESP -20 байт.<br />
<br />
Итого, MTU=1454-20=1434; MSS=MTU-40=1394<br />
<br />
<br />
4. L2TP поверх IPSEC с NAT-Traversal<br />
Это полезный_TCP -> IP -> PPP -> L2TP -> UDP -> ESP -> IP -> UDP -> IP -> Ethernet<br />
<br />
Получается то же самое, что и пункт 3, за вычетом размера заголовков UDP -8 байт и IP -20 байт.<br />
<br />
Итого, MTU=1434-28=1406; MSS=MTU-40=1366<br />
<br />
[http://www.wandin.net/dotclear/index.php?post/2009/01/08/OpenVPN-MTU-Size OpenVPN-MTU-Size]</div>192.168.51.51https://wiki.welard.com/index.php?title=Mtu&diff=2078Mtu2011-10-10T20:48:55Z<p>192.168.51.51: Created page with "1. PPTP PPTP это полезный_TCP -> IP -> PPP -> GRE -> IP -> Ethernet Для Ethernet MTU=1500; заголовки IP -20 байт, заголовок GRE -4 байта..."</p>
<hr />
<div>1. PPTP<br />
<br />
PPTP это полезный_TCP -> IP -> PPP -> GRE -> IP -> Ethernet<br />
Для Ethernet MTU=1500; заголовки IP -20 байт, заголовок GRE -4 байта, заголовок PPP -2 байта.<br />
<br />
Итого, MTU=1500-20-4-2=1474; MSS=MTU-40=1434<br />
<br />
2. Незашифрованный L2TP поверх IP<br />
<br />
L2TP это полезный_TCP -> IP -> PPP -> L2TP -> UDP -> IP -> Ethernet<br />
Для Ethernet MTU=1500; заголовки IP -20 байт, заголовки UDP -8 байт, заголовки L2TP -16 байт, заголовок PPP -2 байта.<br />
<br />
Итого, MTU=1500-20-8-16-2=1454; MSS=MTU-40=1414<br />
<br />
3. L2TP поверх IPSEC<br />
<br />
L2TP поверх IPSEC это полезный_TCP -> IP -> PPP -> L2TP -> UDP -> ESP -> IP -> Ethernet<br />
Получается то же самое, что и пункт 2, за вычетом размера заголовков ESP -20 байт.<br />
<br />
Итого, MTU=1454-20=1434; MSS=MTU-40=1394<br />
<br />
<br />
4. L2TP поверх IPSEC с NAT-Traversal<br />
Это полезный_TCP -> IP -> PPP -> L2TP -> UDP -> ESP -> IP -> UDP -> IP -> Ethernet<br />
<br />
Получается то же самое, что и пункт 3, за вычетом размера заголовков UDP -8 байт и IP -20 байт.<br />
<br />
Итого, MTU=1434-28=1406; MSS=MTU-40=1366</div>192.168.51.51https://wiki.welard.com/index.php?title=OpenVPN&diff=2077OpenVPN2011-10-10T20:47:32Z<p>192.168.51.51: </p>
<hr />
<div>[http://openmaniak.com/ru/openvpn_tutorial.php Установка OPENVPN] <br />
<br />
<br> <br />
<br />
== Настройка OpenVPN ==<br />
<br />
yum install openvpn<br />
cd /etc/openvpn/<br />
mkdir certs<br />
cd certs<br />
cp /usr/share/doc/openvpn/easy-rsa/2.0/* /etc/openvpn/certs/<br />
<br />
Дописуємо свох дані в кіці файлу vars <br />
<br />
. ../vars<br />
./clean-all<br />
<br />
Будуємо сертифікат <br />
<br />
./build-ca<br />
./build-dh<br />
<br />
Будуємо ключ для сервера <br />
<br />
./build-key-server server_name<br />
<br />
Будуємо ключ для клієнтів (на кожного клієнта по одному) <br />
<br />
./build-key client1 <br />
<br />
<br />
<br />
Налаштування /etc/openvpn/server.conf <br />
<pre>port 1194<br />
proto udp<br />
dev tun<br />
ca /etc/openvpn/certs/keys/ca.crt<br />
cert /etc/openvpn/certs/keys/CentOS.crt<br />
key /etc/openvpn/certs/keys/CentOS.key # This file should be kept secret<br />
<br />
dh /etc/openvpn/certs/keys/dh1024.pem<br />
<br />
server 172.16.51.0 255.255.255.0<br />
<br />
ifconfig-pool-persist ipp.txt<br />
;push "route 192.168.10.0 255.255.255.0"<br />
;push "route 192.168.20.0 255.255.255.0"<br />
<br />
#для того щоб клієнти бачили один одного<br />
client-to-client<br />
<br />
mssfix 1450<br />
fragment 1400<br />
<br />
keepalive 10 120<br />
<br />
comp-lzo<br />
;max-clients 100<br />
<br />
;user nobody<br />
;group nobody<br />
<br />
persist-key<br />
persist-tun<br />
<br />
status openvpn-status.log<br />
<br />
;log openvpn.log<br />
;log-append openvpn.log<br />
<br />
verb 3<br />
<br />
</pre><br />
<br />
Налаштування клієнта<br />
<pre><br />
client<br />
dev tun<br />
proto udp<br />
#proto tcp-client<br />
#Change my.publicdomain.com to your public domain or IP address<br />
remote 192.168.0.200 1194<br />
resolv-retry infinite<br />
nobind<br />
persist-key<br />
persist-tun<br />
<br />
ca ca2.crt<br />
cert user.crt<br />
key user.key<br />
ns-cert-type server<br />
<br />
#DNS Options here, CHANGE THESE !!<br />
#push "dhcp-option DNS 123.123.123.123"<br />
#push "dhcp-option DNS 123.123.123.124"<br />
comp-lzo<br />
tun-mtu 1500<br />
mssfix 1450<br />
fragment 1400<br />
verb 3<br />
</pre><br />
<br />
Заборонити клієнту доступ до сервера <br />
revoke-full <ім'я клієнта><br />
cp keys/crl.pem /etc/openvpn/<br />
<br />
== Проблема openvpn в операционной системе Vista ==<br />
<br />
1. Для того чтобы клиент openvpn заработал в windows vista необходимо добавить в конфиг файл клиентской части следующие строки:<br />
route-method exe<br />
route-delay 2<br />
<br />
2. Затем нужно создать bat файл следующего содержания:<br />
"C:\Program Files\OpenVPN\bin\openvpn.exe" "полный_путь_до_конфига"<br />
Для запуска VPN правой кнопкой мыши жмем на полученном bat файле и выбираем "Запустить как администратор"</div>192.168.51.51https://wiki.welard.com/index.php?title=Unformat_ntfs&diff=2066Unformat ntfs2011-09-15T16:39:45Z<p>192.168.51.51: </p>
<hr />
<div>[http://www.insidepro.com/kk/033/033r.shtml Оригинал] Unformat для NTFS &nbsp;Автор: (c)Крис Касперски ака мыщъх <br />
<br />
''Я у вас тут винчестер недавно купил. Так вот, он сдох!<br>- Гарантия какая?<br>- Пожизненная.<br>- Раз сдох, значит гарантия кончилась.''<br>'''(разговор продавца с покупателем)'''<br />
<br />
Случилось самое страшное: вы потеряли весь NTFS-раздел целиком, случайно отформатировали или пережили разрушительный дисковый сбой. Где-то там остались миллиарды байт бесценных данных, теперь уже недоступных операционной системе. Как вернуть информацию к жизни? В этой статье автор делится советами ручного и автоматического восстановления.<br />
<br />
Введение<br />
<br />
До сих пор мы рассматривали лишь незначительные дисковые сбои и легкие разрушения данных типа ошибочно удаленных файлов. Теперь настал черед тяжелых повреждений, при которых прежнее содержимое тома становится недоступно операционной системе. Причиной может быть и непредумышленное форматирование, и искажение главной файловой таблицы, и... Но вы не падайте духом! Из любых переделок NTFS выходит с минимальными потерями (легендарная надежность, как-никак, на то она и NTFS, а не FAT) и во всех этих случаях возможно полное, стопроцентное восстановление данных, если к делу подойти с головой и прямыми руками.<br />
<br />
Проще всего начать с форматирования. Для экспериментов нам потребуется format.com, входящий в комплект штатной поставки Windows NT/2000/XP и дисковый раздел, не содержащий ничего полезного. Хорошо бы обзавестись виртуальной машиной - Virtual PC или VMWare, эмулирующей жесткий диск и ускоряющей процедуру форматирования в сотни (!) раз. А ведь время - не только деньги, но и бесцельно прожитые годы, проведенные за созерцанием индикатора прогресса...<br />
<br />
"Живой" винчестер лучше не трогать (во всяком случае до тех пор, пока вы не научитесь его восстанавливать). Если нет виртуальной машины (до сих пор не поставили Осла? не пользуетесь IRC?), попробуйте приобрести ZIP-привод (который, кстати говоря, намного надежнее оптических накопителей) и форматируйте дискеты под NTFS - благо штатный форматер это позволяет. С гибкими дисками (флопами) дело обстоит сложнее. По мнению Microsoft, их емкости недостаточно для размещения всех структур данных, хотя простейший расчет разбивает это утверждение в пух и прах, что утилита NTFSflp от Марка Руссиновича (mark@sysinternals.com), собственно говоря, и демонстрирует. Статья "NTFS Support for Floppy Disks" ([http://www.sysinternals.com/ntw2k/freeware/ntfsfloppy.shtml ntfsfloppy]) подробно описывает, как обхитрить систему, заставив ее отформатировать гибкий диск под NTFS (для этого вам потребуется soft-ice).<br />
<br />
Форматирование виртуального диска<br />
<br />
<br><br />
[[image:image_1.jpg]]<br />
<br />
Рисунок 1. Форматирование виртуального диска в среде VMWare.<br><br />
<br />
== Что происходит при форматировании ==<br />
<br />
<br />
Форматирование диска - это сложная многостадийная операция, намного более сложная и намного более многостадийная, чем это может показаться на первый взгляд. Кто писал свой собственный форматер дискет (а в конце восьмидесятых-начале девяностых его писали практически все), тот поймет. Свои исследования мы начнем с изучения NTFS-тома, отформатированного под NTFS (техника восстановления NTFS-томов, отформатированных под FAT16/32 дана ниже).<br />
<br />
При выполнении команды "format X: /U /FS:NTFS" в файловой системе диска X: происходят следующие изменения (форматирование диска GUI-утилитой, вызываемой из контекстного меню "Проводника" осуществляется по аналогичной схеме):<br />
<br />
Формируется boot-сектор в формате NTFS;<br />
<br />
Генерируется новый серийный номер диска и записывается в boot-сектор по смещению 48h байт от его начала;<br />
<br />
Рассчитывается новая контрольная сумма boot-сектора и записывается по смещению 50h от его начала (подробнее см. первую статью этого цикла: "Загрузочный сектор - базовые концепции");<br />
<br />
Создается новый $MFT-файл, содержащий сведения обо всех файлах на диске и, как правило, размещаемый поверх старого $MFT-файла; исключения здесь крайне редки - разве что прежний $MFT был заблаговременно перемещен дефрагментатором или при форматировании назначен новый размер кластера. Во всех остальных случаях первые ~24 файловых записи (FILE Record) мрут безвозвратно. В них находится непосредственно сам $MFT, $MFTMirr, корневой каталог, /$LogFile - файл транзакций, /$BITMAP - карта свободного пространства, /$Secure - дескрипторы безопасности и другие служебные файлы;<br />
<br />
Инициируется $MFT:$DATA - назначается новая длина ($MFT:$30.AllocatedSize, $MFT:$30.RealSize, $MFT:$80.AllocatedSize, $MFT:$80.RealSize, $MFT:$80.CompressionSize, $MFT:$80.InitializedSize, $MFT:$80.LastVCN), дата/время создания/последней модификации ($MFT:$10.FileCreationTime, $MFT:$10.FileAlertedTime, $MFT:$10.FileReadTime, $MFT:$30.FileCreationTime, $MFT:$30.FileAlertedTime, $MFT:$30.MFTChangeTime, $MFT:$30.FileReadTime) и, самое главное, создается новый список отрезков (data-runs), необратимо затирающий старый, а это значит, что собирать фрагментированный $MFT нам придется по частям (эк, как тебя разворотило - укорял Василий Иванович Анку, в которую угодил артиллеристский снаряд);<br />
<br />
Создается новый /$MFT:$BITMAP, отвечающий за занятость файловых записей в MFT - все старые записи помечаются как свободные, однако их фактического удаления при этом не происходит (поле FileRecord.flags остается нетронутым), благодаря чему процедура восстановления заметно упрощается. Чаще всего $MFT:$BITMAP располагается на том же самом месте, что и старый (т.е. между boot-сектором и MFT), забивая прежнее содержимое нулями, однако с помощью утилиты chkdsk его можно восстановить;<br />
<br />
Создается новый /$BITMAP-файл, отвечающий за распределение дискового пространства (свободные и занятые кластера), опять-таки затирающий старый, но восстанавливаемый chkdsk'ом;<br />
<br />
Создается новый файл журнала транзакций - /$LogFile, в структуру которого мы углубляться все равно не будем, хотя в NTFS LINUX Project она описана достаточно подробно, но восстанавливать транзакции - это уж слишком; за восстановление транзакций нам никто не заплатит, так что нехай они идут лесом;<br />
<br />
В заголовок файловой записи $MFT заносится новый LogFile Sequence Number или, сокращенно, LSN;<br />
<br />
$MFT назначается новый номер последовательности обновления (Update Sequence Number);<br />
<br />
Создается новое зеркало $MFTMirr, необратимое затирающее старое (в текущих системах оно расположено посередине NTFS-раздела), в результате чего возникает резонный вопрос - на хрена нам зеркало, которое ничего не отражает?;<br />
<br />
Создаются новые /$Volume, /$AttrDef и другие служебные файлы, играющие сугубо вспомогательную роль и легко восстанавливаемые chkdsk'ом (хотя /$Volume и присутствует в зеркальной копии MFT, его ценность явно преувеличена);<br />
<br />
Осуществляется проверка целостности поверхности и все обнаруженные плохие кластеры заносятся в файл /$BadClus;<br />
<br />
Формируется новый корневой каталог;<br />
<br />
Если до форматирования тома на нем присутствовал /System Volume Information-файл, то он обновляется, в противном случае новый /System Volume Information создается только после перезагрузки;<br />
<br />
На самом деле процесс форматирования протекает намного сложнее, но не будем в него углубляться - мы же не форматер пишем! Интересующееся могут взять в руки IDA Pro и расковырять format.com самостоятельно. Подсказка - format.com содержит лишь высокоуровневую надстройку, опирающуюся на библиотеки ifsutil.dll, untfs.dll и... непосредственно сам драйвер файловой системы. Так что, дизассемблировать придется много. Чтобы упростить себе работу, можно пронаблюдать за процессом форматирования с помощью шпионских средств - утилит Марка Руссиновича FileMon и DiskMon, бесплатные копии которых можно скачать с www.sysinternals.com. Также не забывайте о точках останова на основные native-API функции такие как NtFsControlFile, NtDeviceIoControlFile и т.д. Да будет soft-ice вам в помощь!<br />
<br />
Исследование процесса форматирования<br />
<br />
[[image:image_2.jpg]]<br />
Рисунок 2. Исследование процесса форматирования с помощью шпионских средств.<br><br />
<br />
== Автоматическое восстановление отформатированного диска ==<br />
<br />
<br />
Форматирование не уничтожает файловые записи пользовательских файлов и они могут быть полностью восстановлены. Спасением данных занимается множество утилит (R-Studio, EasyRecovery, GetDataBack и т.д.), однако прямых наследников unformat'а среди них как-то не наблюдается. Unformat восстанавливал весь том целиком, а эти - всего лишь "вытягивают" отдельные уцелевшие файлы/каталоги, переписывая их на новый носитель. Да где же нам его взять?! Запись на оптические накопители отпадает сразу - во-первых, для сохранения 80 - 120 Гбайтного жесткого диска в лучшем случае потребуется грузовик (на чем еще вы перевезете такое количество болванок?), во-вторых, непосредственная запись CD-R/RW не всегда возможна, ведь при крахе системы восстанавливающие утилиты приходится загружать с CD-ROM, а в большинстве компьютеров установлен только один оптический привод, и, в-третьих, ни одна известная мне утилита не позволяет "разрезать" большие файлы на несколько маленьких. Можно, конечно, перегнать данные по локальной сети (а она есть?) или установить дополнительный винчестер (корпус компьютера не опечатан, имеется свободные каналы контроллера и лишняя наличность в кармане). Но не слишком ли это хлопотно? Тем не менее, для "вытягивая" пары сотен особо ценных файлов такая методика вполне подходит.<br />
<br />
Продемонстрируем технику автоматического восстановления данных на примере утилиты R-Studio от компании R-TT Inc (www.r-tt.com). Это довольно мощный и в тоже время простой в управлении инструмент, на который можно положиться. После запуска утилиты мы сразу попадаем в окно "Drive View", где перечислены все физические устройства и логические разделы. Находим среди них "свой" и, нажав правую клавишу мыши, говорим - "Scan".<br />
<br />
Нас спрашивают про начальный сектор для сканирования (start), по умолчанию равный 0 - оставляем его без изменений. Размер сканируемой области (size) по умолчанию развертывается на весь раздел. Это гарантирует, что сканер обнаружит все уцелевшие файловые записи, хотя сам поиск займет значительное время. Можно ли ускорить этот процесс? Давайте возьмем ручку и подсчитаем. Допустим, восстанавливаемый раздел содержит сто тысяч файлов. Типичный размер файловой записи составляет 1 Кбайт. При условии, что $MFT не фрагментирован, достаточно просканировать всего ~100 Мбайт от начала раздела. Если эта величина не превышает 10% полной емкости тома (размер пространства, зарезервированного под MFT) и диск никогда не заполнялся более чем на 90%, то, скорее всего, все так и есть. В противном случае $MFT наверняка фрагментирован и живописно разбросан по всему диску. Впрочем, в случае ошибки мы ничем не рискуем. Вводим N Кбайт, где N - предполагаемое кол-во файлов (каталог также считается файлом) и выполняем сканирование - если один или несколько файлов останутся необнаруженными, возвращаемся к настройкам по умолчанию и повторяем процедуру сканирования вновь (если количество имеющихся файлов заранее неизвестно, вводим 10% от емкости тома). В поле File System выбираем файловую систему NTFS, сбрасывая галочки напротив двух остальных (FAT и Ext2FS), т.к. они нам ни к чему, и нажимам "Scan".<br />
<br />
R-Studio<br />
[[image:image_3.jpg]]<br />
Рисунок 3. R-Studio осуществляет поиск уцелевших файловых записей.<br />
<br />
В процессе сканирования будут найдены все уцелевшие файлы (как удаленные, так и нет) и восстановлена структура директорий по корневой каталог включительно. Постойте! Как же так?! Ведь при форматировании он был уничтожен и сформирован заново! Хе-хе. Файловую систему NTFS можно уничтожить только динамитом. Как уже отмечалось, в отличии от FAT, в NTFS каталоги являются лишь вспомогательной структурой данных, проиндексированной для ускорения отображения их содержимого. Всякая файловая запись, независимо от своего происхождения, содержит ссылку на материнский каталог, представляющую собой номер записи в MFT. А запись корневого каталога всегда располагается по одному и тому же месту!<br />
<br />
Удаленные файловые записи могут ссылаться на уже уничтоженные каталоги. R-Studio складывает их в $$$FolderXXX, где XXX - порядковый номер директории. Иерархия подкаталогов в большинстве случаев успешно восстанавливается.<br />
<br />
Просмотр виртуального дерева обнаруженных файлов осуществляется нажатием кнопки &lt;F5&gt; или через одноименный пункт контекстного меню. Выбрав файл (или даже целый каталог с кучей подкаталогов) жмем &lt;F2&gt; или залезаем в предварительный просмотр/редактирование (пункт edit/view контекстного меню). Это достаточно мощный инструмент, отображающий внутреннее содержимое восстанавливаемого файла со всеми его атрибутами, списками отрезков и т.д. в "очеловеченном" формате, хотя до NT Exploder'а ему ох как далеко. При желании можно восстановить все файлы "за раз" ("Recovery All"), или выбрать восстановление по маске (Mask).<br />
<br />
Восстановленная структура директорий<br />
[[image:image_4.jpg]]<br />
Рисунок 4. Восстановленная структура директорий.<br />
<br />
Хваленный Easy Recovery от Data Recovery Software вопреки своему названию простотой управления отнюдь не отличается и имеет довольно специфические особенности поведения. С настройками по умолчанию никаких файлов на отформатированном разделе он не увидит и чтобы заставить этого зверюгу заработать в Advanced Options (дополнительные опции), необходимо указать Ignore MFT (игнорировать MFT), но и в этом случае качество восстановления будет оставлять желать лучшего.<br />
<br />
Красивый интерфейс Easy Recovery<br />
<br />
[[image:image_5.jpg]]<br />
Рисунок 5. Красивый интерфейс Easy Recovery - компенсация за низкое качество восстановления.<br>Ручное восстановление отформатированного диска<br />
<br />
Нашей целью будет ручное восстановление всего отформатированного раздела без использования дополнительных носителей информации и дорогостоящих утилит от сторонних производителей. Все, что потребуется - это любой редактор диска (предпочтительнее всего, конечно же, NT Explorer от Runtime Software, но на худой конец сойдет и бесплатный Disk Probe/Sector Inspector от Microsoft) и chkdsk.<br />
<br />
Очевидно, что в процессе форматирования происходит необратимое разрушение большого количества ключевых структур данных, восстанавливать которые вручную было бы слишком затруднительно. Да это, собственно, и не нужно! Идея состоит в том, чтобы вернуть разделу потерянные файловые записи, а все остальные ремонтные работы поручить chkdsk'у - пусть старается.<br />
<br />
Дизассемблирование показывает, что единственной структурой данных, без которой не может работать chkdsk, является атрибут $DATA файла $MFT. А раз так, все, что нам надо -воссоздать прежний $MFT:$DATA, разместив его поверх старых файловых записей. В простейшем случае (если $MFT:$DATA не фрагментирован) это достигается спекулятивным увеличением его длины. А как ее увеличить?<br />
<br />
Запускаем NT Explorer, переходим в начало MFT (Goto -&gt; Mft), щелкаем по $MFT файлу, находим атрибут $DATA (80h) и увеличиваем поля Allocated Size/Real Size/Compressed Size на требуемую величину, параллельно с этим корректируя список отрезков (он же run-list). Поле Last VCN трогать не нужно - chkdsk исправит его и сам. Как определить длину нефрагментированного MFT-файла? Она равна разнице номеров первого и последнего секторов, в начале которых присутствует сигнатура "FILE", умноженная на 512 байт (исключая сектора, принадлежащие $MFTMirr) Известные мне дисковые редакторы не поддерживают поиска последнего вхождения, поэтому соответствующую утилиту приходится писать самостоятельно. Впрочем, точную длину MFT определять совершенно необязательно и вполне допустимо взять ее с запасом - лишнее все равно отсеет chkdsk. Действуйте по принципу - лучше перебрать, чем недобрать.<br />
<br />
Ручное восстановление MFT<br />
[[image:image_6.jpg]]<br />
Рисунок 6. Ручное восстановление MFT. Подчеркнуты поля, подлежащие изменению.<br />
<br />
Коварный NT Explorer не позволяет редактировать поля в естественном режиме отображения, заставляя нас переключаться в HEX-mode и искать смещения всех значений самостоятельно. Найти заголовок атрибута $DATA очень просто - в его начале расположена последовательность 80 00 00 00 xx 00 00 00 01. В NTFS версии 3.0 она находится по смещению F8h от начала сектора. Поле Real Size во всех версиях NTFS располагается по смещению 30h относительно заголовка, а поля Allocated Size и Initialized Size, соответственно, по смещениям 28h/38h байт, причем значение Allocates Size должно быть кратно размеру кластера. Кстати, о кластерах. Убедитесь, что при переформатировании диска размер кластера не изменился, в противном случае у вас ничего не получится. Как восстановить исходный размер кластера? Да очень просто - набраться мужества и переформатировать восстанавливаемый диск с ключом /A:x, где x - размер кластера. А как его определить? Возьмем любой файл с известным содержимым и проанализируем его run-list. Пускаем контекстный поиск по всему диску, находим файл, запоминаем (записываем на бумажке) его стартовый сектор, после чего открываем закрепленный за ним FILE Record, декодируем run-list и вычисляем номер первого кластера. Делим номер сектора на номер кластера и получаем искомую величину.<br />
<br />
Теперь необходимо сгенерировать новый run-list. В общем случае он будет выглядеть так: 13 XX XX XX YY 00, где XX XX XX - трехбайтовый размер $MFT в кластерах, а YY - стартовый кластер. Стартовый кластер обязательно должен указывать на первый кластер MFT, в противном случае chkdsk не сможет работать. Если новый run-list длиннее нынешнего (а именно так, скорее всего, и будет) необходимо скорректировать длину атрибутного заголовка (она расположена по смещению 04h от его начала). Проделав эту нехитрую операцию, запустим chkdsk с ключом /F и блаженно откинемся на спинку кресла, созерцая как возрождаются наши милые папки и файлы. Единственное, что не восстанавливается - так это дескрипторы безопасности: всем файлам/папкам назначаются права доступа по умолчанию. В остальном же с отремонтированным диском вполне можно работать, не опасаясь, что он рухнет окончательно. Файлы, ссылающиеся на несуществующие каталоги складываются в папку Found.xxx. Это "долгожители", пережившие несколько циклов переформатирования, в буквальном смысле вытащенные с потустороннего света.<br />
<br />
Сложнее восстановить том, чей MFT сильно фрагментирован. Прежний run-list при форматировании был уничтожен, зеркальная копия также пострадала. Ничего другого не остается, как собирать все фрагменты руками. Звучит намного страшнее, чем выглядит. В отличии от всех остальных файлов диска, $MFT-файл имеет замечательную сигнатуру FILE, присутствующую в начале каждой файловой записи. Все, что нам нужно - последовательно сканируя раздел от первого кластера до последнего, выписать начало и конец каждого из фрагментов, принадлежащих MFT. Затем из этой цепочки необходимо исключить $MFTMirr. Его легко узнать - он расположен в середине раздела и содержит копии файловых записей $MFT, $MFTMirr, $LogFile и $Volume, причем $MFTMirr ссылается сам на себя. Допустим, наш список выглядит так: 08h - 333h, 669h - 966h, 1013 - 3210h. В грубом приближении ему будет соответствовать следующий run-list: 12 2B 03 08 22 23 03 69 96 22 FD 21 13 10 00. (Подробнее о кодировании/декодировании run-list'ов см. "Списки отрезков" в прошлой статье этого цикла).<br />
<br />
"В грубом", потому что мы не знаем, в какой последовательности располагались эти отрезки в файле (порядок расположения фрагментов на диске далеко не всегда совпадает с порядком отрезков в run-list'е). Что произойдет, если порядок сборки $MFT-файла окажется нарушен? А вот что - внутри MFT все файловые записи ссылаются друг на друга по своему порядковому номеру, представляющим индекс массива. Эти ссылки необходимы для восстановления структуры директорий, организации hard link'ов и еще кое-чего. Ссылки на материнский каталог дублируются в индексах и восстанавливаются элементарно. Hard link'и мрут безвозвратно (ну, разве что попробовать пересобрать $MFT-файл в другом порядке), но они практически нигде и никем не используются - как говорится, было бы что терять. По-настоящему туго приходится сильно фрагментированным файлам, занимающим несколько файловых записей, раскиданных по разным $MFT-фрагментам. Здесь выручает только перестановка фрагментов. К счастью, количество комбинаций обычно бывает невелико и процедура восстановления занимает совсем немного времени. Хорошая новость - начиная с NTFS версии 3.1 (соответствующей Windows XP) в MFT номера файловых записей хранятся в явном виде (четырехбайтовое поле, расположенное по смещению 2Ch от начала FILE Record), что делает задачу восстановления тривиальной.<br>Восстановление после тяжелых разрушений<br />
<br />
В результате сбоя содержимое дискового тома может стать недоступно операционной системе и при попытке чтения его оглавления будет выдаваться сообщения в стиле "Файл или папка повреждены. Чтение невозможно", "Нет доступа к диску", "Системе не удается найти логическое устройство" и т.д. Chkdsk говорит, что "Повреждена основная таблица файлов" и прекращает работу. Караул! Верните мой том! Пиво, водка и вобла гарантируется!<br />
<br />
Не паникуйте! Попробуйте запустить NT Explorer и посмотрите, что он покажет. Маловероятно, чтобы содержимое всего тома было утеряно целиком (это же что такое с ним нужно было сделать?!). Если хотя бы часть файловых записей уцелела, R-Studio/GetDataBack/EasyRecovery их обязательно восстановят!<br />
<br />
Анализ показывает, что основной причиной, по которой chkdsk отказывается проверять том, обычно становится порча файловой записи, описывающей $MFT. Если в процессе обновления $MFT внезапно отключить питание - такой исход событий вполне вероятен, особенно на жестких дисках с емким аппаратным кэшем - они не успевают завершить сохранение секторов на энергии, накопленной в конденсаторах, а вот их младшие собраться с этим справляются. То же самое происходит при неудачном перемещении $MFT файла или физическом разрушении первого MFT-сектора. Зеркальная копия $MFT во всех этих случаях остается цела, однако chkdsk по каким-то таинственным причинам не хочет ей пользоваться и вы должны восстановить ее самостоятельно. Просто скопируйте первый сектор $MFTMirr в первый сектор $MFT и громко скажите "ниндзя"! Поклонники Sector Inspector'а могут воспользоваться командным файлов следующего содержания.<br />
<br />
SECINSPECT.EXE -backup d: backup.dsk XXX 1<br>SECINSPECT.EXE -restore d: backup.dsk YYY CONFIRM<br />
<br />
Листинг 1. Командный файл для ручного восстановления $MFT из $MFTMirr, XXX - номер сектора $MFTMirr, YYY - номер сектора $MFT.<br />
<br />
Теперь можно смело пускать chkdsk. Если же он по-прежнему не работает, значит либо поврежден загрузочный сектор (а методику его восстановления мы уже обсуждали), либо run-list файла $MFT:$DATA не совпадает с истинным началом MFT (найдите сектор с файловой записью $MFT внутри и исправьте run-list), либо размер кластера, прописанный в boot-секторе отличается от его фактического размера (о том, как определять истинный размер кластера, мы уже только что говорили).<br />
<br />
Если же сбой был настолько серьезен, что вместе с $MFT пострадало и зеркало, задача сводится к восстановлению отформатированного диска. Кстати говоря, при тяжелых разрушениях файловой структуры, когда на диске образуется настоящий кавардак, восстановление тома полезно начинать с... его форматирования. Нет, это не первоапрельская шутка! Утилита format формирует заведомо исправные ключевые структуры, ну а подключение файловых записей - не проблема. Главное - сохраните run-list файла $MFT:$DATA, если, конечно, он еще уцелел. Все остальное - дело техники!<br />
<br />
Безуспешная попытка прочитать поврежденный том<br />
[[image:image_7.jpg]]<br />
Рисунок 7 Безуспешная попытка прочитать поврежденный том.<br>Восстановление NTFS-тома, отформатированного под FAT16/32<br />
<br />
При переформатировании диска, операционные системы семейства NT никогда не изменяют тип файловой системы (разве что попросить их это сделать явно), поэтому непреднамеренное форматирование NTFS раздела в FAT16/32 крайне маловероятно. Windows 9x/MS-DOS, напротив, любой диск стремятся отформатировать под FAT16/32, не замечая, что на нем что-то уже находится. Непреднамеренная порча NTFS-разделов при установке Windows 9x/MS-DOS поверх Windows NT - обычное дело, через которое проходит уже второе поколение пользователей.<br />
<br />
Стратегия спасения данных во всем похожа на восстановление NTFS-тома, отформатированного под NTFS, с той лишь разницей, что при создании таблицы размещения файлов (file allocation table) первые несколько тысяч файловых записей в MFT затираются безвозвратно (впрочем, их еще можно собрать руками, действуя по методике описанной в разделе "Разгребая кластерные обломки" предыдущей статьи этого цикла).<br />
<br />
Файлы с уцелевшей FILE RECORD легко восстанавливаются R-Studio/GetDataBack/EasyRecovery. Для ручного восстановления всего тома его необходимо заново отформатировать под NTFS, предварительно определив количество секторов в кластере. Далее действуем по плану - увеличиваем размер $MFT, пускаем chkdsk и собираем все, что только можно собрать. Поскольку количество файлов, хранящихся на современных дисках, зачастую исчисляется многими миллионами, потеря первой тысячи из них не так уж и страшна (если только по закону подлости это не будут самые ценные файлы).<br>Источники угрозы<br />
<br />
Почему погибают дисковые разделы? Ниже приводится список наиболее распространенных причини, отсортированный в порядке убывания их "популярности":<br />
<br />
Ошибки оператора, вирусы, троянские программы;<br />
<br />
Отключение питания/зависание системы во время интенсивных дисковых операций, сопровождаемых обновлением MFT (например, удаление/добавление файлов или каталогов);<br />
<br />
Некорректное поведение различных дисковых утилит (Partition Magic, Ahead Nero, Norton Disk Doctor и т.д.);<br />
<br />
Физические дефекты оперативной памяти, приводящие к нарушению целостности дискового кэша и как следствие - порче самого диска;<br />
<br />
Некорректное поведение привилегированных драйверов, случайно или преднамеренно "залетающих" внутрь служебных структур NTFS-драйвера;<br />
<br />
Полезные советы - план превентивных действий по спасению данных<br />
<br />
Чтобы предотвратить разрушение тома и упростить задачу восстановления данных, рекомендуется заблаговременно выполнить следующий комплекс мероприятий:<br />
<br />
Переместите $MFT подальше от начала раздела. Первые секторы раздела, как показывает практика, самое небезопасное место. Во-первых, сюда стремятся вирусы (миф о невозможности прямого доступа к диску под NT всего лишь миф - читайте описание функции CreateFile и инструкцию на ASPI32-драйвер), во-вторых, некоторые утилиты (и, в частности, Ahead Nero) при некоторых обстоятельствах путают жесткий диск с оптическим накопителем, записывая образ не "туда", а, значит, в первых ~700 Мбайтах физического диска (не логического тома!) не должно быть ничего ценного, в-третьих, если вы вдруг запустите WipeDisk или любую другую затирающую утилиту, первым погибнет именно $MFT, без которого весь дисковый том - просто груда мусора, в четвертых... да много разных причин можно найти. Просто переместите $MFT, вам что - трудно? Достаточно взять любой дефрагментатор, распространяющийся в исходных текстах (энтузиасты! ау! присоединяйтесь к проекту http://sourceforge.net/projects/opendefrag/) и слегка доработать его "напильником" под наши нужды. Естественно, валерьянка и резервная копия обязательно должны быть под рукой!<br />
<br />
Не допускайте фрагментации $MFT-файла! Не создавайте на диске огромного количества мелких файлов и не заполняйте его более чем на 90%. Стандартный дефрагментатор, входящий в комплект штатной поставки Windows 2000/XP, не позволяет дефрагментировать $MFT и приходится прибегать к сторонним средствам, лучшим из которых на мой взгляд является O&amp;O Defrag Pro от одноименной компании (www.oo-software.com). Это действительно профессиональный дефрагментатор, к тому же поддерживающий командную строку;<br />
<br />
Периодически создавайте резервную копию файловой записи $MFT - для этого достаточно сохранить один-единственный (!) сектор - первый сектор MFT, номер которого содержится в boot, только не забывайте его периодически обновлять, ведь при добавлении новых файлов/каталогов MFT планомерно расширяется и старые списки отрезков становятся все менее и менее актуальны;<br />
<br />
Нормальный дисковый том<br />
[[image:image_8.jpg]]<br />
Рисунок 8. Нормальный дисковый том (MFT, выделенный желтым цветом, расположен в начале раздела).<br />
<br />
Иммунизированный дисковый том<br />
[[image:image_9.jpg]]<br />
Рисунок 9. "Иммунизированный" дисковый том (MFT расположен в середине).<br>Заключение<br />
<br />
Наш затянувшийся разговор о восстановлении данных подходит к своему логическому концу, однако NTFS не стоит на месте, а интенсивно развирается. И хотя до сих пор эти изменения носили чисто косметический характер, в Windows Longhorn все обещает кардинальным образом измениться. Microsoft активно работает над новой файловой системой - Windows File System или сокращенно WinFS, сроки выхода которой, кстати говоря, постоянно переносятся (разработка файловой системы - это не шутка!).<br />
<br />
По словам вице-президента Microsoft Боба Маглиа, WinFS - это все та же NTFS, с прикрученным SQL и XML. Насколько изменятся базовые структуры файловой системы, общественности до сих пор неясно. И уж совсем непонятно, зачем NTFS понадобился реляционный SQL, когда эти возможности в нее закладывались изначально, просто их не успели доделать. Любой системный программист запросто напишет драйвер, принимающий SQL/XML запросы и транслирующий их в обращения к драйверу текущей файловой системы! Что-либо менять внутри NTFS совсем необязательно. Сдается мне, что это всего лишь очередной маркетинговый трюк, подталкивающих пользователей к переходу на ненавистный мне Longhorn!<br />
<br />
С другой стороны, развитие NTFS можно только приветствовать, поскольку оно дает пищу всем специалистам по восстановлению данных, ведь старые утилиты с новой файловой системой, скорей всего, окажутся несовместимы.<br></div>192.168.51.51https://wiki.welard.com/index.php?title=Windows&diff=2065Windows2011-09-15T16:37:22Z<p>192.168.51.51: </p>
<hr />
<div> [[Windows boot]]<br />
[[Keyboard|Keyboard]]<br />
[[Fixboot]]<br />
[[Thunderbird]]<br />
[[Terminal Server]]<br />
[[VirtualBox Network Fix]]<br />
[[Unformat_ntfs]]</div>192.168.51.51https://wiki.welard.com/index.php?title=Unformat_ntfs&diff=2064Unformat ntfs2011-09-15T13:32:34Z<p>192.168.51.51: </p>
<hr />
<div>[http://www.insidepro.com/kk/033/033r.shtml Оригинал] Unformat для NTFS &nbsp;Автор: (c)Крис Касперски ака мыщъх <br />
<br />
''Я у вас тут винчестер недавно купил. Так вот, он сдох!<br>- Гарантия какая?<br>- Пожизненная.<br>- Раз сдох, значит гарантия кончилась.''<br>'''(разговор продавца с покупателем)'''<br />
<br />
Случилось самое страшное: вы потеряли весь NTFS-раздел целиком, случайно отформатировали или пережили разрушительный дисковый сбой. Где-то там остались миллиарды байт бесценных данных, теперь уже недоступных операционной системе. Как вернуть информацию к жизни? В этой статье автор делится советами ручного и автоматического восстановления.<br />
<br />
Введение<br />
<br />
До сих пор мы рассматривали лишь незначительные дисковые сбои и легкие разрушения данных типа ошибочно удаленных файлов. Теперь настал черед тяжелых повреждений, при которых прежнее содержимое тома становится недоступно операционной системе. Причиной может быть и непредумышленное форматирование, и искажение главной файловой таблицы, и... Но вы не падайте духом! Из любых переделок NTFS выходит с минимальными потерями (легендарная надежность, как-никак, на то она и NTFS, а не FAT) и во всех этих случаях возможно полное, стопроцентное восстановление данных, если к делу подойти с головой и прямыми руками.<br />
<br />
Проще всего начать с форматирования. Для экспериментов нам потребуется format.com, входящий в комплект штатной поставки Windows NT/2000/XP и дисковый раздел, не содержащий ничего полезного. Хорошо бы обзавестись виртуальной машиной - Virtual PC или VMWare, эмулирующей жесткий диск и ускоряющей процедуру форматирования в сотни (!) раз. А ведь время - не только деньги, но и бесцельно прожитые годы, проведенные за созерцанием индикатора прогресса...<br />
<br />
"Живой" винчестер лучше не трогать (во всяком случае до тех пор, пока вы не научитесь его восстанавливать). Если нет виртуальной машины (до сих пор не поставили Осла? не пользуетесь IRC?), попробуйте приобрести ZIP-привод (который, кстати говоря, намного надежнее оптических накопителей) и форматируйте дискеты под NTFS - благо штатный форматер это позволяет. С гибкими дисками (флопами) дело обстоит сложнее. По мнению Microsoft, их емкости недостаточно для размещения всех структур данных, хотя простейший расчет разбивает это утверждение в пух и прах, что утилита NTFSflp от Марка Руссиновича (mark@sysinternals.com), собственно говоря, и демонстрирует. Статья "NTFS Support for Floppy Disks" ([http://www.sysinternals.com/ntw2k/freeware/ntfsfloppy.shtml ntfsfloppy]) подробно описывает, как обхитрить систему, заставив ее отформатировать гибкий диск под NTFS (для этого вам потребуется soft-ice).<br />
<br />
Форматирование виртуального диска<br />
<br />
<br><br />
[[File:image_1.jpg]]<br />
<br />
Рисунок 1. Форматирование виртуального диска в среде VMWare.<br><br />
<br />
== Что происходит при форматировании ==<br />
<br />
<br />
Форматирование диска - это сложная многостадийная операция, намного более сложная и намного более многостадийная, чем это может показаться на первый взгляд. Кто писал свой собственный форматер дискет (а в конце восьмидесятых-начале девяностых его писали практически все), тот поймет. Свои исследования мы начнем с изучения NTFS-тома, отформатированного под NTFS (техника восстановления NTFS-томов, отформатированных под FAT16/32 дана ниже).<br />
<br />
При выполнении команды "format X: /U /FS:NTFS" в файловой системе диска X: происходят следующие изменения (форматирование диска GUI-утилитой, вызываемой из контекстного меню "Проводника" осуществляется по аналогичной схеме):<br />
<br />
Формируется boot-сектор в формате NTFS;<br />
<br />
Генерируется новый серийный номер диска и записывается в boot-сектор по смещению 48h байт от его начала;<br />
<br />
Рассчитывается новая контрольная сумма boot-сектора и записывается по смещению 50h от его начала (подробнее см. первую статью этого цикла: "Загрузочный сектор - базовые концепции");<br />
<br />
Создается новый $MFT-файл, содержащий сведения обо всех файлах на диске и, как правило, размещаемый поверх старого $MFT-файла; исключения здесь крайне редки - разве что прежний $MFT был заблаговременно перемещен дефрагментатором или при форматировании назначен новый размер кластера. Во всех остальных случаях первые ~24 файловых записи (FILE Record) мрут безвозвратно. В них находится непосредственно сам $MFT, $MFTMirr, корневой каталог, /$LogFile - файл транзакций, /$BITMAP - карта свободного пространства, /$Secure - дескрипторы безопасности и другие служебные файлы;<br />
<br />
Инициируется $MFT:$DATA - назначается новая длина ($MFT:$30.AllocatedSize, $MFT:$30.RealSize, $MFT:$80.AllocatedSize, $MFT:$80.RealSize, $MFT:$80.CompressionSize, $MFT:$80.InitializedSize, $MFT:$80.LastVCN), дата/время создания/последней модификации ($MFT:$10.FileCreationTime, $MFT:$10.FileAlertedTime, $MFT:$10.FileReadTime, $MFT:$30.FileCreationTime, $MFT:$30.FileAlertedTime, $MFT:$30.MFTChangeTime, $MFT:$30.FileReadTime) и, самое главное, создается новый список отрезков (data-runs), необратимо затирающий старый, а это значит, что собирать фрагментированный $MFT нам придется по частям (эк, как тебя разворотило - укорял Василий Иванович Анку, в которую угодил артиллеристский снаряд);<br />
<br />
Создается новый /$MFT:$BITMAP, отвечающий за занятость файловых записей в MFT - все старые записи помечаются как свободные, однако их фактического удаления при этом не происходит (поле FileRecord.flags остается нетронутым), благодаря чему процедура восстановления заметно упрощается. Чаще всего $MFT:$BITMAP располагается на том же самом месте, что и старый (т.е. между boot-сектором и MFT), забивая прежнее содержимое нулями, однако с помощью утилиты chkdsk его можно восстановить;<br />
<br />
Создается новый /$BITMAP-файл, отвечающий за распределение дискового пространства (свободные и занятые кластера), опять-таки затирающий старый, но восстанавливаемый chkdsk'ом;<br />
<br />
Создается новый файл журнала транзакций - /$LogFile, в структуру которого мы углубляться все равно не будем, хотя в NTFS LINUX Project она описана достаточно подробно, но восстанавливать транзакции - это уж слишком; за восстановление транзакций нам никто не заплатит, так что нехай они идут лесом;<br />
<br />
В заголовок файловой записи $MFT заносится новый LogFile Sequence Number или, сокращенно, LSN;<br />
<br />
$MFT назначается новый номер последовательности обновления (Update Sequence Number);<br />
<br />
Создается новое зеркало $MFTMirr, необратимое затирающее старое (в текущих системах оно расположено посередине NTFS-раздела), в результате чего возникает резонный вопрос - на хрена нам зеркало, которое ничего не отражает?;<br />
<br />
Создаются новые /$Volume, /$AttrDef и другие служебные файлы, играющие сугубо вспомогательную роль и легко восстанавливаемые chkdsk'ом (хотя /$Volume и присутствует в зеркальной копии MFT, его ценность явно преувеличена);<br />
<br />
Осуществляется проверка целостности поверхности и все обнаруженные плохие кластеры заносятся в файл /$BadClus;<br />
<br />
Формируется новый корневой каталог;<br />
<br />
Если до форматирования тома на нем присутствовал /System Volume Information-файл, то он обновляется, в противном случае новый /System Volume Information создается только после перезагрузки;<br />
<br />
На самом деле процесс форматирования протекает намного сложнее, но не будем в него углубляться - мы же не форматер пишем! Интересующееся могут взять в руки IDA Pro и расковырять format.com самостоятельно. Подсказка - format.com содержит лишь высокоуровневую надстройку, опирающуюся на библиотеки ifsutil.dll, untfs.dll и... непосредственно сам драйвер файловой системы. Так что, дизассемблировать придется много. Чтобы упростить себе работу, можно пронаблюдать за процессом форматирования с помощью шпионских средств - утилит Марка Руссиновича FileMon и DiskMon, бесплатные копии которых можно скачать с www.sysinternals.com. Также не забывайте о точках останова на основные native-API функции такие как NtFsControlFile, NtDeviceIoControlFile и т.д. Да будет soft-ice вам в помощь!<br />
<br />
Исследование процесса форматирования<br />
<br />
[[File:image_2.jpg]]<br />
Рисунок 2. Исследование процесса форматирования с помощью шпионских средств.<br><br />
<br />
== Автоматическое восстановление отформатированного диска ==<br />
<br />
<br />
Форматирование не уничтожает файловые записи пользовательских файлов и они могут быть полностью восстановлены. Спасением данных занимается множество утилит (R-Studio, EasyRecovery, GetDataBack и т.д.), однако прямых наследников unformat'а среди них как-то не наблюдается. Unformat восстанавливал весь том целиком, а эти - всего лишь "вытягивают" отдельные уцелевшие файлы/каталоги, переписывая их на новый носитель. Да где же нам его взять?! Запись на оптические накопители отпадает сразу - во-первых, для сохранения 80 - 120 Гбайтного жесткого диска в лучшем случае потребуется грузовик (на чем еще вы перевезете такое количество болванок?), во-вторых, непосредственная запись CD-R/RW не всегда возможна, ведь при крахе системы восстанавливающие утилиты приходится загружать с CD-ROM, а в большинстве компьютеров установлен только один оптический привод, и, в-третьих, ни одна известная мне утилита не позволяет "разрезать" большие файлы на несколько маленьких. Можно, конечно, перегнать данные по локальной сети (а она есть?) или установить дополнительный винчестер (корпус компьютера не опечатан, имеется свободные каналы контроллера и лишняя наличность в кармане). Но не слишком ли это хлопотно? Тем не менее, для "вытягивая" пары сотен особо ценных файлов такая методика вполне подходит.<br />
<br />
Продемонстрируем технику автоматического восстановления данных на примере утилиты R-Studio от компании R-TT Inc (www.r-tt.com). Это довольно мощный и в тоже время простой в управлении инструмент, на который можно положиться. После запуска утилиты мы сразу попадаем в окно "Drive View", где перечислены все физические устройства и логические разделы. Находим среди них "свой" и, нажав правую клавишу мыши, говорим - "Scan".<br />
<br />
Нас спрашивают про начальный сектор для сканирования (start), по умолчанию равный 0 - оставляем его без изменений. Размер сканируемой области (size) по умолчанию развертывается на весь раздел. Это гарантирует, что сканер обнаружит все уцелевшие файловые записи, хотя сам поиск займет значительное время. Можно ли ускорить этот процесс? Давайте возьмем ручку и подсчитаем. Допустим, восстанавливаемый раздел содержит сто тысяч файлов. Типичный размер файловой записи составляет 1 Кбайт. При условии, что $MFT не фрагментирован, достаточно просканировать всего ~100 Мбайт от начала раздела. Если эта величина не превышает 10% полной емкости тома (размер пространства, зарезервированного под MFT) и диск никогда не заполнялся более чем на 90%, то, скорее всего, все так и есть. В противном случае $MFT наверняка фрагментирован и живописно разбросан по всему диску. Впрочем, в случае ошибки мы ничем не рискуем. Вводим N Кбайт, где N - предполагаемое кол-во файлов (каталог также считается файлом) и выполняем сканирование - если один или несколько файлов останутся необнаруженными, возвращаемся к настройкам по умолчанию и повторяем процедуру сканирования вновь (если количество имеющихся файлов заранее неизвестно, вводим 10% от емкости тома). В поле File System выбираем файловую систему NTFS, сбрасывая галочки напротив двух остальных (FAT и Ext2FS), т.к. они нам ни к чему, и нажимам "Scan".<br />
<br />
R-Studio<br />
[[File:image_3.jpg]]<br />
Рисунок 3. R-Studio осуществляет поиск уцелевших файловых записей.<br />
<br />
В процессе сканирования будут найдены все уцелевшие файлы (как удаленные, так и нет) и восстановлена структура директорий по корневой каталог включительно. Постойте! Как же так?! Ведь при форматировании он был уничтожен и сформирован заново! Хе-хе. Файловую систему NTFS можно уничтожить только динамитом. Как уже отмечалось, в отличии от FAT, в NTFS каталоги являются лишь вспомогательной структурой данных, проиндексированной для ускорения отображения их содержимого. Всякая файловая запись, независимо от своего происхождения, содержит ссылку на материнский каталог, представляющую собой номер записи в MFT. А запись корневого каталога всегда располагается по одному и тому же месту!<br />
<br />
Удаленные файловые записи могут ссылаться на уже уничтоженные каталоги. R-Studio складывает их в $$$FolderXXX, где XXX - порядковый номер директории. Иерархия подкаталогов в большинстве случаев успешно восстанавливается.<br />
<br />
Просмотр виртуального дерева обнаруженных файлов осуществляется нажатием кнопки &lt;F5&gt; или через одноименный пункт контекстного меню. Выбрав файл (или даже целый каталог с кучей подкаталогов) жмем &lt;F2&gt; или залезаем в предварительный просмотр/редактирование (пункт edit/view контекстного меню). Это достаточно мощный инструмент, отображающий внутреннее содержимое восстанавливаемого файла со всеми его атрибутами, списками отрезков и т.д. в "очеловеченном" формате, хотя до NT Exploder'а ему ох как далеко. При желании можно восстановить все файлы "за раз" ("Recovery All"), или выбрать восстановление по маске (Mask).<br />
<br />
Восстановленная структура директорий<br />
[[File:image_4.jpg]]<br />
Рисунок 4. Восстановленная структура директорий.<br />
<br />
Хваленный Easy Recovery от Data Recovery Software вопреки своему названию простотой управления отнюдь не отличается и имеет довольно специфические особенности поведения. С настройками по умолчанию никаких файлов на отформатированном разделе он не увидит и чтобы заставить этого зверюгу заработать в Advanced Options (дополнительные опции), необходимо указать Ignore MFT (игнорировать MFT), но и в этом случае качество восстановления будет оставлять желать лучшего.<br />
<br />
Красивый интерфейс Easy Recovery<br />
<br />
[[File:image_5.jpg]]<br />
Рисунок 5. Красивый интерфейс Easy Recovery - компенсация за низкое качество восстановления.<br>Ручное восстановление отформатированного диска<br />
<br />
Нашей целью будет ручное восстановление всего отформатированного раздела без использования дополнительных носителей информации и дорогостоящих утилит от сторонних производителей. Все, что потребуется - это любой редактор диска (предпочтительнее всего, конечно же, NT Explorer от Runtime Software, но на худой конец сойдет и бесплатный Disk Probe/Sector Inspector от Microsoft) и chkdsk.<br />
<br />
Очевидно, что в процессе форматирования происходит необратимое разрушение большого количества ключевых структур данных, восстанавливать которые вручную было бы слишком затруднительно. Да это, собственно, и не нужно! Идея состоит в том, чтобы вернуть разделу потерянные файловые записи, а все остальные ремонтные работы поручить chkdsk'у - пусть старается.<br />
<br />
Дизассемблирование показывает, что единственной структурой данных, без которой не может работать chkdsk, является атрибут $DATA файла $MFT. А раз так, все, что нам надо -воссоздать прежний $MFT:$DATA, разместив его поверх старых файловых записей. В простейшем случае (если $MFT:$DATA не фрагментирован) это достигается спекулятивным увеличением его длины. А как ее увеличить?<br />
<br />
Запускаем NT Explorer, переходим в начало MFT (Goto -&gt; Mft), щелкаем по $MFT файлу, находим атрибут $DATA (80h) и увеличиваем поля Allocated Size/Real Size/Compressed Size на требуемую величину, параллельно с этим корректируя список отрезков (он же run-list). Поле Last VCN трогать не нужно - chkdsk исправит его и сам. Как определить длину нефрагментированного MFT-файла? Она равна разнице номеров первого и последнего секторов, в начале которых присутствует сигнатура "FILE", умноженная на 512 байт (исключая сектора, принадлежащие $MFTMirr) Известные мне дисковые редакторы не поддерживают поиска последнего вхождения, поэтому соответствующую утилиту приходится писать самостоятельно. Впрочем, точную длину MFT определять совершенно необязательно и вполне допустимо взять ее с запасом - лишнее все равно отсеет chkdsk. Действуйте по принципу - лучше перебрать, чем недобрать.<br />
<br />
Ручное восстановление MFT<br />
[[File:image_6.jpg]]<br />
Рисунок 6. Ручное восстановление MFT. Подчеркнуты поля, подлежащие изменению.<br />
<br />
Коварный NT Explorer не позволяет редактировать поля в естественном режиме отображения, заставляя нас переключаться в HEX-mode и искать смещения всех значений самостоятельно. Найти заголовок атрибута $DATA очень просто - в его начале расположена последовательность 80 00 00 00 xx 00 00 00 01. В NTFS версии 3.0 она находится по смещению F8h от начала сектора. Поле Real Size во всех версиях NTFS располагается по смещению 30h относительно заголовка, а поля Allocated Size и Initialized Size, соответственно, по смещениям 28h/38h байт, причем значение Allocates Size должно быть кратно размеру кластера. Кстати, о кластерах. Убедитесь, что при переформатировании диска размер кластера не изменился, в противном случае у вас ничего не получится. Как восстановить исходный размер кластера? Да очень просто - набраться мужества и переформатировать восстанавливаемый диск с ключом /A:x, где x - размер кластера. А как его определить? Возьмем любой файл с известным содержимым и проанализируем его run-list. Пускаем контекстный поиск по всему диску, находим файл, запоминаем (записываем на бумажке) его стартовый сектор, после чего открываем закрепленный за ним FILE Record, декодируем run-list и вычисляем номер первого кластера. Делим номер сектора на номер кластера и получаем искомую величину.<br />
<br />
Теперь необходимо сгенерировать новый run-list. В общем случае он будет выглядеть так: 13 XX XX XX YY 00, где XX XX XX - трехбайтовый размер $MFT в кластерах, а YY - стартовый кластер. Стартовый кластер обязательно должен указывать на первый кластер MFT, в противном случае chkdsk не сможет работать. Если новый run-list длиннее нынешнего (а именно так, скорее всего, и будет) необходимо скорректировать длину атрибутного заголовка (она расположена по смещению 04h от его начала). Проделав эту нехитрую операцию, запустим chkdsk с ключом /F и блаженно откинемся на спинку кресла, созерцая как возрождаются наши милые папки и файлы. Единственное, что не восстанавливается - так это дескрипторы безопасности: всем файлам/папкам назначаются права доступа по умолчанию. В остальном же с отремонтированным диском вполне можно работать, не опасаясь, что он рухнет окончательно. Файлы, ссылающиеся на несуществующие каталоги складываются в папку Found.xxx. Это "долгожители", пережившие несколько циклов переформатирования, в буквальном смысле вытащенные с потустороннего света.<br />
<br />
Сложнее восстановить том, чей MFT сильно фрагментирован. Прежний run-list при форматировании был уничтожен, зеркальная копия также пострадала. Ничего другого не остается, как собирать все фрагменты руками. Звучит намного страшнее, чем выглядит. В отличии от всех остальных файлов диска, $MFT-файл имеет замечательную сигнатуру FILE, присутствующую в начале каждой файловой записи. Все, что нам нужно - последовательно сканируя раздел от первого кластера до последнего, выписать начало и конец каждого из фрагментов, принадлежащих MFT. Затем из этой цепочки необходимо исключить $MFTMirr. Его легко узнать - он расположен в середине раздела и содержит копии файловых записей $MFT, $MFTMirr, $LogFile и $Volume, причем $MFTMirr ссылается сам на себя. Допустим, наш список выглядит так: 08h - 333h, 669h - 966h, 1013 - 3210h. В грубом приближении ему будет соответствовать следующий run-list: 12 2B 03 08 22 23 03 69 96 22 FD 21 13 10 00. (Подробнее о кодировании/декодировании run-list'ов см. "Списки отрезков" в прошлой статье этого цикла).<br />
<br />
"В грубом", потому что мы не знаем, в какой последовательности располагались эти отрезки в файле (порядок расположения фрагментов на диске далеко не всегда совпадает с порядком отрезков в run-list'е). Что произойдет, если порядок сборки $MFT-файла окажется нарушен? А вот что - внутри MFT все файловые записи ссылаются друг на друга по своему порядковому номеру, представляющим индекс массива. Эти ссылки необходимы для восстановления структуры директорий, организации hard link'ов и еще кое-чего. Ссылки на материнский каталог дублируются в индексах и восстанавливаются элементарно. Hard link'и мрут безвозвратно (ну, разве что попробовать пересобрать $MFT-файл в другом порядке), но они практически нигде и никем не используются - как говорится, было бы что терять. По-настоящему туго приходится сильно фрагментированным файлам, занимающим несколько файловых записей, раскиданных по разным $MFT-фрагментам. Здесь выручает только перестановка фрагментов. К счастью, количество комбинаций обычно бывает невелико и процедура восстановления занимает совсем немного времени. Хорошая новость - начиная с NTFS версии 3.1 (соответствующей Windows XP) в MFT номера файловых записей хранятся в явном виде (четырехбайтовое поле, расположенное по смещению 2Ch от начала FILE Record), что делает задачу восстановления тривиальной.<br>Восстановление после тяжелых разрушений<br />
<br />
В результате сбоя содержимое дискового тома может стать недоступно операционной системе и при попытке чтения его оглавления будет выдаваться сообщения в стиле "Файл или папка повреждены. Чтение невозможно", "Нет доступа к диску", "Системе не удается найти логическое устройство" и т.д. Chkdsk говорит, что "Повреждена основная таблица файлов" и прекращает работу. Караул! Верните мой том! Пиво, водка и вобла гарантируется!<br />
<br />
Не паникуйте! Попробуйте запустить NT Explorer и посмотрите, что он покажет. Маловероятно, чтобы содержимое всего тома было утеряно целиком (это же что такое с ним нужно было сделать?!). Если хотя бы часть файловых записей уцелела, R-Studio/GetDataBack/EasyRecovery их обязательно восстановят!<br />
<br />
Анализ показывает, что основной причиной, по которой chkdsk отказывается проверять том, обычно становится порча файловой записи, описывающей $MFT. Если в процессе обновления $MFT внезапно отключить питание - такой исход событий вполне вероятен, особенно на жестких дисках с емким аппаратным кэшем - они не успевают завершить сохранение секторов на энергии, накопленной в конденсаторах, а вот их младшие собраться с этим справляются. То же самое происходит при неудачном перемещении $MFT файла или физическом разрушении первого MFT-сектора. Зеркальная копия $MFT во всех этих случаях остается цела, однако chkdsk по каким-то таинственным причинам не хочет ей пользоваться и вы должны восстановить ее самостоятельно. Просто скопируйте первый сектор $MFTMirr в первый сектор $MFT и громко скажите "ниндзя"! Поклонники Sector Inspector'а могут воспользоваться командным файлов следующего содержания.<br />
<br />
SECINSPECT.EXE -backup d: backup.dsk XXX 1<br>SECINSPECT.EXE -restore d: backup.dsk YYY CONFIRM<br />
<br />
Листинг 1. Командный файл для ручного восстановления $MFT из $MFTMirr, XXX - номер сектора $MFTMirr, YYY - номер сектора $MFT.<br />
<br />
Теперь можно смело пускать chkdsk. Если же он по-прежнему не работает, значит либо поврежден загрузочный сектор (а методику его восстановления мы уже обсуждали), либо run-list файла $MFT:$DATA не совпадает с истинным началом MFT (найдите сектор с файловой записью $MFT внутри и исправьте run-list), либо размер кластера, прописанный в boot-секторе отличается от его фактического размера (о том, как определять истинный размер кластера, мы уже только что говорили).<br />
<br />
Если же сбой был настолько серьезен, что вместе с $MFT пострадало и зеркало, задача сводится к восстановлению отформатированного диска. Кстати говоря, при тяжелых разрушениях файловой структуры, когда на диске образуется настоящий кавардак, восстановление тома полезно начинать с... его форматирования. Нет, это не первоапрельская шутка! Утилита format формирует заведомо исправные ключевые структуры, ну а подключение файловых записей - не проблема. Главное - сохраните run-list файла $MFT:$DATA, если, конечно, он еще уцелел. Все остальное - дело техники!<br />
<br />
Безуспешная попытка прочитать поврежденный том<br />
[[File:image_7.jpg]]<br />
Рисунок 7 Безуспешная попытка прочитать поврежденный том.<br>Восстановление NTFS-тома, отформатированного под FAT16/32<br />
<br />
При переформатировании диска, операционные системы семейства NT никогда не изменяют тип файловой системы (разве что попросить их это сделать явно), поэтому непреднамеренное форматирование NTFS раздела в FAT16/32 крайне маловероятно. Windows 9x/MS-DOS, напротив, любой диск стремятся отформатировать под FAT16/32, не замечая, что на нем что-то уже находится. Непреднамеренная порча NTFS-разделов при установке Windows 9x/MS-DOS поверх Windows NT - обычное дело, через которое проходит уже второе поколение пользователей.<br />
<br />
Стратегия спасения данных во всем похожа на восстановление NTFS-тома, отформатированного под NTFS, с той лишь разницей, что при создании таблицы размещения файлов (file allocation table) первые несколько тысяч файловых записей в MFT затираются безвозвратно (впрочем, их еще можно собрать руками, действуя по методике описанной в разделе "Разгребая кластерные обломки" предыдущей статьи этого цикла).<br />
<br />
Файлы с уцелевшей FILE RECORD легко восстанавливаются R-Studio/GetDataBack/EasyRecovery. Для ручного восстановления всего тома его необходимо заново отформатировать под NTFS, предварительно определив количество секторов в кластере. Далее действуем по плану - увеличиваем размер $MFT, пускаем chkdsk и собираем все, что только можно собрать. Поскольку количество файлов, хранящихся на современных дисках, зачастую исчисляется многими миллионами, потеря первой тысячи из них не так уж и страшна (если только по закону подлости это не будут самые ценные файлы).<br>Источники угрозы<br />
<br />
Почему погибают дисковые разделы? Ниже приводится список наиболее распространенных причини, отсортированный в порядке убывания их "популярности":<br />
<br />
Ошибки оператора, вирусы, троянские программы;<br />
<br />
Отключение питания/зависание системы во время интенсивных дисковых операций, сопровождаемых обновлением MFT (например, удаление/добавление файлов или каталогов);<br />
<br />
Некорректное поведение различных дисковых утилит (Partition Magic, Ahead Nero, Norton Disk Doctor и т.д.);<br />
<br />
Физические дефекты оперативной памяти, приводящие к нарушению целостности дискового кэша и как следствие - порче самого диска;<br />
<br />
Некорректное поведение привилегированных драйверов, случайно или преднамеренно "залетающих" внутрь служебных структур NTFS-драйвера;<br />
<br />
Полезные советы - план превентивных действий по спасению данных<br />
<br />
Чтобы предотвратить разрушение тома и упростить задачу восстановления данных, рекомендуется заблаговременно выполнить следующий комплекс мероприятий:<br />
<br />
Переместите $MFT подальше от начала раздела. Первые секторы раздела, как показывает практика, самое небезопасное место. Во-первых, сюда стремятся вирусы (миф о невозможности прямого доступа к диску под NT всего лишь миф - читайте описание функции CreateFile и инструкцию на ASPI32-драйвер), во-вторых, некоторые утилиты (и, в частности, Ahead Nero) при некоторых обстоятельствах путают жесткий диск с оптическим накопителем, записывая образ не "туда", а, значит, в первых ~700 Мбайтах физического диска (не логического тома!) не должно быть ничего ценного, в-третьих, если вы вдруг запустите WipeDisk или любую другую затирающую утилиту, первым погибнет именно $MFT, без которого весь дисковый том - просто груда мусора, в четвертых... да много разных причин можно найти. Просто переместите $MFT, вам что - трудно? Достаточно взять любой дефрагментатор, распространяющийся в исходных текстах (энтузиасты! ау! присоединяйтесь к проекту http://sourceforge.net/projects/opendefrag/) и слегка доработать его "напильником" под наши нужды. Естественно, валерьянка и резервная копия обязательно должны быть под рукой!<br />
<br />
Не допускайте фрагментации $MFT-файла! Не создавайте на диске огромного количества мелких файлов и не заполняйте его более чем на 90%. Стандартный дефрагментатор, входящий в комплект штатной поставки Windows 2000/XP, не позволяет дефрагментировать $MFT и приходится прибегать к сторонним средствам, лучшим из которых на мой взгляд является O&amp;O Defrag Pro от одноименной компании (www.oo-software.com). Это действительно профессиональный дефрагментатор, к тому же поддерживающий командную строку;<br />
<br />
Периодически создавайте резервную копию файловой записи $MFT - для этого достаточно сохранить один-единственный (!) сектор - первый сектор MFT, номер которого содержится в boot, только не забывайте его периодически обновлять, ведь при добавлении новых файлов/каталогов MFT планомерно расширяется и старые списки отрезков становятся все менее и менее актуальны;<br />
<br />
Нормальный дисковый том<br />
[[File:image_8.jpg]]<br />
Рисунок 8. Нормальный дисковый том (MFT, выделенный желтым цветом, расположен в начале раздела).<br />
<br />
Иммунизированный дисковый том<br />
[[File:image_9.jpg]]<br />
Рисунок 9. "Иммунизированный" дисковый том (MFT расположен в середине).<br>Заключение<br />
<br />
Наш затянувшийся разговор о восстановлении данных подходит к своему логическому концу, однако NTFS не стоит на месте, а интенсивно развирается. И хотя до сих пор эти изменения носили чисто косметический характер, в Windows Longhorn все обещает кардинальным образом измениться. Microsoft активно работает над новой файловой системой - Windows File System или сокращенно WinFS, сроки выхода которой, кстати говоря, постоянно переносятся (разработка файловой системы - это не шутка!).<br />
<br />
По словам вице-президента Microsoft Боба Маглиа, WinFS - это все та же NTFS, с прикрученным SQL и XML. Насколько изменятся базовые структуры файловой системы, общественности до сих пор неясно. И уж совсем непонятно, зачем NTFS понадобился реляционный SQL, когда эти возможности в нее закладывались изначально, просто их не успели доделать. Любой системный программист запросто напишет драйвер, принимающий SQL/XML запросы и транслирующий их в обращения к драйверу текущей файловой системы! Что-либо менять внутри NTFS совсем необязательно. Сдается мне, что это всего лишь очередной маркетинговый трюк, подталкивающих пользователей к переходу на ненавистный мне Longhorn!<br />
<br />
С другой стороны, развитие NTFS можно только приветствовать, поскольку оно дает пищу всем специалистам по восстановлению данных, ведь старые утилиты с новой файловой системой, скорей всего, окажутся несовместимы.<br></div>192.168.51.51https://wiki.welard.com/index.php?title=Unformat_ntfs&diff=2063Unformat ntfs2011-09-15T13:25:24Z<p>192.168.51.51: Created page with "[http://www.insidepro.com/kk/033/033r.shtml Оригинал] Unformat для NTFS &nbsp;Автор: (c)Крис Касперски ака мыщъх ''Я у вас тут ви..."</p>
<hr />
<div>[http://www.insidepro.com/kk/033/033r.shtml Оригинал] Unformat для NTFS &nbsp;Автор: (c)Крис Касперски ака мыщъх <br />
<br />
''Я у вас тут винчестер недавно купил. Так вот, он сдох!<br>- Гарантия какая?<br>- Пожизненная.<br>- Раз сдох, значит гарантия кончилась.''<br>'''(разговор продавца с покупателем)'''<br />
<br />
Случилось самое страшное: вы потеряли весь NTFS-раздел целиком, случайно отформатировали или пережили разрушительный дисковый сбой. Где-то там остались миллиарды байт бесценных данных, теперь уже недоступных операционной системе. Как вернуть информацию к жизни? В этой статье автор делится советами ручного и автоматического восстановления.<br />
<br />
Введение<br />
<br />
До сих пор мы рассматривали лишь незначительные дисковые сбои и легкие разрушения данных типа ошибочно удаленных файлов. Теперь настал черед тяжелых повреждений, при которых прежнее содержимое тома становится недоступно операционной системе. Причиной может быть и непредумышленное форматирование, и искажение главной файловой таблицы, и... Но вы не падайте духом! Из любых переделок NTFS выходит с минимальными потерями (легендарная надежность, как-никак, на то она и NTFS, а не FAT) и во всех этих случаях возможно полное, стопроцентное восстановление данных, если к делу подойти с головой и прямыми руками.<br />
<br />
Проще всего начать с форматирования. Для экспериментов нам потребуется format.com, входящий в комплект штатной поставки Windows NT/2000/XP и дисковый раздел, не содержащий ничего полезного. Хорошо бы обзавестись виртуальной машиной - Virtual PC или VMWare, эмулирующей жесткий диск и ускоряющей процедуру форматирования в сотни (!) раз. А ведь время - не только деньги, но и бесцельно прожитые годы, проведенные за созерцанием индикатора прогресса...<br />
<br />
"Живой" винчестер лучше не трогать (во всяком случае до тех пор, пока вы не научитесь его восстанавливать). Если нет виртуальной машины (до сих пор не поставили Осла? не пользуетесь IRC?), попробуйте приобрести ZIP-привод (который, кстати говоря, намного надежнее оптических накопителей) и форматируйте дискеты под NTFS - благо штатный форматер это позволяет. С гибкими дисками (флопами) дело обстоит сложнее. По мнению Microsoft, их емкости недостаточно для размещения всех структур данных, хотя простейший расчет разбивает это утверждение в пух и прах, что утилита NTFSflp от Марка Руссиновича (mark@sysinternals.com), собственно говоря, и демонстрирует. Статья "NTFS Support for Floppy Disks" ([http://www.sysinternals.com/ntw2k/freeware/ntfsfloppy.shtml ntfsfloppy]) подробно описывает, как обхитрить систему, заставив ее отформатировать гибкий диск под NTFS (для этого вам потребуется soft-ice).<br />
<br />
Форматирование виртуального диска<br />
<br />
<br><br />
<br />
Рисунок 1. Форматирование виртуального диска в среде VMWare.<br>Что происходит при форматировании<br />
<br />
Форматирование диска - это сложная многостадийная операция, намного более сложная и намного более многостадийная, чем это может показаться на первый взгляд. Кто писал свой собственный форматер дискет (а в конце восьмидесятых-начале девяностых его писали практически все), тот поймет. Свои исследования мы начнем с изучения NTFS-тома, отформатированного под NTFS (техника восстановления NTFS-томов, отформатированных под FAT16/32 дана ниже).<br />
<br />
При выполнении команды "format X: /U /FS:NTFS" в файловой системе диска X: происходят следующие изменения (форматирование диска GUI-утилитой, вызываемой из контекстного меню "Проводника" осуществляется по аналогичной схеме):<br />
<br />
Формируется boot-сектор в формате NTFS;<br />
<br />
Генерируется новый серийный номер диска и записывается в boot-сектор по смещению 48h байт от его начала;<br />
<br />
Рассчитывается новая контрольная сумма boot-сектора и записывается по смещению 50h от его начала (подробнее см. первую статью этого цикла: "Загрузочный сектор - базовые концепции");<br />
<br />
Создается новый $MFT-файл, содержащий сведения обо всех файлах на диске и, как правило, размещаемый поверх старого $MFT-файла; исключения здесь крайне редки - разве что прежний $MFT был заблаговременно перемещен дефрагментатором или при форматировании назначен новый размер кластера. Во всех остальных случаях первые ~24 файловых записи (FILE Record) мрут безвозвратно. В них находится непосредственно сам $MFT, $MFTMirr, корневой каталог, /$LogFile - файл транзакций, /$BITMAP - карта свободного пространства, /$Secure - дескрипторы безопасности и другие служебные файлы;<br />
<br />
Инициируется $MFT:$DATA - назначается новая длина ($MFT:$30.AllocatedSize, $MFT:$30.RealSize, $MFT:$80.AllocatedSize, $MFT:$80.RealSize, $MFT:$80.CompressionSize, $MFT:$80.InitializedSize, $MFT:$80.LastVCN), дата/время создания/последней модификации ($MFT:$10.FileCreationTime, $MFT:$10.FileAlertedTime, $MFT:$10.FileReadTime, $MFT:$30.FileCreationTime, $MFT:$30.FileAlertedTime, $MFT:$30.MFTChangeTime, $MFT:$30.FileReadTime) и, самое главное, создается новый список отрезков (data-runs), необратимо затирающий старый, а это значит, что собирать фрагментированный $MFT нам придется по частям (эк, как тебя разворотило - укорял Василий Иванович Анку, в которую угодил артиллеристский снаряд);<br />
<br />
Создается новый /$MFT:$BITMAP, отвечающий за занятость файловых записей в MFT - все старые записи помечаются как свободные, однако их фактического удаления при этом не происходит (поле FileRecord.flags остается нетронутым), благодаря чему процедура восстановления заметно упрощается. Чаще всего $MFT:$BITMAP располагается на том же самом месте, что и старый (т.е. между boot-сектором и MFT), забивая прежнее содержимое нулями, однако с помощью утилиты chkdsk его можно восстановить;<br />
<br />
Создается новый /$BITMAP-файл, отвечающий за распределение дискового пространства (свободные и занятые кластера), опять-таки затирающий старый, но восстанавливаемый chkdsk'ом;<br />
<br />
Создается новый файл журнала транзакций - /$LogFile, в структуру которого мы углубляться все равно не будем, хотя в NTFS LINUX Project она описана достаточно подробно, но восстанавливать транзакции - это уж слишком; за восстановление транзакций нам никто не заплатит, так что нехай они идут лесом;<br />
<br />
В заголовок файловой записи $MFT заносится новый LogFile Sequence Number или, сокращенно, LSN;<br />
<br />
$MFT назначается новый номер последовательности обновления (Update Sequence Number);<br />
<br />
Создается новое зеркало $MFTMirr, необратимое затирающее старое (в текущих системах оно расположено посередине NTFS-раздела), в результате чего возникает резонный вопрос - на хрена нам зеркало, которое ничего не отражает?;<br />
<br />
Создаются новые /$Volume, /$AttrDef и другие служебные файлы, играющие сугубо вспомогательную роль и легко восстанавливаемые chkdsk'ом (хотя /$Volume и присутствует в зеркальной копии MFT, его ценность явно преувеличена);<br />
<br />
Осуществляется проверка целостности поверхности и все обнаруженные плохие кластеры заносятся в файл /$BadClus;<br />
<br />
Формируется новый корневой каталог;<br />
<br />
Если до форматирования тома на нем присутствовал /System Volume Information-файл, то он обновляется, в противном случае новый /System Volume Information создается только после перезагрузки;<br />
<br />
На самом деле процесс форматирования протекает намного сложнее, но не будем в него углубляться - мы же не форматер пишем! Интересующееся могут взять в руки IDA Pro и расковырять format.com самостоятельно. Подсказка - format.com содержит лишь высокоуровневую надстройку, опирающуюся на библиотеки ifsutil.dll, untfs.dll и... непосредственно сам драйвер файловой системы. Так что, дизассемблировать придется много. Чтобы упростить себе работу, можно пронаблюдать за процессом форматирования с помощью шпионских средств - утилит Марка Руссиновича FileMon и DiskMon, бесплатные копии которых можно скачать с www.sysinternals.com. Также не забывайте о точках останова на основные native-API функции такие как NtFsControlFile, NtDeviceIoControlFile и т.д. Да будет soft-ice вам в помощь!<br />
<br />
Исследование процесса форматирования<br />
<br />
Рисунок 2. Исследование процесса форматирования с помощью шпионских средств.<br>Автоматическое восстановление отформатированного диска<br />
<br />
Форматирование не уничтожает файловые записи пользовательских файлов и они могут быть полностью восстановлены. Спасением данных занимается множество утилит (R-Studio, EasyRecovery, GetDataBack и т.д.), однако прямых наследников unformat'а среди них как-то не наблюдается. Unformat восстанавливал весь том целиком, а эти - всего лишь "вытягивают" отдельные уцелевшие файлы/каталоги, переписывая их на новый носитель. Да где же нам его взять?! Запись на оптические накопители отпадает сразу - во-первых, для сохранения 80 - 120 Гбайтного жесткого диска в лучшем случае потребуется грузовик (на чем еще вы перевезете такое количество болванок?), во-вторых, непосредственная запись CD-R/RW не всегда возможна, ведь при крахе системы восстанавливающие утилиты приходится загружать с CD-ROM, а в большинстве компьютеров установлен только один оптический привод, и, в-третьих, ни одна известная мне утилита не позволяет "разрезать" большие файлы на несколько маленьких. Можно, конечно, перегнать данные по локальной сети (а она есть?) или установить дополнительный винчестер (корпус компьютера не опечатан, имеется свободные каналы контроллера и лишняя наличность в кармане). Но не слишком ли это хлопотно? Тем не менее, для "вытягивая" пары сотен особо ценных файлов такая методика вполне подходит.<br />
<br />
Продемонстрируем технику автоматического восстановления данных на примере утилиты R-Studio от компании R-TT Inc (www.r-tt.com). Это довольно мощный и в тоже время простой в управлении инструмент, на который можно положиться. После запуска утилиты мы сразу попадаем в окно "Drive View", где перечислены все физические устройства и логические разделы. Находим среди них "свой" и, нажав правую клавишу мыши, говорим - "Scan".<br />
<br />
Нас спрашивают про начальный сектор для сканирования (start), по умолчанию равный 0 - оставляем его без изменений. Размер сканируемой области (size) по умолчанию развертывается на весь раздел. Это гарантирует, что сканер обнаружит все уцелевшие файловые записи, хотя сам поиск займет значительное время. Можно ли ускорить этот процесс? Давайте возьмем ручку и подсчитаем. Допустим, восстанавливаемый раздел содержит сто тысяч файлов. Типичный размер файловой записи составляет 1 Кбайт. При условии, что $MFT не фрагментирован, достаточно просканировать всего ~100 Мбайт от начала раздела. Если эта величина не превышает 10% полной емкости тома (размер пространства, зарезервированного под MFT) и диск никогда не заполнялся более чем на 90%, то, скорее всего, все так и есть. В противном случае $MFT наверняка фрагментирован и живописно разбросан по всему диску. Впрочем, в случае ошибки мы ничем не рискуем. Вводим N Кбайт, где N - предполагаемое кол-во файлов (каталог также считается файлом) и выполняем сканирование - если один или несколько файлов останутся необнаруженными, возвращаемся к настройкам по умолчанию и повторяем процедуру сканирования вновь (если количество имеющихся файлов заранее неизвестно, вводим 10% от емкости тома). В поле File System выбираем файловую систему NTFS, сбрасывая галочки напротив двух остальных (FAT и Ext2FS), т.к. они нам ни к чему, и нажимам "Scan".<br />
<br />
R-Studio<br />
<br />
Рисунок 3. R-Studio осуществляет поиск уцелевших файловых записей.<br />
<br />
В процессе сканирования будут найдены все уцелевшие файлы (как удаленные, так и нет) и восстановлена структура директорий по корневой каталог включительно. Постойте! Как же так?! Ведь при форматировании он был уничтожен и сформирован заново! Хе-хе. Файловую систему NTFS можно уничтожить только динамитом. Как уже отмечалось, в отличии от FAT, в NTFS каталоги являются лишь вспомогательной структурой данных, проиндексированной для ускорения отображения их содержимого. Всякая файловая запись, независимо от своего происхождения, содержит ссылку на материнский каталог, представляющую собой номер записи в MFT. А запись корневого каталога всегда располагается по одному и тому же месту!<br />
<br />
Удаленные файловые записи могут ссылаться на уже уничтоженные каталоги. R-Studio складывает их в $$$FolderXXX, где XXX - порядковый номер директории. Иерархия подкаталогов в большинстве случаев успешно восстанавливается.<br />
<br />
Просмотр виртуального дерева обнаруженных файлов осуществляется нажатием кнопки &lt;F5&gt; или через одноименный пункт контекстного меню. Выбрав файл (или даже целый каталог с кучей подкаталогов) жмем &lt;F2&gt; или залезаем в предварительный просмотр/редактирование (пункт edit/view контекстного меню). Это достаточно мощный инструмент, отображающий внутреннее содержимое восстанавливаемого файла со всеми его атрибутами, списками отрезков и т.д. в "очеловеченном" формате, хотя до NT Exploder'а ему ох как далеко. При желании можно восстановить все файлы "за раз" ("Recovery All"), или выбрать восстановление по маске (Mask).<br />
<br />
Восстановленная структура директорий<br />
<br />
Рисунок 4. Восстановленная структура директорий.<br />
<br />
Хваленный Easy Recovery от Data Recovery Software вопреки своему названию простотой управления отнюдь не отличается и имеет довольно специфические особенности поведения. С настройками по умолчанию никаких файлов на отформатированном разделе он не увидит и чтобы заставить этого зверюгу заработать в Advanced Options (дополнительные опции), необходимо указать Ignore MFT (игнорировать MFT), но и в этом случае качество восстановления будет оставлять желать лучшего.<br />
<br />
Красивый интерфейс Easy Recovery<br />
<br />
Рисунок 5. Красивый интерфейс Easy Recovery - компенсация за низкое качество восстановления.<br>Ручное восстановление отформатированного диска<br />
<br />
Нашей целью будет ручное восстановление всего отформатированного раздела без использования дополнительных носителей информации и дорогостоящих утилит от сторонних производителей. Все, что потребуется - это любой редактор диска (предпочтительнее всего, конечно же, NT Explorer от Runtime Software, но на худой конец сойдет и бесплатный Disk Probe/Sector Inspector от Microsoft) и chkdsk.<br />
<br />
Очевидно, что в процессе форматирования происходит необратимое разрушение большого количества ключевых структур данных, восстанавливать которые вручную было бы слишком затруднительно. Да это, собственно, и не нужно! Идея состоит в том, чтобы вернуть разделу потерянные файловые записи, а все остальные ремонтные работы поручить chkdsk'у - пусть старается.<br />
<br />
Дизассемблирование показывает, что единственной структурой данных, без которой не может работать chkdsk, является атрибут $DATA файла $MFT. А раз так, все, что нам надо -воссоздать прежний $MFT:$DATA, разместив его поверх старых файловых записей. В простейшем случае (если $MFT:$DATA не фрагментирован) это достигается спекулятивным увеличением его длины. А как ее увеличить?<br />
<br />
Запускаем NT Explorer, переходим в начало MFT (Goto -&gt; Mft), щелкаем по $MFT файлу, находим атрибут $DATA (80h) и увеличиваем поля Allocated Size/Real Size/Compressed Size на требуемую величину, параллельно с этим корректируя список отрезков (он же run-list). Поле Last VCN трогать не нужно - chkdsk исправит его и сам. Как определить длину нефрагментированного MFT-файла? Она равна разнице номеров первого и последнего секторов, в начале которых присутствует сигнатура "FILE", умноженная на 512 байт (исключая сектора, принадлежащие $MFTMirr) Известные мне дисковые редакторы не поддерживают поиска последнего вхождения, поэтому соответствующую утилиту приходится писать самостоятельно. Впрочем, точную длину MFT определять совершенно необязательно и вполне допустимо взять ее с запасом - лишнее все равно отсеет chkdsk. Действуйте по принципу - лучше перебрать, чем недобрать.<br />
<br />
Ручное восстановление MFT<br />
<br />
Рисунок 6. Ручное восстановление MFT. Подчеркнуты поля, подлежащие изменению.<br />
<br />
Коварный NT Explorer не позволяет редактировать поля в естественном режиме отображения, заставляя нас переключаться в HEX-mode и искать смещения всех значений самостоятельно. Найти заголовок атрибута $DATA очень просто - в его начале расположена последовательность 80 00 00 00 xx 00 00 00 01. В NTFS версии 3.0 она находится по смещению F8h от начала сектора. Поле Real Size во всех версиях NTFS располагается по смещению 30h относительно заголовка, а поля Allocated Size и Initialized Size, соответственно, по смещениям 28h/38h байт, причем значение Allocates Size должно быть кратно размеру кластера. Кстати, о кластерах. Убедитесь, что при переформатировании диска размер кластера не изменился, в противном случае у вас ничего не получится. Как восстановить исходный размер кластера? Да очень просто - набраться мужества и переформатировать восстанавливаемый диск с ключом /A:x, где x - размер кластера. А как его определить? Возьмем любой файл с известным содержимым и проанализируем его run-list. Пускаем контекстный поиск по всему диску, находим файл, запоминаем (записываем на бумажке) его стартовый сектор, после чего открываем закрепленный за ним FILE Record, декодируем run-list и вычисляем номер первого кластера. Делим номер сектора на номер кластера и получаем искомую величину.<br />
<br />
Теперь необходимо сгенерировать новый run-list. В общем случае он будет выглядеть так: 13 XX XX XX YY 00, где XX XX XX - трехбайтовый размер $MFT в кластерах, а YY - стартовый кластер. Стартовый кластер обязательно должен указывать на первый кластер MFT, в противном случае chkdsk не сможет работать. Если новый run-list длиннее нынешнего (а именно так, скорее всего, и будет) необходимо скорректировать длину атрибутного заголовка (она расположена по смещению 04h от его начала). Проделав эту нехитрую операцию, запустим chkdsk с ключом /F и блаженно откинемся на спинку кресла, созерцая как возрождаются наши милые папки и файлы. Единственное, что не восстанавливается - так это дескрипторы безопасности: всем файлам/папкам назначаются права доступа по умолчанию. В остальном же с отремонтированным диском вполне можно работать, не опасаясь, что он рухнет окончательно. Файлы, ссылающиеся на несуществующие каталоги складываются в папку Found.xxx. Это "долгожители", пережившие несколько циклов переформатирования, в буквальном смысле вытащенные с потустороннего света.<br />
<br />
Сложнее восстановить том, чей MFT сильно фрагментирован. Прежний run-list при форматировании был уничтожен, зеркальная копия также пострадала. Ничего другого не остается, как собирать все фрагменты руками. Звучит намного страшнее, чем выглядит. В отличии от всех остальных файлов диска, $MFT-файл имеет замечательную сигнатуру FILE, присутствующую в начале каждой файловой записи. Все, что нам нужно - последовательно сканируя раздел от первого кластера до последнего, выписать начало и конец каждого из фрагментов, принадлежащих MFT. Затем из этой цепочки необходимо исключить $MFTMirr. Его легко узнать - он расположен в середине раздела и содержит копии файловых записей $MFT, $MFTMirr, $LogFile и $Volume, причем $MFTMirr ссылается сам на себя. Допустим, наш список выглядит так: 08h - 333h, 669h - 966h, 1013 - 3210h. В грубом приближении ему будет соответствовать следующий run-list: 12 2B 03 08 22 23 03 69 96 22 FD 21 13 10 00. (Подробнее о кодировании/декодировании run-list'ов см. "Списки отрезков" в прошлой статье этого цикла).<br />
<br />
"В грубом", потому что мы не знаем, в какой последовательности располагались эти отрезки в файле (порядок расположения фрагментов на диске далеко не всегда совпадает с порядком отрезков в run-list'е). Что произойдет, если порядок сборки $MFT-файла окажется нарушен? А вот что - внутри MFT все файловые записи ссылаются друг на друга по своему порядковому номеру, представляющим индекс массива. Эти ссылки необходимы для восстановления структуры директорий, организации hard link'ов и еще кое-чего. Ссылки на материнский каталог дублируются в индексах и восстанавливаются элементарно. Hard link'и мрут безвозвратно (ну, разве что попробовать пересобрать $MFT-файл в другом порядке), но они практически нигде и никем не используются - как говорится, было бы что терять. По-настоящему туго приходится сильно фрагментированным файлам, занимающим несколько файловых записей, раскиданных по разным $MFT-фрагментам. Здесь выручает только перестановка фрагментов. К счастью, количество комбинаций обычно бывает невелико и процедура восстановления занимает совсем немного времени. Хорошая новость - начиная с NTFS версии 3.1 (соответствующей Windows XP) в MFT номера файловых записей хранятся в явном виде (четырехбайтовое поле, расположенное по смещению 2Ch от начала FILE Record), что делает задачу восстановления тривиальной.<br>Восстановление после тяжелых разрушений<br />
<br />
В результате сбоя содержимое дискового тома может стать недоступно операционной системе и при попытке чтения его оглавления будет выдаваться сообщения в стиле "Файл или папка повреждены. Чтение невозможно", "Нет доступа к диску", "Системе не удается найти логическое устройство" и т.д. Chkdsk говорит, что "Повреждена основная таблица файлов" и прекращает работу. Караул! Верните мой том! Пиво, водка и вобла гарантируется!<br />
<br />
Не паникуйте! Попробуйте запустить NT Explorer и посмотрите, что он покажет. Маловероятно, чтобы содержимое всего тома было утеряно целиком (это же что такое с ним нужно было сделать?!). Если хотя бы часть файловых записей уцелела, R-Studio/GetDataBack/EasyRecovery их обязательно восстановят!<br />
<br />
Анализ показывает, что основной причиной, по которой chkdsk отказывается проверять том, обычно становится порча файловой записи, описывающей $MFT. Если в процессе обновления $MFT внезапно отключить питание - такой исход событий вполне вероятен, особенно на жестких дисках с емким аппаратным кэшем - они не успевают завершить сохранение секторов на энергии, накопленной в конденсаторах, а вот их младшие собраться с этим справляются. То же самое происходит при неудачном перемещении $MFT файла или физическом разрушении первого MFT-сектора. Зеркальная копия $MFT во всех этих случаях остается цела, однако chkdsk по каким-то таинственным причинам не хочет ей пользоваться и вы должны восстановить ее самостоятельно. Просто скопируйте первый сектор $MFTMirr в первый сектор $MFT и громко скажите "ниндзя"! Поклонники Sector Inspector'а могут воспользоваться командным файлов следующего содержания.<br />
<br />
SECINSPECT.EXE -backup d: backup.dsk XXX 1<br>SECINSPECT.EXE -restore d: backup.dsk YYY CONFIRM<br />
<br />
Листинг 1. Командный файл для ручного восстановления $MFT из $MFTMirr, XXX - номер сектора $MFTMirr, YYY - номер сектора $MFT.<br />
<br />
Теперь можно смело пускать chkdsk. Если же он по-прежнему не работает, значит либо поврежден загрузочный сектор (а методику его восстановления мы уже обсуждали), либо run-list файла $MFT:$DATA не совпадает с истинным началом MFT (найдите сектор с файловой записью $MFT внутри и исправьте run-list), либо размер кластера, прописанный в boot-секторе отличается от его фактического размера (о том, как определять истинный размер кластера, мы уже только что говорили).<br />
<br />
Если же сбой был настолько серьезен, что вместе с $MFT пострадало и зеркало, задача сводится к восстановлению отформатированного диска. Кстати говоря, при тяжелых разрушениях файловой структуры, когда на диске образуется настоящий кавардак, восстановление тома полезно начинать с... его форматирования. Нет, это не первоапрельская шутка! Утилита format формирует заведомо исправные ключевые структуры, ну а подключение файловых записей - не проблема. Главное - сохраните run-list файла $MFT:$DATA, если, конечно, он еще уцелел. Все остальное - дело техники!<br />
<br />
Безуспешная попытка прочитать поврежденный том<br />
<br />
Рисунок 7 Безуспешная попытка прочитать поврежденный том.<br>Восстановление NTFS-тома, отформатированного под FAT16/32<br />
<br />
При переформатировании диска, операционные системы семейства NT никогда не изменяют тип файловой системы (разве что попросить их это сделать явно), поэтому непреднамеренное форматирование NTFS раздела в FAT16/32 крайне маловероятно. Windows 9x/MS-DOS, напротив, любой диск стремятся отформатировать под FAT16/32, не замечая, что на нем что-то уже находится. Непреднамеренная порча NTFS-разделов при установке Windows 9x/MS-DOS поверх Windows NT - обычное дело, через которое проходит уже второе поколение пользователей.<br />
<br />
Стратегия спасения данных во всем похожа на восстановление NTFS-тома, отформатированного под NTFS, с той лишь разницей, что при создании таблицы размещения файлов (file allocation table) первые несколько тысяч файловых записей в MFT затираются безвозвратно (впрочем, их еще можно собрать руками, действуя по методике описанной в разделе "Разгребая кластерные обломки" предыдущей статьи этого цикла).<br />
<br />
Файлы с уцелевшей FILE RECORD легко восстанавливаются R-Studio/GetDataBack/EasyRecovery. Для ручного восстановления всего тома его необходимо заново отформатировать под NTFS, предварительно определив количество секторов в кластере. Далее действуем по плану - увеличиваем размер $MFT, пускаем chkdsk и собираем все, что только можно собрать. Поскольку количество файлов, хранящихся на современных дисках, зачастую исчисляется многими миллионами, потеря первой тысячи из них не так уж и страшна (если только по закону подлости это не будут самые ценные файлы).<br>Источники угрозы<br />
<br />
Почему погибают дисковые разделы? Ниже приводится список наиболее распространенных причини, отсортированный в порядке убывания их "популярности":<br />
<br />
Ошибки оператора, вирусы, троянские программы;<br />
<br />
Отключение питания/зависание системы во время интенсивных дисковых операций, сопровождаемых обновлением MFT (например, удаление/добавление файлов или каталогов);<br />
<br />
Некорректное поведение различных дисковых утилит (Partition Magic, Ahead Nero, Norton Disk Doctor и т.д.);<br />
<br />
Физические дефекты оперативной памяти, приводящие к нарушению целостности дискового кэша и как следствие - порче самого диска;<br />
<br />
Некорректное поведение привилегированных драйверов, случайно или преднамеренно "залетающих" внутрь служебных структур NTFS-драйвера;<br />
<br />
Полезные советы - план превентивных действий по спасению данных<br />
<br />
Чтобы предотвратить разрушение тома и упростить задачу восстановления данных, рекомендуется заблаговременно выполнить следующий комплекс мероприятий:<br />
<br />
Переместите $MFT подальше от начала раздела. Первые секторы раздела, как показывает практика, самое небезопасное место. Во-первых, сюда стремятся вирусы (миф о невозможности прямого доступа к диску под NT всего лишь миф - читайте описание функции CreateFile и инструкцию на ASPI32-драйвер), во-вторых, некоторые утилиты (и, в частности, Ahead Nero) при некоторых обстоятельствах путают жесткий диск с оптическим накопителем, записывая образ не "туда", а, значит, в первых ~700 Мбайтах физического диска (не логического тома!) не должно быть ничего ценного, в-третьих, если вы вдруг запустите WipeDisk или любую другую затирающую утилиту, первым погибнет именно $MFT, без которого весь дисковый том - просто груда мусора, в четвертых... да много разных причин можно найти. Просто переместите $MFT, вам что - трудно? Достаточно взять любой дефрагментатор, распространяющийся в исходных текстах (энтузиасты! ау! присоединяйтесь к проекту http://sourceforge.net/projects/opendefrag/) и слегка доработать его "напильником" под наши нужды. Естественно, валерьянка и резервная копия обязательно должны быть под рукой!<br />
<br />
Не допускайте фрагментации $MFT-файла! Не создавайте на диске огромного количества мелких файлов и не заполняйте его более чем на 90%. Стандартный дефрагментатор, входящий в комплект штатной поставки Windows 2000/XP, не позволяет дефрагментировать $MFT и приходится прибегать к сторонним средствам, лучшим из которых на мой взгляд является O&amp;O Defrag Pro от одноименной компании (www.oo-software.com). Это действительно профессиональный дефрагментатор, к тому же поддерживающий командную строку;<br />
<br />
Периодически создавайте резервную копию файловой записи $MFT - для этого достаточно сохранить один-единственный (!) сектор - первый сектор MFT, номер которого содержится в boot, только не забывайте его периодически обновлять, ведь при добавлении новых файлов/каталогов MFT планомерно расширяется и старые списки отрезков становятся все менее и менее актуальны;<br />
<br />
Нормальный дисковый том<br />
<br />
Рисунок 8. Нормальный дисковый том (MFT, выделенный желтым цветом, расположен в начале раздела).<br />
<br />
Иммунизированный дисковый том<br />
<br />
Рисунок 9. "Иммунизированный" дисковый том (MFT расположен в середине).<br>Заключение<br />
<br />
Наш затянувшийся разговор о восстановлении данных подходит к своему логическому концу, однако NTFS не стоит на месте, а интенсивно развирается. И хотя до сих пор эти изменения носили чисто косметический характер, в Windows Longhorn все обещает кардинальным образом измениться. Microsoft активно работает над новой файловой системой - Windows File System или сокращенно WinFS, сроки выхода которой, кстати говоря, постоянно переносятся (разработка файловой системы - это не шутка!).<br />
<br />
По словам вице-президента Microsoft Боба Маглиа, WinFS - это все та же NTFS, с прикрученным SQL и XML. Насколько изменятся базовые структуры файловой системы, общественности до сих пор неясно. И уж совсем непонятно, зачем NTFS понадобился реляционный SQL, когда эти возможности в нее закладывались изначально, просто их не успели доделать. Любой системный программист запросто напишет драйвер, принимающий SQL/XML запросы и транслирующий их в обращения к драйверу текущей файловой системы! Что-либо менять внутри NTFS совсем необязательно. Сдается мне, что это всего лишь очередной маркетинговый трюк, подталкивающих пользователей к переходу на ненавистный мне Longhorn!<br />
<br />
С другой стороны, развитие NTFS можно только приветствовать, поскольку оно дает пищу всем специалистам по восстановлению данных, ведь старые утилиты с новой файловой системой, скорей всего, окажутся несовместимы.<br></div>192.168.51.51https://wiki.welard.com/index.php?title=Centos_Repo&diff=2052Centos Repo2011-07-07T20:38:31Z<p>192.168.51.51: </p>
<hr />
<div>== Додавання репозиторію RpmForge ==<br />
yum install yum-priorities<br />
Дописати у .repo файли в /etc/yum.repos.d/ <br />
priority=N<br />
<br />
[base], [addons], [updates], [extras] ... priority=1 <br />
[centosplus],[contrib] ... priority=2<br />
Third Party Repos such as rpmforge ... priority=N (N > 10 )<br />
<br />
Качаємо пакет<br />
<br />
для i386 <br />
http://apt.sw.be/redhat/el5/en/i386/RPMS.dag/rpmforge-release-0.3.6-1.el5.rf.i386.rpm<br />
для x86_64<br />
http://apt.sw.be/redhat/el5/en/x86_64/RPMS.dag/rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm<br />
Ставимо ключ і пакет<br />
rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt<br />
rpm -i rpmforge-release-0.3.6-1.el5.rf.*.rpm<br />
<br />
== Додавання репозиторію EPEL ==<br />
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm<br />
Деталі тут http://fedoraproject.org/wiki/EPEL/FAQ#howtouse<br />
<br />
Набір репозиторіїв <br />
[http://pkgs.org/ pkg.org]<br />
[http://usefulthings.org.uk/category/reference/rpm/ Some RPMS]</div>192.168.51.51https://wiki.welard.com/index.php?title=Fstab&diff=2032Fstab2011-02-13T13:40:58Z<p>192.168.51.51: </p>
<hr />
<div>== Монтирование разделов по меткам в fstab (fstab mount linux label) ==<br />
<br />
Оригинал: http://ru.gentoo-wiki.com/Fstab<br />
<br />
<br />
Введение<br />
--------<br />
<br />
/etc/fstab Конфигурационный файл с указанием партиции и ее точки<br />
монтирования в структуре файловой системы.<br />
<br />
Классическая схема конфигурации на основе шины описана в статье О<br />
монтировании файловых систем<br />
<br />
<br />
Уникальные идентификаторы<br />
<br />
<br />
Уникальная идентификация партиции и точное указание точки монтирования<br />
стало возможным при наличии udev и имеет некоторое превосходство над<br />
обозначением по положению на шине ide/scsi.<br />
<br />
Развитие Linux и udev увеличивает надежность опознания различных<br />
устройств, но в тоже время появляются новые проблемы.<br />
<br />
1. Если у вас больше одного sata/scsi или ide контроллера, то их<br />
обозначение при загрузке будет случайным. В результате после<br />
перезагрузки диск sdX может выглядеть как sdY или для ide дисков -<br />
hdX и hdY. Уникальная идентификация позволяет забыть о подобных<br />
мелочах.<br />
2. Введение новой libata pata поддержки, все ваши ide hdX диски будут<br />
видны как sdX устройства. Уникальная идентификация дисков и<br />
партиций позволит вам безболезненный переход.<br />
3. В компьютерах с наличием sata и ide контроллеров переход от hdX к<br />
sdX может внести путаницу, которую можно избежать при<br />
использовании идентификаторов.<br />
<br />
<br />
Четыре схемы уникальной идентификации<br />
<br />
<br />
Идентификация по UUID<br />
<br />
UUID это сокращение от слов Universally Unique IDentifier и описывает<br />
механизм выдачи каждой файловой системе уникального идентификатора.<br />
Все файловые системы в линуксе, включая swap, поддерживают UUID. FAT и<br />
NTFS не поддерживают UUID изначально, и тем не менее в линуксе им так<br />
же назначается UUID.<br />
<br />
ls -al /dev/disk/by-uuid/<br />
total 0<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 2f6e40d0-83b5-42dc-a102-b95bc32073dc<br />
-> ../../sda1<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 84e7c2c9-f26e-4e3f-98b8-93eec152cd5a<br />
-> ../../hdc5<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 867a5afb-f266-4a85-900f-efcc86004370<br />
-> ../../sda3<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 9542be4e-fe40-4ca9-9522-f5222d32ac84<br />
-> ../../sdb1<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 b15f438d-b4b7-4536-a8cc-46128f440c7c<br />
-> ../../hdc6<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 AF92-3DDB -> ../../sdd1<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 B0JC190ODC193954 -> ../../sdd6<br />
<br />
<br />
Как вы видите, FAT и NTFS разделы имеют укороченный идентификатор.<br />
<br />
Для определения UUID так же можно воспользоватся командой<br />
<br />
tune2fs -l /dev/sda1 | grep UUID<br />
<br />
Filesystem UUID: 2f6e40d0-83b5-42dc-a102-b95bc32073dc<br />
<br />
<br />
* Преимущества использования UUID: уникальность каждого раздела по<br />
идентификатору позволяет избежать ошибок при монтировании.<br />
<br />
<br />
* Недостаток использования UUID: трудно запомнить ;)<br />
<br />
<br />
<br />
Идентификация по LABEL<br />
<br />
<br />
Практически любой файловой системе или партиции можно присвоить LABEL<br />
(метку)<br />
<br />
ls -l /dev/disk/by-label/<br />
total 0<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 250gig -> ../../sdb1<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 b00t -> ../../sda1<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 level0 -> ../../sda3<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 p2p -> ../../hdc6<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 swap -> ../../hdc5<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 fat -> ../../sdd1<br />
lrwxrwxrwx 1 root root 10 2007-04-24 18:01 ntfs -> ../../sdd6<br />
<br />
<br />
Посмотреть названия так же можно командой cfdisk /dev/sda<br />
<br />
Для изменения label для каждой файловой системы выполните подходящие<br />
команды:<br />
swap: Создание новой swap партиции:<br />
mkswap -L <label> /dev/XXX<br />
<br />
<br />
ext2/ext3:<br />
e2label /dev/XXX <label><br />
<br />
<br />
reiserfs:<br />
reiserfstune -l <label> /dev/XXX<br />
<br />
jfs:<br />
jfs_tune -L <label> /dev/XXX<br />
<br />
<br />
xfs:<br />
xfs_admin -L <label> /dev/XXX<br />
<br />
<br />
fat/vfat: Изменить метку диска в Windows, или при создании раздела в линуксе<br />
<br />
mkdosfs -n <label> <other options>.<br />
<br />
назначение метки диску <br />
tune2fs -L HOME /dev/sda1 <br />
<br />
ntfs: Изменить метку диска в Windows или<br />
<br />
ntfslabel /dev/XXX <label><br />
<br />
<br />
Предупреждение: Будте внимательны при обозначении партиций. LABEL<br />
должен быть уникальным для каждого диска.<br />
<br />
<br />
Идентификация по id<br />
<br />
В данном случае id образуется из производственного серийного номера<br />
вашего диска.<br />
<br />
<br />
<br />
Идентификация по path<br />
<br />
<br />
Создание имени по кратчайшему пути (path) в соответствии с sysfs и<br />
содежит информацию о шине на которой расположен жесткий диск. Что не<br />
подходит для наших целей и решения вышеобозначенных проблем. Более<br />
подробно в статье О монтировании файловых систем<br />
<br />
<br />
Использование уникальных идентификаторов<br />
<br />
<br />
Я надеюсь вы уже определились какой метод вам понравился.<br />
Использование данных методов достаточно просто.<br />
<br />
<br />
fstab<br />
<br />
<br />
В /etc/fstab замените обозначение диска в первой колонке на ваш<br />
идентификатор к примеру, я закомментировал обозначение дисков по id<br />
знаком # и записал обозначение двух партиций по разным<br />
идентификационным схемам.<br />
<br />
/etc/fstab<br />
#/dev/sda1 /boot ext2 noauto,noatime 1 2<br />
LABEL=b00t /boot ext2 noauto,noatime 1 2<br />
#/dev/hdc5 none swap sw 0 0<br />
UUID=84e7c2c9-f26e-4e3f-98b8-93eec152cd5a none swap sw 0 0<br />
<br />
<br />
Так же можно заменить /dev/sda1 на /dev/disk/by-label/b00t или<br />
/dev/disk/by-uuid/2f6e40d0-83b5-42dc-a102-b95bc32073dc<br />
<br />
<br />
grub<br />
<br />
<br />
Предупреждение: Данное описание -- для Arch Linux. В Gentoo надо<br />
использовать genkernel и работает только указание корня через LABEL=<br />
(на данный момент)<br />
<br />
Для использования уникальных идентификаторов при загрузке необходимо:<br />
1. Использовать mkinitcpio initramfs образ<br />
2. Разрешить использование udev в /etc/mkinitcpio.conf<br />
3. Пересоздать initramfs образ до перезагрузки компьютера.<br />
<br />
Примечание: В версиях klibc-udev до 101-3 уникальное обозначение<br />
устройств не работает<br />
<br />
В приведенном выше примере партиция /dev/sda3 LABEL=level0 является<br />
root партицией и в файле /boot/grub/menu.lst запись<br />
<br />
/boot/grub/menu.lst<br />
<br />
kernel /boot/vmlinuz26 root=/dev/sda3 vga=0x318 ro<br />
<br />
<br />
надо поменять на<br />
/boot/grub/menu.lst<br />
<br />
kernel /boot/vmlinuz root=/dev/disk/by-label/level0 vga=0x318 ro<br />
<br />
<br />
или<br />
/boot/grub/menu.lst<br />
<br />
kernel /boot/vmlinuz root=LABEL=level0 vga=0x318 ro</div>192.168.51.51https://wiki.welard.com/index.php?title=OpenVPN&diff=2020OpenVPN2010-10-02T06:38:30Z<p>192.168.51.51: </p>
<hr />
<div>[http://openmaniak.com/ru/openvpn_tutorial.php Установка OPENVPN] <br />
<br />
<br> <br />
<br />
== Настройка OpenVPN ==<br />
<br />
yum install openvpn<br />
cd /etc/openvpn/<br />
mkdir certs<br />
cd certs<br />
cp /usr/share/openvpn/easy-rsa/2.0/* /etc/openvpn/certs/<br />
<br />
Дописуємо свох дані в кіці файлу vars <br />
<br />
. ../vars<br />
./clean-all<br />
<br />
Будуємо сертифікат <br />
<br />
./build-ca<br />
<br />
Будуємо ключ для сервера <br />
<br />
./build-key-server server_name<br />
<br />
Будуємо ключ для клієнтів (на кожного клієнта по одному) <br />
<br />
./build-key client1 <br />
<br />
./build-dh<br />
<br />
Налаштування /etc/openvpn/server.conf <br />
<pre>port 1194<br />
proto udp<br />
dev tun<br />
ca /etc/openvpn/certs/keys/ca.crt<br />
cert /etc/openvpn/certs/keys/CentOS.crt<br />
key /etc/openvpn/certs/keys/CentOS.key # This file should be kept secret<br />
<br />
dh /etc/openvpn/certs/keys/dh1024.pem<br />
<br />
server 172.16.51.0 255.255.255.0<br />
<br />
ifconfig-pool-persist ipp.txt<br />
;push "route 192.168.10.0 255.255.255.0"<br />
;push "route 192.168.20.0 255.255.255.0"<br />
<br />
keepalive 10 120<br />
<br />
comp-lzo<br />
;max-clients 100<br />
<br />
;user nobody<br />
;group nobody<br />
<br />
persist-key<br />
persist-tun<br />
<br />
status openvpn-status.log<br />
<br />
;log openvpn.log<br />
;log-append openvpn.log<br />
<br />
verb 3<br />
<br />
</pre><br />
<br />
Налаштування клієнта<br />
<pre><br />
client<br />
dev tun<br />
proto udp<br />
#proto tcp-client<br />
#Change my.publicdomain.com to your public domain or IP address<br />
remote 192.168.0.200 1194<br />
resolv-retry infinite<br />
nobind<br />
persist-key<br />
persist-tun<br />
<br />
ca ca2.crt<br />
cert user.crt<br />
key user.key<br />
ns-cert-type server<br />
<br />
#DNS Options here, CHANGE THESE !!<br />
#push "dhcp-option DNS 123.123.123.123"<br />
#push "dhcp-option DNS 123.123.123.124"<br />
comp-lzo<br />
tun-mtu 1500<br />
mssfix 1450<br />
verb 3<br />
</pre><br />
<br />
Заборонити клієнту доступ до сервера <br />
revoke-full <ім'я клієнта><br />
cp keys/crl.pem /etc/openvpn/<br />
<br />
<br />
== Проблема openvpn в операционной системе Vista ==<br />
<br />
1. Для того чтобы клиент openvpn заработал в windows vista необходимо добавить в конфиг файл клиентской части следующие строки:<br />
route-method exe<br />
route-delay 2<br />
<br />
2. Затем нужно создать bat файл следующего содержания:<br />
"C:\Program Files\OpenVPN\bin\openvpn.exe" "полный_путь_до_конфига"<br />
Для запуска VPN правой кнопкой мыши жмем на полученном bat файле и выбираем "Запустить как администратор"</div>192.168.51.51https://wiki.welard.com/index.php?title=Mysql&diff=1994Mysql2010-06-28T10:35:22Z<p>192.168.51.51: </p>
<hr />
<div>Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування.<br />
<br />
MySQL – компактний багатонитевий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.<br />
<br />
MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних.<br />
<br />
MySQL вважається гарним рішенням для малих і середніх застосунків. Вихідні коди сервера компілюються на багатьох платформах. Найповніше можливості сервера виявляються в UNІХ-системах, де є підтримка багатонитевості, що підвищує продуктивність системи в цілому.<br />
Для некомерційного використання MySQL є безкоштовним. <br />
<br />
<br />
<br />
<br />
== Встановлення прав ==<br />
GRANT ALL PRIVILEGES ON *.* TO user@'%' IDENTIFIED BY '1'<br />
<br />
== Швидкий дамп та швидке розгортання ==<br />
SELECT * INTO OUTFILE '/tmp/result.txt' FROM &lt;table name&gt;<br />
LOAD DATA INFILE '/tmp/result.txt' INTO TABLE &lt;table name&gt;<br />
<br />
<br />
Значення по замовчуванню<br />
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'<br />
LINES TERMINATED BY '\n' STARTING BY ''<br />
<br />
== Что нужно настроить в mySQL сразу после установки? ==<br />
<br />
Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.<br />
<br />
Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.<br />
<br />
Несмотря на то, что в mySQL существует довольно много настроек, которые Вы можете изменить, есть набор действительно очень важных характеристик, которые обязательно нужно оптимизировать под собственный сервер. Обычно после такой небольшой настройки производительность сервера заметно увеличивается.<br />
<br />
* key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.<br />
* innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.<br />
* innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.<br />
* innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.<br />
* innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.<br />
* innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.<br />
* table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.<br />
* thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.<br />
* query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.<br />
<br />
<br />
Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.<br />
<br />
PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.</div>192.168.51.51https://wiki.welard.com/index.php?title=Mysql&diff=1993Mysql2010-06-28T10:34:45Z<p>192.168.51.51: </p>
<hr />
<div>Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування.<br />
<br />
MySQL – компактний багатонитевий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.<br />
<br />
MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних.<br />
<br />
MySQL вважається гарним рішенням для малих і середніх застосунків. Вихідні коди сервера компілюються на багатьох платформах. Найповніше можливості сервера виявляються в UNІХ-системах, де є підтримка багатонитевості, що підвищує продуктивність системи в цілому.<br />
Для некомерційного використання MySQL є безкоштовним. <br />
<br />
<br />
<br />
<br />
== Встановлення прав ==<br />
GRANT ALL PRIVILEGES ON *.* TO user@'%' IDENTIFIED BY '1'<br />
<br />
== Швидкий дамп та швидке розгортання ==<br />
SELECT * INTO OUTFILE '/tmp/result.txt' FROM &dt;table name&lt;<br />
LOAD DATA INFILE '/tmp/result.txt' INTO TABLE table name<br />
<br />
<br />
Значення по замовчуванню<br />
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'<br />
LINES TERMINATED BY '\n' STARTING BY ''<br />
<br />
== Что нужно настроить в mySQL сразу после установки? ==<br />
<br />
Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.<br />
<br />
Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.<br />
<br />
Несмотря на то, что в mySQL существует довольно много настроек, которые Вы можете изменить, есть набор действительно очень важных характеристик, которые обязательно нужно оптимизировать под собственный сервер. Обычно после такой небольшой настройки производительность сервера заметно увеличивается.<br />
<br />
* key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.<br />
* innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.<br />
* innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.<br />
* innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.<br />
* innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.<br />
* innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.<br />
* table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.<br />
* thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.<br />
* query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.<br />
<br />
<br />
Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.<br />
<br />
PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.</div>192.168.51.51https://wiki.welard.com/index.php?title=Mysql&diff=1992Mysql2010-06-28T10:34:11Z<p>192.168.51.51: </p>
<hr />
<div>Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування.<br />
<br />
MySQL – компактний багатонитевий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.<br />
<br />
MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних.<br />
<br />
MySQL вважається гарним рішенням для малих і середніх застосунків. Вихідні коди сервера компілюються на багатьох платформах. Найповніше можливості сервера виявляються в UNІХ-системах, де є підтримка багатонитевості, що підвищує продуктивність системи в цілому.<br />
Для некомерційного використання MySQL є безкоштовним. <br />
<br />
<br />
<br />
<br />
== Встановлення прав ==<br />
GRANT ALL PRIVILEGES ON *.* TO user@'%' IDENTIFIED BY '1'<br />
<br />
== Швидкий дамп та швидке розгортання ==<br />
SELECT * INTO OUTFILE '/tmp/result.txt' FROM <<table name>><br />
LOAD DATA INFILE '/tmp/result.txt' INTO TABLE <<table name>><br />
<br />
<br />
Значення по замовчуванню<br />
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'<br />
LINES TERMINATED BY '\n' STARTING BY ''<br />
<br />
== Что нужно настроить в mySQL сразу после установки? ==<br />
<br />
Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.<br />
<br />
Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.<br />
<br />
Несмотря на то, что в mySQL существует довольно много настроек, которые Вы можете изменить, есть набор действительно очень важных характеристик, которые обязательно нужно оптимизировать под собственный сервер. Обычно после такой небольшой настройки производительность сервера заметно увеличивается.<br />
<br />
* key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.<br />
* innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.<br />
* innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.<br />
* innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.<br />
* innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.<br />
* innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.<br />
* table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.<br />
* thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.<br />
* query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.<br />
<br />
<br />
Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.<br />
<br />
PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.</div>192.168.51.51https://wiki.welard.com/index.php?title=Mysql&diff=1991Mysql2010-06-28T10:33:25Z<p>192.168.51.51: </p>
<hr />
<div>Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування.<br />
<br />
MySQL – компактний багатонитевий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.<br />
<br />
MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних.<br />
<br />
MySQL вважається гарним рішенням для малих і середніх застосунків. Вихідні коди сервера компілюються на багатьох платформах. Найповніше можливості сервера виявляються в UNІХ-системах, де є підтримка багатонитевості, що підвищує продуктивність системи в цілому.<br />
Для некомерційного використання MySQL є безкоштовним. <br />
<br />
<br />
<br />
<br />
== Встановлення прав ==<br />
GRANT ALL PRIVILEGES ON *.* TO user@'%' IDENTIFIED BY '1'<br />
<br />
== Швидкий дамп та швидке розгортання ==<br />
SELECT * INTO OUTFILE '/tmp/result.txt' FROM table name<br />
LOAD DATA INFILE '/tmp/result.txt' INTO TABLE table name<br />
<br />
<br />
Значення по замовчуванню<br />
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'<br />
LINES TERMINATED BY '\n' STARTING BY ''<br />
<br />
== Что нужно настроить в mySQL сразу после установки? ==<br />
<br />
Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.<br />
<br />
Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.<br />
<br />
Несмотря на то, что в mySQL существует довольно много настроек, которые Вы можете изменить, есть набор действительно очень важных характеристик, которые обязательно нужно оптимизировать под собственный сервер. Обычно после такой небольшой настройки производительность сервера заметно увеличивается.<br />
<br />
* key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.<br />
* innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.<br />
* innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.<br />
* innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.<br />
* innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.<br />
* innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.<br />
* table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.<br />
* thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.<br />
* query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.<br />
<br />
<br />
Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.<br />
<br />
PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.</div>192.168.51.51https://wiki.welard.com/index.php?title=Mysql&diff=1990Mysql2010-06-28T10:32:49Z<p>192.168.51.51: </p>
<hr />
<div>Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування.<br />
<br />
MySQL – компактний багатонитевий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.<br />
<br />
MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних.<br />
<br />
MySQL вважається гарним рішенням для малих і середніх застосунків. Вихідні коди сервера компілюються на багатьох платформах. Найповніше можливості сервера виявляються в UNІХ-системах, де є підтримка багатонитевості, що підвищує продуктивність системи в цілому.<br />
Для некомерційного використання MySQL є безкоштовним. <br />
<br />
<br />
<br />
<br />
== Встановлення прав ==<br />
== Швидкий дамп та швидке розгортання ==<br />
SELECT * INTO OUTFILE '/tmp/result.txt' FROM <table name><br />
LOAD DATA INFILE '/tmp/result.txt' INTO TABLE <table name><br />
<br />
GRANT ALL PRIVILEGES ON *.* TO user@'%' IDENTIFIED BY '1'<br />
<br />
Значення по замовчуванню<br />
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'<br />
LINES TERMINATED BY '\n' STARTING BY ''<br />
<br />
== Что нужно настроить в mySQL сразу после установки? ==<br />
<br />
Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.<br />
<br />
Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.<br />
<br />
Несмотря на то, что в mySQL существует довольно много настроек, которые Вы можете изменить, есть набор действительно очень важных характеристик, которые обязательно нужно оптимизировать под собственный сервер. Обычно после такой небольшой настройки производительность сервера заметно увеличивается.<br />
<br />
* key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.<br />
* innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.<br />
* innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.<br />
* innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.<br />
* innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.<br />
* innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.<br />
* table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.<br />
* thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.<br />
* query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.<br />
<br />
<br />
Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.<br />
<br />
PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.</div>192.168.51.51https://wiki.welard.com/index.php?title=Mysql&diff=1989Mysql2010-06-28T10:32:31Z<p>192.168.51.51: </p>
<hr />
<div>Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування.<br />
<br />
MySQL – компактний багатонитевий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.<br />
<br />
MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних.<br />
<br />
MySQL вважається гарним рішенням для малих і середніх застосунків. Вихідні коди сервера компілюються на багатьох платформах. Найповніше можливості сервера виявляються в UNІХ-системах, де є підтримка багатонитевості, що підвищує продуктивність системи в цілому.<br />
Для некомерційного використання MySQL є безкоштовним. <br />
<br />
<br />
<br />
<br />
== Встановлення прав ==<br />
== Швидкий дамп та швидке розгортання ==<br />
GRANT ALL PRIVILEGES ON *.* TO user@'%' IDENTIFIED BY '1'<br />
SELECT * INTO OUTFILE '/tmp/result.txt' FROM <table name><br />
LOAD DATA INFILE '/tmp/result.txt' INTO TABLE <table name><br />
<br />
Значення по замовчуванню<br />
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'<br />
LINES TERMINATED BY '\n' STARTING BY ''<br />
<br />
== Что нужно настроить в mySQL сразу после установки? ==<br />
<br />
Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.<br />
<br />
Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.<br />
<br />
Несмотря на то, что в mySQL существует довольно много настроек, которые Вы можете изменить, есть набор действительно очень важных характеристик, которые обязательно нужно оптимизировать под собственный сервер. Обычно после такой небольшой настройки производительность сервера заметно увеличивается.<br />
<br />
* key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.<br />
* innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.<br />
* innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.<br />
* innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.<br />
* innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.<br />
* innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.<br />
* table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.<br />
* thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.<br />
* query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.<br />
<br />
<br />
Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.<br />
<br />
PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.</div>192.168.51.51https://wiki.welard.com/index.php?title=Mysql&diff=1988Mysql2010-06-28T10:32:15Z<p>192.168.51.51: </p>
<hr />
<div>Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування.<br />
<br />
MySQL – компактний багатонитевий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.<br />
<br />
MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних.<br />
<br />
MySQL вважається гарним рішенням для малих і середніх застосунків. Вихідні коди сервера компілюються на багатьох платформах. Найповніше можливості сервера виявляються в UNІХ-системах, де є підтримка багатонитевості, що підвищує продуктивність системи в цілому.<br />
Для некомерційного використання MySQL є безкоштовним. <br />
<br />
<br />
<br />
<br />
== Встановлення прав ==<br />
== Швидкий дамп та швидке розгортання ==<br />
GRANT ALL PRIVILEGES ON *.* TO user@'%' IDENTIFIED BY '1';<br />
SELECT * INTO OUTFILE '/tmp/result.txt' FROM <table name><br />
LOAD DATA INFILE '/tmp/result.txt' INTO TABLE <table name><br />
<br />
Значення по замовчуванню<br />
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'<br />
LINES TERMINATED BY '\n' STARTING BY ''<br />
<br />
== Что нужно настроить в mySQL сразу после установки? ==<br />
<br />
Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.<br />
<br />
Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.<br />
<br />
Несмотря на то, что в mySQL существует довольно много настроек, которые Вы можете изменить, есть набор действительно очень важных характеристик, которые обязательно нужно оптимизировать под собственный сервер. Обычно после такой небольшой настройки производительность сервера заметно увеличивается.<br />
<br />
* key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.<br />
* innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.<br />
* innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.<br />
* innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.<br />
* innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.<br />
* innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.<br />
* table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.<br />
* thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.<br />
* query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.<br />
<br />
<br />
Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.<br />
<br />
PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.</div>192.168.51.51https://wiki.welard.com/index.php?title=Mysql&diff=1987Mysql2010-06-28T10:31:57Z<p>192.168.51.51: </p>
<hr />
<div>Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування.<br />
<br />
MySQL – компактний багатонитевий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.<br />
<br />
MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних.<br />
<br />
MySQL вважається гарним рішенням для малих і середніх застосунків. Вихідні коди сервера компілюються на багатьох платформах. Найповніше можливості сервера виявляються в UNІХ-системах, де є підтримка багатонитевості, що підвищує продуктивність системи в цілому.<br />
Для некомерційного використання MySQL є безкоштовним. <br />
<br />
<br />
<br />
<br />
== Встановлення прав ==<br />
== Швидкий дамп та швидке розгортання ==<br />
GRANT ALL PRIVILEGES ON *.* TO user@'%' IDENTIFIED BY '1';<br />
<br />
<br />
SELECT * INTO OUTFILE '/tmp/result.txt' FROM <table name><br />
LOAD DATA INFILE '/tmp/result.txt' INTO TABLE <table name><br />
<br />
Значення по замовчуванню<br />
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'<br />
LINES TERMINATED BY '\n' STARTING BY ''<br />
<br />
== Что нужно настроить в mySQL сразу после установки? ==<br />
<br />
Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.<br />
<br />
Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.<br />
<br />
Несмотря на то, что в mySQL существует довольно много настроек, которые Вы можете изменить, есть набор действительно очень важных характеристик, которые обязательно нужно оптимизировать под собственный сервер. Обычно после такой небольшой настройки производительность сервера заметно увеличивается.<br />
<br />
* key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.<br />
* innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.<br />
* innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.<br />
* innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.<br />
* innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.<br />
* innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.<br />
* table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.<br />
* thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.<br />
* query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.<br />
<br />
<br />
Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.<br />
<br />
PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.</div>192.168.51.51https://wiki.welard.com/index.php?title=Mysql&diff=1986Mysql2010-06-28T10:30:11Z<p>192.168.51.51: </p>
<hr />
<div>Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування.<br />
<br />
MySQL – компактний багатонитевий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.<br />
<br />
MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних.<br />
<br />
MySQL вважається гарним рішенням для малих і середніх застосунків. Вихідні коди сервера компілюються на багатьох платформах. Найповніше можливості сервера виявляються в UNІХ-системах, де є підтримка багатонитевості, що підвищує продуктивність системи в цілому.<br />
Для некомерційного використання MySQL є безкоштовним. <br />
<br />
<br />
<br />
<br />
== Встановлення прав ==<br />
GRANT ALL PRIVILEGES ON *.* TO user@'%' IDENTIFIED BY '1';<br />
<br />
== Швидкий дамп та швидке розгортання ==<br />
SELECT * INTO OUTFILE '/tmp/result.txt' FROM <table name><br />
LOAD DATA INFILE '/tmp/result.txt' INTO TABLE <table name><br />
<br />
Значення по замовчуванню<br />
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'<br />
LINES TERMINATED BY '\n' STARTING BY ''<br />
<br />
== Что нужно настроить в mySQL сразу после установки? ==<br />
<br />
Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.<br />
<br />
Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.<br />
<br />
Несмотря на то, что в mySQL существует довольно много настроек, которые Вы можете изменить, есть набор действительно очень важных характеристик, которые обязательно нужно оптимизировать под собственный сервер. Обычно после такой небольшой настройки производительность сервера заметно увеличивается.<br />
<br />
* key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.<br />
* innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.<br />
* innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.<br />
* innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.<br />
* innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.<br />
* innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.<br />
* table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.<br />
* thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.<br />
* query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.<br />
<br />
<br />
Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.<br />
<br />
PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.</div>192.168.51.51https://wiki.welard.com/index.php?title=Mysql&diff=1985Mysql2010-06-28T10:29:50Z<p>192.168.51.51: </p>
<hr />
<div>Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування.<br />
<br />
MySQL – компактний багатонитевий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.<br />
<br />
MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних.<br />
<br />
MySQL вважається гарним рішенням для малих і середніх застосунків. Вихідні коди сервера компілюються на багатьох платформах. Найповніше можливості сервера виявляються в UNІХ-системах, де є підтримка багатонитевості, що підвищує продуктивність системи в цілому.<br />
Для некомерційного використання MySQL є безкоштовним. <br />
<br />
<br />
<br />
<br />
== Встановлення прав ==<br />
GRANT ALL PRIVILEGES ON *.* TO user@'%' IDENTIFIED BY '1';<br />
<br />
== Швидкий дамп та швидке розгортання ==<br />
SELECT * INTO OUTFILE '/tmp/result.txt' FROM <table name> LOAD DATA INFILE '/tmp/result.txt' INTO TABLE <table name><br />
<br />
Значення по замовчуванню<br />
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'<br />
LINES TERMINATED BY '\n' STARTING BY ''<br />
<br />
== Что нужно настроить в mySQL сразу после установки? ==<br />
<br />
Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.<br />
<br />
Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.<br />
<br />
Несмотря на то, что в mySQL существует довольно много настроек, которые Вы можете изменить, есть набор действительно очень важных характеристик, которые обязательно нужно оптимизировать под собственный сервер. Обычно после такой небольшой настройки производительность сервера заметно увеличивается.<br />
<br />
* key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.<br />
* innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.<br />
* innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.<br />
* innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.<br />
* innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.<br />
* innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.<br />
* table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.<br />
* thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.<br />
* query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.<br />
<br />
<br />
Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.<br />
<br />
PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.</div>192.168.51.51https://wiki.welard.com/index.php?title=Mysql&diff=1984Mysql2010-06-28T10:29:27Z<p>192.168.51.51: </p>
<hr />
<div>Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування.<br />
<br />
MySQL – компактний багатонитевий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.<br />
<br />
MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних.<br />
<br />
MySQL вважається гарним рішенням для малих і середніх застосунків. Вихідні коди сервера компілюються на багатьох платформах. Найповніше можливості сервера виявляються в UNІХ-системах, де є підтримка багатонитевості, що підвищує продуктивність системи в цілому.<br />
Для некомерційного використання MySQL є безкоштовним. <br />
<br />
<br />
<br />
<br />
== Встановлення прав ==<br />
GRANT ALL PRIVILEGES ON *.* TO user@'%' IDENTIFIED BY '1';<br />
<br />
== Швидкий дамп та швидке розгортання ==<br />
SELECT * INTO OUTFILE '/tmp/result.txt' FROM <table name><br />
LOAD DATA INFILE '/tmp/result.txt' INTO TABLE <table name><br />
<br />
Значення по замовчуванню<br />
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'<br />
LINES TERMINATED BY '\n' STARTING BY ''<br />
<br />
== Что нужно настроить в mySQL сразу после установки? ==<br />
<br />
Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.<br />
<br />
Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.<br />
<br />
Несмотря на то, что в mySQL существует довольно много настроек, которые Вы можете изменить, есть набор действительно очень важных характеристик, которые обязательно нужно оптимизировать под собственный сервер. Обычно после такой небольшой настройки производительность сервера заметно увеличивается.<br />
<br />
* key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.<br />
* innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.<br />
* innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.<br />
* innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.<br />
* innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.<br />
* innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.<br />
* table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.<br />
* thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.<br />
* query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.<br />
<br />
<br />
Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.<br />
<br />
PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.</div>192.168.51.51https://wiki.welard.com/index.php?title=CentOS&diff=1976CentOS2010-04-30T17:10:58Z<p>192.168.51.51: </p>
<hr />
<div>CentOS (Community ENTerprise Operating System) -- вільно доступний дистрибутив [[Лінукс]] на основі комерційного дистрибутиву Red Hat Enterprise Linux компанії Red Hat.<br />
<br />
Проект доклав зусиль, щоб зібрати 100% двійково сумісний зі своїм предком дистрибутив у плані шляху його розвитку, і старається розвиватися з ним в один бік, не відступаючи від його основної лінії та модифікацій, щоб не змінювати своєї мети. <br />
<br />
Karanbir Singh is one of the core developers in the CentOS Project<br />
<br />
[http://twitter.com/centos Twitter]<br />
<br />
[http://www.karan.org Офіційний сайт]<br />
<br />
<br />
<br />
== Додаткова інформація ==<br />
<br />
Встановити для компіляції <br />
<br />
yum groupinstall 'Development Tools'<br />
yum groupinstall 'Development Libraries'<br />
<br />
<br> <br />
<br />
== Управління службами ==<br />
ntsysv</div>192.168.51.51https://wiki.welard.com/index.php?title=CentOS&diff=1975CentOS2010-04-30T17:10:43Z<p>192.168.51.51: </p>
<hr />
<div>CentOS (Community ENTerprise Operating System) -- вільно доступний дистрибутив [[Лінукс]] на основі комерційного дистрибутиву Red Hat Enterprise Linux компанії Red Hat.<br />
<br />
Проект доклав зусиль, щоб зібрати 100% двійково сумісний зі своїм предком дистрибутив у плані шляху його розвитку, і старається розвиватися з ним в один бік, не відступаючи від його основної лінії та модифікацій, щоб не змінювати своєї мети. <br />
<br />
Karanbir Singh is one of the core developers in the CentOS Project<br />
[http://twitter.com/centos Twitter]<br />
[http://www.karan.org Офіційний сайт]<br />
<br> <br />
<br />
== Додаткова інформація ==<br />
<br />
Встановити для компіляції <br />
<br />
yum groupinstall 'Development Tools'<br />
yum groupinstall 'Development Libraries'<br />
<br />
<br> <br />
<br />
== Управління службами ==<br />
ntsysv</div>192.168.51.51https://wiki.welard.com/index.php?title=Linux&diff=1974Linux2010-04-30T17:06:40Z<p>192.168.51.51: </p>
<hr />
<div>Операційна система <br />
<br />
[[Linux Шпаргалка]]<br />
[[ps]]<br />
[[Checkinstall]]<br />
[[Fstab]]<br />
[[Установить Linux по сети]]<br />
[[LDAP-configure]]<br />
[[Mail setting]]<br />
[[OpenSSL]]<br />
[[Centos Repo]]<br />
[[Centos multimedia]]<br />
[[Yum]]<br />
[[RPM]]<br />
[[Управління rpm]]<br />
[[Ssh]]<br />
[[SPF]]<br />
[[OpenVPN]]<br />
[[Nfs 3]]<br />
[[Nginx-as-reverse-proxy]]<br />
[[Ldap-errors]]<br />
[[DNS]]<br />
[[Iptables]]<br />
[[OpenLDAP]]<br />
[[Iptables]]<br />
[[Mod ssl]]<br />
[[SSL configure]]<br />
[[CentOS]]<br />
[[Php fastcgi]]<br />
[[Nginx Django]]<br />
[[Vim]]<br />
[[Захист SSH]]<br />
[[Install FTP Server]]<br />
[[Iftop]]<br />
[[Webmin]]<br />
[[Squid]]<br />
[[EraseDNS]]<br />
[[Rtorrent]]<br />
[[Довбана переключалка клавіатури в Linux]]<br />
[[Centos services]]<br />
[[Mini centos]]<br />
[[Ubuntu]]<br />
[[Trac]]<br />
[[Mc]]<br />
[[ZTEA2726]] Настройка 3G модема під Linux<br />
[[Virtualbox without gui]]<br />
[[Php-fpm]]<br />
[[Su]]<br />
[[PostgreSQL]]</div>192.168.51.51https://wiki.welard.com/index.php?title=Windows&diff=1886Windows2009-10-30T21:16:40Z<p>192.168.51.51: Created page with 'Windows_boot'</p>
<hr />
<div>[[Windows_boot]]</div>192.168.51.51https://wiki.welard.com/index.php?title=Windows_boot&diff=1885Windows boot2009-10-30T21:16:05Z<p>192.168.51.51: </p>
<hr />
<div>== Загрузка Windows ==<br />
<br />
[http://www.osp.ru/win2000/2003/01/175736/ Оригинал]<br />
<br />
<br />
Посмотрим, какие стадии проходит Windows 2000 в процессе загрузки. <br />
<br />
После включения компьютера выполняется загрузка BIOS, которая проводит процедуру первоначального тестирования оборудования (POST), считывает запись Master Boot Record (MBR) и передает управление коду, содержащемуся в этой записи.Он выполняет проверку, ищет в корневом каталоге модуль ntldr и передает ему управление (MBR не может читать дерево подкаталогов, поэтому Ntldr всегда находится в корневом каталоге). <br />
В свою очередь, Ntldr обрабатывает файл boot.ini, выводит на экран меню вариантов загрузки или, если вариант один, не дожидаясь выбора, переходит к следующему этапу. <br />
На нем запускается 16-разрядное приложение ntdetect.com, которое получает информацию об оборудовании от BIOS и сохраняет ее во внутренних структурах. Затем ntldr выводит картинку — индикатор загрузки Windows 2000 — и предлагает нажать на F8. Действия операционной системы при выборе специальных вариантов загрузки по нажатию клавиши F8 мы здесь рассматривать не будем.<br />
<br />
Ntldr загружает ядро операционной системы и Hardware Abstraction Layer (HAL), которым, по умолчанию, соответствуют файлы Ntoskrnl.exe и HAL.dll. <br />
Далее загружаются необходимые (помеченные флажком SERVICE_BOOT_START) драйверы устройств, описанные в файле SYSTEM, содержащем соответствующий раздел реестра. <br />
После этого загрузчик производит действия, необходимые для запуска ntoskrnl.exe, и передает управление его главной функции. Здесь происходит много всяких, во-первых, сложных и, во-вторых, не представляющих сейчас для нас интереса событий. Но в числе прочего создается процесс Smss, который формирует среду пользовательского режима. Smss запускает подсистему Win32, программы, перечисленные в HKLM\SYSTEM\CurrentControlSet\ Control\Session Manager\BootExecute, инициализирует реестр, переменные окружения и другие «мелочи» и, наконец, запускает процесс Winlogon.<br />
<br />
Далее ответственность за дальнейшую инициализацию системы ложится на Winlogon. Он формирует объект WindowStation и три рабочих стола — пользовательский, хранителя экрана и Winlogon; загружает GINA DLL (!), создает процесс диспетчера управления службами (SCM), загружает все службы и драйверы устройств, помеченные для автоматического запуска, и запускает процесс Lsass. После того как пользователь успешно зарегистрировался, а SCM запустил службы и драйверы, загрузка считается успешно завершенной, и LastKnownGood обновляется в соответствии с текущими установками.</div>192.168.51.51https://wiki.welard.com/index.php?title=Windows_boot&diff=1884Windows boot2009-10-30T21:13:57Z<p>192.168.51.51: </p>
<hr />
<div>== Загрузка Windows ==<br />
<br />
[http://www.osp.ru/win2000/2003/01/175736/ Оригинал]<br />
<br />
<br />
Посмотрим, какие стадии проходит Windows 2000 в процессе загрузки (подробнее об этом рассказано в [1]). После включения компьютера выполняется загрузка BIOS, которая проводит процедуру первоначального тестирования оборудования (POST), считывает запись Master Boot Record (MBR) и передает управление коду, содержащемуся в этой записи. Он выполняет проверку, ищет в корневом каталоге модуль ntldr и передает ему управление (MBR не может читать дерево подкаталогов, поэтому Ntldr всегда находится в корневом каталоге). В свою очередь, Ntldr обрабатывает файл boot.ini, выводит на экран меню вариантов загрузки или, если вариант один, не дожидаясь выбора, переходит к следующему этапу. На нем запускается 16-разрядное приложение ntdetect.com, которое получает информацию об оборудовании от BIOS и сохраняет ее во внутренних структурах. Затем ntldr выводит картинку — индикатор загрузки Windows 2000 — и предлагает нажать на F8. Действия операционной системы при выборе специальных вариантов загрузки по нажатию клавиши F8 мы здесь рассматривать не будем.<br />
<br />
Ntldr загружает ядро операционной системы и Hardware Abstraction Layer (HAL), которым, по умолчанию, соответствуют файлы Ntoskrnl.exe и HAL.dll. Далее загружаются необходимые (помеченные флажком SERVICE_BOOT_START) драйверы устройств, описанные в файле SYSTEM, содержащем соответствующий раздел реестра. После этого загрузчик производит действия, необходимые для запуска ntoskrnl.exe, и передает управление его главной функции. Здесь происходит много всяких, во-первых, сложных и, во-вторых, не представляющих сейчас для нас интереса событий. Но в числе прочего создается процесс Smss, который формирует среду пользовательского режима. Smss запускает подсистему Win32, программы, перечисленные в HKLM\SYSTEM\CurrentControlSet\ Control\Session Manager\BootExecute, инициализирует реестр, переменные окружения и другие «мелочи» и, наконец, запускает процесс Winlogon.<br />
<br />
Далее ответственность за дальнейшую инициализацию системы ложится на Winlogon. Он формирует объект WindowStation и три рабочих стола — пользовательский, хранителя экрана и Winlogon; загружает GINA DLL (!), создает процесс диспетчера управления службами (SCM), загружает все службы и драйверы устройств, помеченные для автоматического запуска, и запускает процесс Lsass. После того как пользователь успешно зарегистрировался, а SCM запустил службы и драйверы, загрузка считается успешно завершенной, и LastKnownGood обновляется в соответствии с текущими установками.</div>192.168.51.51https://wiki.welard.com/index.php?title=Windows_boot&diff=1883Windows boot2009-10-30T21:13:45Z<p>192.168.51.51: Created page with ' == Загрузка Windows == [http://www.osp.ru/win2000/2003/01/175736/ Оригинал] Посмотрим, какие стадии проходит Windows 2000 в пр...'</p>
<hr />
<div><br />
== Загрузка Windows ==<br />
<br />
[http://www.osp.ru/win2000/2003/01/175736/ Оригинал]<br />
<br />
<br />
Посмотрим, какие стадии проходит Windows 2000 в процессе загрузки (подробнее об этом рассказано в [1]). После включения компьютера выполняется загрузка BIOS, которая проводит процедуру первоначального тестирования оборудования (POST), считывает запись Master Boot Record (MBR) и передает управление коду, содержащемуся в этой записи. Он выполняет проверку, ищет в корневом каталоге модуль ntldr и передает ему управление (MBR не может читать дерево подкаталогов, поэтому Ntldr всегда находится в корневом каталоге). В свою очередь, Ntldr обрабатывает файл boot.ini, выводит на экран меню вариантов загрузки или, если вариант один, не дожидаясь выбора, переходит к следующему этапу. На нем запускается 16-разрядное приложение ntdetect.com, которое получает информацию об оборудовании от BIOS и сохраняет ее во внутренних структурах. Затем ntldr выводит картинку — индикатор загрузки Windows 2000 — и предлагает нажать на F8. Действия операционной системы при выборе специальных вариантов загрузки по нажатию клавиши F8 мы здесь рассматривать не будем.<br />
<br />
Ntldr загружает ядро операционной системы и Hardware Abstraction Layer (HAL), которым, по умолчанию, соответствуют файлы Ntoskrnl.exe и HAL.dll. Далее загружаются необходимые (помеченные флажком SERVICE_BOOT_START) драйверы устройств, описанные в файле SYSTEM, содержащем соответствующий раздел реестра. После этого загрузчик производит действия, необходимые для запуска ntoskrnl.exe, и передает управление его главной функции. Здесь происходит много всяких, во-первых, сложных и, во-вторых, не представляющих сейчас для нас интереса событий. Но в числе прочего создается процесс Smss, который формирует среду пользовательского режима. Smss запускает подсистему Win32, программы, перечисленные в HKLM\SYSTEM\CurrentControlSet\ Control\Session Manager\BootExecute, инициализирует реестр, переменные окружения и другие «мелочи» и, наконец, запускает процесс Winlogon.<br />
<br />
Далее ответственность за дальнейшую инициализацию системы ложится на Winlogon. Он формирует объект WindowStation и три рабочих стола — пользовательский, хранителя экрана и Winlogon; загружает GINA DLL (!), создает процесс диспетчера управления службами (SCM), загружает все службы и драйверы устройств, помеченные для автоматического запуска, и запускает процесс Lsass. После того как пользователь успешно зарегистрировался, а SCM запустил службы и драйверы, загрузка считается успешно завершенной, и LastKnownGood обновляется в соответствии с текущими установками.</div>192.168.51.51https://wiki.welard.com/index.php?title=Linux&diff=1882Linux2009-10-23T21:15:44Z<p>192.168.51.51: </p>
<hr />
<div>Операційна система <br />
<br />
[[Linux Шпаргалка]]<br />
[[Checkinstall]]<br />
[[Fstab]]<br />
[[Установить Linux по сети]]<br />
[[LDAP-configure]]<br />
[[Mail setting]]<br />
[[OpenSSL]]<br />
[[Centos Repo]]<br />
[[Centos multimedia]]<br />
[[Yum]]<br />
[[RPM]]<br />
[[Управління rpm]]<br />
[[Ssh]]<br />
[[SPF]]<br />
[[OpenVPN]]<br />
[[Nfs 3]]<br />
[[Nginx-as-reverse-proxy]]<br />
[[Ldap-errors]]<br />
[[DNS]]<br />
[[Iptables]]<br />
[[OpenLDAP]]<br />
[[Iptables]]<br />
[[Mod ssl]]<br />
[[SSL configure]]<br />
[[СentOS]]<br />
[[Php fastcgi]]<br />
[[Nginx Django]]<br />
[[Vim]]<br />
[[Захист SSH]]<br />
[[Install FTP Server]]<br />
[[Iftop]]<br />
[[Webmin]]<br />
[[Squid]]<br />
[[EraseDNS]]<br />
[[Rtorrent]]<br />
[[Довбана переключалка клавіатури в Linux]]<br />
[[Centos services]]<br />
[[Mini centos]]<br />
[[Ubuntu]]<br />
[[Trac]]<br />
[[Mc]]<br />
[[ZTEA2726]] Настройка 3G модема під Linux</div>192.168.51.51https://wiki.welard.com/index.php?title=Mc&diff=1881Mc2009-10-23T21:15:22Z<p>192.168.51.51: Created page with '== Midnight commander. == Запустим mc и будем настраивать его так, как я считаю нужным. Прежде всего зайдем в ...'</p>
<hr />
<div>== Midnight commander. ==<br />
<br />
Запустим mc и будем настраивать его так, как я считаю нужным. <br />
Прежде всего зайдем в меню F9 и в Options поставим в Display Bits поддержку 8bit символов на входе и выходе. Опять в Options->Layout:<br />
<br />
Убрать menubar visible (экранное пространство очень дорого чтобы там валялась бестолковая строчка с меню)<br />
<br />
Убрать keybar visible (по тем же соображениям, кнопки все надо помнить наизусть!)<br />
<br />
Включить hintbar visible (там будет показано много интересного)<br />
<br />
Запишите все опции. Теперь mc принял приемлемый вид.<br />
Понятно что просмотр содержимого каталогов сразу по входу в них - это очень удобно. <br />
Не надо все время давить ls -la для просмотра состояния каталога. Все показано к тому же в удобоваримом виде.<br />
<br />
Какие кнопки давить?<br />
<br />
Insert - отмечать файлы и каталоги<br />
Ctrl-ENTER (ESC+ENTER или Alt-ENTER) - послать текущий об'ект в командную строку<br />
Ctrl-X+T - послать выделенные об'екты в командную строку<br />
Alt-p (ESC+p) - вернуть предыдущую (предыдущие) командную строку (строки)<br />
Alt-n (ESC+n) - вернуть последующую (последующие) командную строку (строки)<br />
Ctrl-\ - hotlist (для частоиспользуемых директорий)<br />
Shift-F3 - просмотр файла (raw/ без учета расширения)<br />
Shift-F4 - создать новый файл<br />
F12 - Save as<br />
Ctrl-O - погасить панели и посмотреть что под ними (работает ТОЛЬКО в linux!)<br />
здесь же можно поработать в shell'e.<br />
Если при включенных панелях у вас не запускается ничего и выдается<br />
ошибка "The shell is already running a command" - это значит что нужно<br />
освободить шелл. Погасите снова панели и нажмите ENTER пару раз.<br />
Ctrl-S - поиск файла<br />
Сtrl-X+A - текущие VFS (ftp и пр.)<br />
Ctrl-X+C - посмотреть/поменять permissions<br />
Ctrl-X+O - посмотреть/поменять owner<br />
Ctrl-X+L - создать link<br />
Ctrl-X+S - создать symlink<br />
Ctrl-X+Ctrl-S - редактировать symlink<br />
Ctrl-X+D - сравнить каталоги<br />
Ctrl-X+J - фоновые задачи<br />
Ctrl-X+Q - быстрый просмотр содержимого файла<br />
<br />
ESC+A - послать в ком.строку текущий каталог<br />
ESC+C - быстро сменить каталог<br />
ESC+H - history<br />
ESC+P - вернуть предыдущую (предыдущие) командную строку (строки)<br />
ESC+N - вернуть последующую (последующие) командную строку (строки)<br />
ESC+S - поиск файла (в текущей директории)<br />
ESC+? - раширенный поиск фала (или вхождения/regular expression)<br />
ESC+цифра - тоже что и F{цифра} (ESC+5 = F5)<br />
<br />
F4 (в редакторе) - поиск с заменой<br />
F6 (в редакторе) - поиск с помощью регулярного выражения<br />
Shift-Del (в редакторе) - удалить блок (и положить его в clipboard)<br />
Shift-Ins (в редакторе) - вставить блок из clipboard (работает даже в другой консоли!!!) <br />
Можно редактировать два и более файлов на разных консолях и гонять блоки между ними.<br />
<br />
Alt-TAB (ESC+TAB) - Крутейшая кнопка для поиска загружаемых файлов (например вы забыли как полностью пишется netcfg. <br />
Достаточно набрать в командной строке net и нажать Alt-TAB - вам сразу покажут что можно запустить, <br />
которое начинается со слова net) нажимать два раза!<br />
Alt-TAB (ESC+TAB) - работает так же как в Bash TAB (т.е. подгоняет по первым буквам имена файлов или директорий. <br />
Наберите cd /u потом Alt-TAB - сразу будет cd /usr/ и т.д.)</div>192.168.51.51https://wiki.welard.com/index.php?title=SSL_configure&diff=1457SSL configure2009-03-24T19:00:28Z<p>192.168.51.51: </p>
<hr />
<div>== Установка Certificate Authority (CA) using OpenSSL ==<br />
[[ http://www.felipe-alfaro.org/blog/2005/11/18/setting-up-certificate-authority-ca-using-openssl/ |original ]]<br />
<br />
'''OpenSSL''' утилиты дают большую функциональность. OpenSSL может генерировать '''private keys''' приватные ключи и соответствующие им запросы сертификатов открытого ключа '''public key certificate requests''', может подписывать запросы сертификатов, публиковать анулирование серртификатов '''certificate revocation lists (CRLs)''', конвертировать между некоторыми форматами кодировок например DER, PEM, PKCS#12, etc.<br />
<br />
В этом статье я опишу как использовать OpenSSL, чтобы установить Certificate Authority (CA), как сгенерировать приватный ключ, генерировать запрос сертификатов и подписать их, ипользуя OpenSSL и command-line утилиты на CentOS Linux system.<br />
<br />
<br />
== Конфигурироание OpenSSL ==<br />
Редактируем /etc/pki/tls/openssl.cnf и удостовертесь, что секция [ CA_default ] выглядит следующим образом:<br />
обратите внимание на выделенное <br />
<br />
[ CA_default ]<br />
<br />
dir = /etc/pki/CA # Where everything is kept<br />
certs = $dir/certs # Where the issued certs are kept<br />
crl_dir = $dir/crl # Where the issued crl are kept<br />
database = $dir/'''index.txt''' # database index file.<br />
unique_subject = no # Set to 'no' to allow creation of<br />
# several ctificates with same subject.<br />
new_certs_dir = $dir/'''newcerts''' # default place for new certs.<br />
<br />
certificate = $dir/'''cacert.pem''' # The CA certificate<br />
serial = $dir/'''serial''' # The current serial number<br />
#crlnumber = $dir/crlnumber # the current crl number must be<br />
# commented out to leave a V1 CRL<br />
crl = $dir/crl.pem # The current CRL<br />
private_key = $dir/private/'''cakey.pem'''# The private key<br />
RANDFILE = $dir/private/.rand # private random number file<br />
<br />
x509_extensions = usr_cert # The extentions to add to the cert<br />
<br />
# Comment out the following two lines for the "traditional"<br />
# (and highly broken) format.<br />
name_opt = ca_default # Subject Name options<br />
cert_opt = ca_default # Certificate field options<br />
<br />
# Extension copying option: use with caution.<br />
# copy_extensions = copy<br />
<br />
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs<br />
# so this is commented out by default to leave a V1 CRL.<br />
# crlnumber must also be commented out to leave a V1 CRL.<br />
# crl_extensions = crl_ext<br />
<br />
default_days = 365 # how long to certify for<br />
default_crl_days= 30 # how long before next CRL<br />
default_md = sha1 # which md to use.<br />
preserve = no # keep passed DN ordering<br />
<br />
# A few difference way of specifying how similar the request should look<br />
# For type CA, the listed attributes must be the same, and the optional<br />
# and supplied fields are just that.<br />
policy = policy_match<br />
<br />
<br />
== Создание Certificate Authority (CA) ==<br />
<br />
Этим шагом мы создадим '''CA private key''' приватный ключ и самоподписываемый the '''CA certificate''' сертификат .<br />
Сертификат '''CA certificate''' будет сохранен в '''/etc/pki/CA/cacert.pem''', тогда как '''CA private key''' будет сохранен в '''/etc/pki/CA/private/cakey.pem''':<br />
'''openssl req -new -x509 -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem'''<br />
'''chmod 600 /etc/pki/CA/private/cakey.pem'''<br />
<br />
копия каждого подписанного сертификата будет сохранена в '''/etc/pki/CA/newcerts''', с именем которое подходит серийному номеру сертификата плюс .pem расширение:<br />
'''mkdir /etc/pki/CA/newcerts'''<br />
Файл /etc/pki/CA/index.txt содержит лог каждого подписанного сертификата:<br />
'''touch /etc/pki/CA/index.txt'''<br />
Файл /etc/pki/CA/serial файл содержит следующий X.509 свободный серийный номер:<br />
'''echo 01 > /etc/pki/CA/serial'''<br />
<br />
== Генерирование запроса сертификата и соответствующего ему приватного ключа ==<br />
<br />
Следующая команда сгенерирует , 1024-bit приватный RSA ключ и соответствующий ему публичный ключ будез завернут в PEM-encoded сертификат. Этот сертификат все еще не подписан и будет подан к CA на подпись позже:<br />
<br />
'''openssl req -new -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/sslkey.pem -out /etc/pki/CA/sslcert.pem'''<br />
<br />
Приватный ключ будет сохранен в /etc/pki/CA/sslkey.pem тогда как публичный ключ, закодирован в не подписанный сертификат, будет сохранен в /etc/pki/CA/sslcert.pem.<br />
<br />
опция -nodes может быть использована что бы избежать pass-phrase для защиты приватного ключа. Это опционально, но некоторые приложения не могут прочитать приватный ключ если он защищен pass-phrase, тогда как другие FreeRADIUS делают это без проблем.<br />
<br />
<br />
== Подписывание Сертификата ==<br />
<br />
Что бы подписать сертификат сохраненный в /etc/pki/CA/sslcert.pem, используйте следующие комманды:,<br />
'''cd /etc/pki/CA/newcerts'''<br />
'''openssl ca -in /etc/pki/CA/sslcert.pem -out /etc/pki/CA/cert.pem'''<br />
<br />
Результирующий подписанный сертификат будет сохранен в /etc/pki/CA/cert.pem. когда сертификат подписан, то не подписанный сертификат можно удалить.</div>192.168.51.51https://wiki.welard.com/index.php?title=SSL_configure&diff=1456SSL configure2009-03-24T18:59:33Z<p>192.168.51.51: </p>
<hr />
<div>== Setting up Certificate Authority (CA) using OpenSSL ==<br />
[[ http://www.felipe-alfaro.org/blog/2005/11/18/setting-up-certificate-authority-ca-using-openssl/ |original ]]<br />
<br />
'''OpenSSL''' утилиты дают большую функциональность. OpenSSL может генерировать '''private keys''' приватные ключи и соответствующие им запросы сертификатов открытого ключа '''public key certificate requests''', может подписывать запросы сертификатов, публиковать анулирование серртификатов '''certificate revocation lists (CRLs)''', конвертировать между некоторыми форматами кодировок например DER, PEM, PKCS#12, etc.<br />
<br />
В этом статье я опишу как использовать OpenSSL, чтобы установить Certificate Authority (CA), как сгенерировать приватный ключ, генерировать запрос сертификатов и подписать их, ипользуя OpenSSL и command-line утилиты на CentOS Linux system.<br />
<br />
<br />
== Конфигурироание OpenSSL ==<br />
Редактируем /etc/pki/tls/openssl.cnf и удостовертесь, что секция [ CA_default ] выглядит следующим образом:<br />
обратите внимание на выделенное <br />
<br />
[ CA_default ]<br />
<br />
dir = /etc/pki/CA # Where everything is kept<br />
certs = $dir/certs # Where the issued certs are kept<br />
crl_dir = $dir/crl # Where the issued crl are kept<br />
database = $dir/'''index.txt''' # database index file.<br />
unique_subject = no # Set to 'no' to allow creation of<br />
# several ctificates with same subject.<br />
new_certs_dir = $dir/'''newcerts''' # default place for new certs.<br />
<br />
certificate = $dir/'''cacert.pem''' # The CA certificate<br />
serial = $dir/'''serial''' # The current serial number<br />
#crlnumber = $dir/crlnumber # the current crl number must be<br />
# commented out to leave a V1 CRL<br />
crl = $dir/crl.pem # The current CRL<br />
private_key = $dir/private/'''cakey.pem'''# The private key<br />
RANDFILE = $dir/private/.rand # private random number file<br />
<br />
x509_extensions = usr_cert # The extentions to add to the cert<br />
<br />
# Comment out the following two lines for the "traditional"<br />
# (and highly broken) format.<br />
name_opt = ca_default # Subject Name options<br />
cert_opt = ca_default # Certificate field options<br />
<br />
# Extension copying option: use with caution.<br />
# copy_extensions = copy<br />
<br />
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs<br />
# so this is commented out by default to leave a V1 CRL.<br />
# crlnumber must also be commented out to leave a V1 CRL.<br />
# crl_extensions = crl_ext<br />
<br />
default_days = 365 # how long to certify for<br />
default_crl_days= 30 # how long before next CRL<br />
default_md = sha1 # which md to use.<br />
preserve = no # keep passed DN ordering<br />
<br />
# A few difference way of specifying how similar the request should look<br />
# For type CA, the listed attributes must be the same, and the optional<br />
# and supplied fields are just that.<br />
policy = policy_match<br />
<br />
<br />
== Создание Certificate Authority (CA) ==<br />
<br />
Этим шагом мы создадим '''CA private key''' приватный ключ и самоподписываемый the '''CA certificate''' сертификат .<br />
Сертификат '''CA certificate''' будет сохранен в '''/etc/pki/CA/cacert.pem''', тогда как '''CA private key''' будет сохранен в '''/etc/pki/CA/private/cakey.pem''':<br />
'''openssl req -new -x509 -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem'''<br />
'''chmod 600 /etc/pki/CA/private/cakey.pem'''<br />
<br />
копия каждого подписанного сертификата будет сохранена в '''/etc/pki/CA/newcerts''', с именем которое подходит серийному номеру сертификата плюс .pem расширение:<br />
'''mkdir /etc/pki/CA/newcerts'''<br />
Файл /etc/pki/CA/index.txt содержит лог каждого подписанного сертификата:<br />
'''touch /etc/pki/CA/index.txt'''<br />
Файл /etc/pki/CA/serial файл содержит следующий X.509 свободный серийный номер:<br />
'''echo 01 > /etc/pki/CA/serial'''<br />
<br />
== Генерирование запроса сертификата и соответствующего ему приватного ключа ==<br />
<br />
Следующая команда сгенерирует , 1024-bit приватный RSA ключ и соответствующий ему публичный ключ будез завернут в PEM-encoded сертификат. Этот сертификат все еще не подписан и будет подан к CA на подпись позже:<br />
<br />
'''openssl req -new -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/sslkey.pem -out /etc/pki/CA/sslcert.pem'''<br />
<br />
Приватный ключ будет сохранен в /etc/pki/CA/sslkey.pem тогда как публичный ключ, закодирован в не подписанный сертификат, будет сохранен в /etc/pki/CA/sslcert.pem.<br />
<br />
опция -nodes может быть использована что бы избежать pass-phrase для защиты приватного ключа. Это опционально, но некоторые приложения не могут прочитать приватный ключ если он защищен pass-phrase, тогда как другие FreeRADIUS делают это без проблем.<br />
<br />
<br />
== Подписывание Сертификата ==<br />
<br />
Что бы подписать сертификат сохраненный в /etc/pki/CA/sslcert.pem, используйте следующие комманды:,<br />
'''cd /etc/pki/CA/newcerts'''<br />
'''openssl ca -in /etc/pki/CA/sslcert.pem -out /etc/pki/CA/cert.pem'''<br />
<br />
Результирующий подписанный сертификат будет сохранен в /etc/pki/CA/cert.pem. когда сертификат подписан, то не подписанный сертификат можно удалить.</div>192.168.51.51https://wiki.welard.com/index.php?title=SSL_configure&diff=1454SSL configure2009-03-24T18:58:25Z<p>192.168.51.51: </p>
<hr />
<div>== Setting up Certificate Authority (CA) using OpenSSL ==<br />
[[ http://www.felipe-alfaro.org/blog/2005/11/18/setting-up-certificate-authority-ca-using-openssl/ |original ]]<br />
<br />
'''OpenSSL''' утилиты дают большую функциональность. OpenSSL может генерировать '''private keys''' приватные ключи и соответствующие им запросы сертификатов открытого ключа '''public key certificate requests''', может подписывать запросы сертификатов, публиковать анулирование серртификатов '''certificate revocation lists (CRLs)''', конвертировать между некоторыми форматами кодировок например DER, PEM, PKCS#12, etc.<br />
<br />
В этом статье я опишу как использовать OpenSSL, чтобы установить Certificate Authority (CA), как сгенерировать приватный ключ, генерировать запрос сертификатов и подписать их, ипользуя OpenSSL и command-line утилиты на CentOS Linux system.<br />
<br />
<br />
== Configuring OpenSSL ==<br />
Редактируем /etc/pki/tls/openssl.cnf и удостовертесь, что секция [ CA_default ] выглядит следующим образом:<br />
обратите внимание на выделенное <br />
<br />
[ CA_default ]<br />
<br />
dir = /etc/pki/CA # Where everything is kept<br />
certs = $dir/certs # Where the issued certs are kept<br />
crl_dir = $dir/crl # Where the issued crl are kept<br />
database = $dir/'''index.txt''' # database index file.<br />
unique_subject = no # Set to 'no' to allow creation of<br />
# several ctificates with same subject.<br />
new_certs_dir = $dir/'''newcerts''' # default place for new certs.<br />
<br />
certificate = $dir/'''cacert.pem''' # The CA certificate<br />
serial = $dir/'''serial''' # The current serial number<br />
#crlnumber = $dir/crlnumber # the current crl number must be<br />
# commented out to leave a V1 CRL<br />
crl = $dir/crl.pem # The current CRL<br />
private_key = $dir/private/'''cakey.pem'''# The private key<br />
RANDFILE = $dir/private/.rand # private random number file<br />
<br />
x509_extensions = usr_cert # The extentions to add to the cert<br />
<br />
# Comment out the following two lines for the "traditional"<br />
# (and highly broken) format.<br />
name_opt = ca_default # Subject Name options<br />
cert_opt = ca_default # Certificate field options<br />
<br />
# Extension copying option: use with caution.<br />
# copy_extensions = copy<br />
<br />
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs<br />
# so this is commented out by default to leave a V1 CRL.<br />
# crlnumber must also be commented out to leave a V1 CRL.<br />
# crl_extensions = crl_ext<br />
<br />
default_days = 365 # how long to certify for<br />
default_crl_days= 30 # how long before next CRL<br />
default_md = sha1 # which md to use.<br />
preserve = no # keep passed DN ordering<br />
<br />
# A few difference way of specifying how similar the request should look<br />
# For type CA, the listed attributes must be the same, and the optional<br />
# and supplied fields are just that.<br />
policy = policy_match<br />
<br />
<br />
== Создание Certificate Authority (CA) ==<br />
<br />
Этим шагом мы создадим '''CA private key''' приватный ключ и самоподписываемый the '''CA certificate''' сертификат .<br />
Сертификат '''CA certificate''' будет сохранен в '''/etc/pki/CA/cacert.pem''', тогда как '''CA private key''' будет сохранен в '''/etc/pki/CA/private/cakey.pem''':<br />
'''openssl req -new -x509 -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem'''<br />
'''chmod 600 /etc/pki/CA/private/cakey.pem'''<br />
<br />
копия каждого подписанного сертификата будет сохранена в '''/etc/pki/CA/newcerts''', с именем которое подходит серийному номеру сертификата плюс .pem расширение:<br />
'''mkdir /etc/pki/CA/newcerts'''<br />
Файл /etc/pki/CA/index.txt содержит лог каждого подписанного сертификата:<br />
'''touch /etc/pki/CA/index.txt'''<br />
Файл /etc/pki/CA/serial файл содержит следующий X.509 свободный серийный номер:<br />
'''echo 01 > /etc/pki/CA/serial'''<br />
<br />
== Генерирование запроса сертификата и соответствующего ему приватного ключа ==<br />
<br />
Следующая команда сгенерирует , 1024-bit приватный RSA ключ и соответствующий ему публичный ключ будез завернут в PEM-encoded сертификат. Этот сертификат все еще не подписан и будет подан к CA на подпись позже:<br />
<br />
'''openssl req -new -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/sslkey.pem -out /etc/pki/CA/sslcert.pem'''<br />
<br />
Приватный ключ будет сохранен в /etc/pki/CA/sslkey.pem тогда как публичный ключ, закодирован в не подписанный сертификат, будет сохранен в /etc/pki/CA/sslcert.pem.<br />
<br />
опция -nodes может быть использована что бы избежать pass-phrase для защиты приватного ключа. Это опционально, но некоторые приложения не могут прочитать приватный ключ если он защищен pass-phrase, тогда как другие FreeRADIUS делают это без проблем.<br />
<br />
<br />
== Подписывание Сертификата ==<br />
<br />
Что бы подписать сертификат сохраненный в /etc/pki/CA/sslcert.pem, используйте следующие комманды:,<br />
'''cd /etc/pki/CA/newcerts'''<br />
'''openssl ca -in /etc/pki/CA/sslcert.pem -out /etc/pki/CA/cert.pem'''<br />
<br />
Результирующий подписанный сертификат будет сохранен в /etc/pki/CA/cert.pem. когда сертификат подписан, то не подписанный сертификат можно удалить.</div>192.168.51.51https://wiki.welard.com/index.php?title=SSL_configure&diff=1451SSL configure2009-03-24T18:50:58Z<p>192.168.51.51: </p>
<hr />
<div>== Setting up Certificate Authority (CA) using OpenSSL ==<br />
[[ http://www.felipe-alfaro.org/blog/2005/11/18/setting-up-certificate-authority-ca-using-openssl/ |original ]]<br />
<br />
'''OpenSSL''' утилиты дают большую функциональность. OpenSSL может генерировать '''private keys''' приватные ключи и соответствующие им запросы сертификатов открытого ключа '''public key certificate requests''', может подписывать запросы сертификатов, публиковать анулирование серртификатов '''certificate revocation lists (CRLs)''', конвертировать между некоторыми форматами кодировок например DER, PEM, PKCS#12, etc.<br />
<br />
В этом статье я опишу как использовать OpenSSL, чтобы установить Certificate Authority (CA), как сгенерировать приватный ключ, генерировать запрос сертификатов и подписать их, ипользуя OpenSSL и command-line утилиты на CentOS Linux system.<br />
<br />
<br />
== Configuring OpenSSL ==<br />
Редактируем /etc/pki/tls/openssl.cnf и удостовертесь, что секция [ CA_default ] выглядит следующим образом:<br />
обратите внимание на выделенное <br />
<br />
[ CA_default ]<br />
<br />
dir = /etc/pki/CA # Where everything is kept<br />
certs = $dir/certs # Where the issued certs are kept<br />
crl_dir = $dir/crl # Where the issued crl are kept<br />
database = $dir/'''index.txt''' # database index file.<br />
unique_subject = no # Set to 'no' to allow creation of<br />
# several ctificates with same subject.<br />
new_certs_dir = $dir/'''newcerts''' # default place for new certs.<br />
<br />
certificate = $dir/'''cacert.pem''' # The CA certificate<br />
serial = $dir/'''serial''' # The current serial number<br />
#crlnumber = $dir/crlnumber # the current crl number must be<br />
# commented out to leave a V1 CRL<br />
crl = $dir/crl.pem # The current CRL<br />
private_key = $dir/private/'''cakey.pem'''# The private key<br />
RANDFILE = $dir/private/.rand # private random number file<br />
<br />
x509_extensions = usr_cert # The extentions to add to the cert<br />
<br />
# Comment out the following two lines for the "traditional"<br />
# (and highly broken) format.<br />
name_opt = ca_default # Subject Name options<br />
cert_opt = ca_default # Certificate field options<br />
<br />
# Extension copying option: use with caution.<br />
# copy_extensions = copy<br />
<br />
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs<br />
# so this is commented out by default to leave a V1 CRL.<br />
# crlnumber must also be commented out to leave a V1 CRL.<br />
# crl_extensions = crl_ext<br />
<br />
default_days = 365 # how long to certify for<br />
default_crl_days= 30 # how long before next CRL<br />
default_md = sha1 # which md to use.<br />
preserve = no # keep passed DN ordering<br />
<br />
# A few difference way of specifying how similar the request should look<br />
# For type CA, the listed attributes must be the same, and the optional<br />
# and supplied fields are just that.<br />
policy = policy_match<br />
<br />
<br />
== Creating the Certificate Authority (CA) ==<br />
<br />
Этим шагом мы создадим '''CA private key''' приватный ключ и самоподписываемый the '''CA certificate''' сертификат .<br />
Сертификат '''CA certificate''' будет сохранен в '''/etc/pki/CA/cacert.pem''', тогда как '''CA private key''' будет сохранен в '''/etc/pki/CA/private/cakey.pem''':<br />
'''openssl req -new -x509 -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem'''<br />
'''chmod 600 /etc/pki/CA/private/cakey.pem'''<br />
<br />
копия каждого подписанного сертификата будет сохранена в '''/etc/pki/CA/newcerts''', с именем которое подходит серийному номеру сертификата плюс .pem расширение:<br />
'''mkdir /etc/pki/CA/newcerts'''<br />
Файл /etc/pki/CA/index.txt содержит лог каждого подписанного сертификата:<br />
'''touch /etc/pki/CA/index.txt'''<br />
Файл /etc/pki/CA/serial файл содержит следующий X.509 свободный серийный номер:<br />
'''echo 01 > /etc/pki/CA/serial'''<br />
<br />
== Генерирование запроса сертификата и соответствующий ему приватный ключ ==<br />
<br />
Следующая команда сгенерирует , 1024-bit приватный RSA ключ и соответствующий ему публичный ключ будез завернут в PEM-encoded сертификат. Этот сертификат все еще не подписан и будет подан к CA на подпись позже:<br />
<br />
'''openssl req -new -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/sslkey.pem -out /etc/pki/CA/sslcert.pem'''<br />
<br />
Приватный ключ будет сохранен в /etc/pki/CA/sslkey.pem тогда как публичный ключ, закодирован в не подписанный сертификат, будет сохранен в /etc/pki/CA/sslcert.pem.<br />
<br />
The -nodes option can be used to avoid using a pass-phrase to protect the private key. This is optional, but some applications are unable to read the private key if it was protected by a pass-phrase, while others like FreeRADIUS can do so with no problems at all.<br />
<br />
<br />
== Signing a certificate ==<br />
<br />
To sign a certificate stored in /etc/pki/CA/sslcert.pem, use the following command:,<br />
'''cd /etc/pki/CA/newcerts'''<br />
'''openssl ca -in /etc/pki/CA/sslcert.pem -out /etc/pki/CA/cert.pem'''<br />
<br />
The resulting signed certificate will get outputted to /etc/pki/CA/cert.pem. Once the certificate has been signed, the unsigned certificate can be safely deleted.</div>192.168.51.51https://wiki.welard.com/index.php?title=SSL_configure&diff=1450SSL configure2009-03-24T18:34:33Z<p>192.168.51.51: </p>
<hr />
<div>== Setting up Certificate Authority (CA) using OpenSSL ==<br />
[[ http://www.felipe-alfaro.org/blog/2005/11/18/setting-up-certificate-authority-ca-using-openssl/ |original ]]<br />
<br />
'''OpenSSL''' утилиты дают большую функциональность. OpenSSL может генерировать '''private keys''' приватные ключи и соответствующие им запросы сертификатов открытого ключа '''public key certificate requests''', может подписывать запросы сертификатов, публиковать анулирование серртификатов '''certificate revocation lists (CRLs)''', конвертировать между некоторыми форматами кодировок например DER, PEM, PKCS#12, etc.<br />
<br />
В этом статье я опишу как использовать OpenSSL, чтобы установить Certificate Authority (CA), как сгенерировать приватный ключ, генерировать запрос сертификатов и подписать их, ипользуя OpenSSL и command-line утилиты на CentOS Linux system.<br />
<br />
<br />
== Configuring OpenSSL ==<br />
Редактируем /etc/pki/tls/openssl.cnf и удостовертесь, что секция [ CA_default ] выглядит следующим образом:<br />
обратите внимание на выделенное <br />
<br />
[ CA_default ]<br />
<br />
dir = /etc/pki/CA # Where everything is kept<br />
certs = $dir/certs # Where the issued certs are kept<br />
crl_dir = $dir/crl # Where the issued crl are kept<br />
database = $dir/'''index.txt''' # database index file.<br />
unique_subject = no # Set to 'no' to allow creation of<br />
# several ctificates with same subject.<br />
new_certs_dir = $dir/'''newcerts''' # default place for new certs.<br />
<br />
certificate = $dir/'''cacert.pem''' # The CA certificate<br />
serial = $dir/'''serial''' # The current serial number<br />
#crlnumber = $dir/crlnumber # the current crl number must be<br />
# commented out to leave a V1 CRL<br />
crl = $dir/crl.pem # The current CRL<br />
private_key = $dir/private/'''cakey.pem'''# The private key<br />
RANDFILE = $dir/private/.rand # private random number file<br />
<br />
x509_extensions = usr_cert # The extentions to add to the cert<br />
<br />
# Comment out the following two lines for the "traditional"<br />
# (and highly broken) format.<br />
name_opt = ca_default # Subject Name options<br />
cert_opt = ca_default # Certificate field options<br />
<br />
# Extension copying option: use with caution.<br />
# copy_extensions = copy<br />
<br />
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs<br />
# so this is commented out by default to leave a V1 CRL.<br />
# crlnumber must also be commented out to leave a V1 CRL.<br />
# crl_extensions = crl_ext<br />
<br />
default_days = 365 # how long to certify for<br />
default_crl_days= 30 # how long before next CRL<br />
default_md = sha1 # which md to use.<br />
preserve = no # keep passed DN ordering<br />
<br />
# A few difference way of specifying how similar the request should look<br />
# For type CA, the listed attributes must be the same, and the optional<br />
# and supplied fields are just that.<br />
policy = policy_match<br />
<br />
<br />
== Creating the Certificate Authority (CA) ==<br />
<br />
Этим шагом мы создадим '''CA private key''' приватный ключ и самоподписываемый the '''CA certificate''' сертификат .<br />
Сертификат '''CA certificate''' будет сохранен в '''/etc/pki/CA/cacert.pem''', тогда как '''CA private key''' будет сохранен в '''/etc/pki/CA/private/cakey.pem''':<br />
'''openssl req -new -x509 -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem'''<br />
'''chmod 600 /etc/pki/CA/private/cakey.pem'''<br />
<br />
A copy of every signed certificate will be stored into /etc/pki/CA/newcerts, with a name matching the certificate serial number plus the .pem extension:<br />
'''mkdir /etc/pki/CA/newcerts'''<br />
The /etc/pki/CA/index.txt file holds a log of every signed certificate:<br />
'''touch /etc/pki/CA/index.txt'''<br />
The /etc/pki/CA/serial file holds the next available X.509 serial number:<br />
'''echo 01 > /etc/pki/CA/serial'''<br />
<br />
== Generating a certificate request and its corresponding private key ==<br />
<br />
The following command will generate a random, 1024-bit private RSA key and its corresponding public key will be wrapped into a PEM-encoded certificate. This certificate is still unsigned and will be submitted later to the CA for signing:<br />
<br />
'''openssl req -new -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/sslkey.pem -out /etc/pki/CA/sslcert.pem'''<br />
<br />
The private key will get written to /etc/pki/CA/sslkey.pem while the public key, encoded inside an unsigned certificate, will get written to /etc/pki/CA/sslcert.pem.<br />
<br />
The -nodes option can be used to avoid using a pass-phrase to protect the private key. This is optional, but some applications are unable to read the private key if it was protected by a pass-phrase, while others like FreeRADIUS can do so with no problems at all.<br />
<br />
<br />
== Signing a certificate ==<br />
<br />
To sign a certificate stored in /etc/pki/CA/sslcert.pem, use the following command:,<br />
'''cd /etc/pki/CA/newcerts'''<br />
'''openssl ca -in /etc/pki/CA/sslcert.pem -out /etc/pki/CA/cert.pem'''<br />
<br />
The resulting signed certificate will get outputted to /etc/pki/CA/cert.pem. Once the certificate has been signed, the unsigned certificate can be safely deleted.</div>192.168.51.51https://wiki.welard.com/index.php?title=SSL_configure&diff=1448SSL configure2009-03-24T18:19:21Z<p>192.168.51.51: </p>
<hr />
<div>== Setting up Certificate Authority (CA) using OpenSSL ==<br />
[[ http://www.felipe-alfaro.org/blog/2005/11/18/setting-up-certificate-authority-ca-using-openssl/ |original ]]<br />
<br />
OpenSSL утилиты дают большую функциональность. OpenSSL может генерировать '''private keys''' приватные ключи и соответствующие им '''public key certificate requests''' запросы сертификатов открытого ключа, может подписывать (sign) запросы сертификатов, публиковать анулирование серртификатов '''certificate revocation lists (CRLs)''', конвертировать между некоторыми форматами кодировок например DER, PEM, PKCS#12, etc.<br />
<br />
In this article I will describe how to use OpenSSL to set up a Certificate Authority (CA), how to generate private keys, generate certificate requests and sign them, using OpenSSL and the command-line on a Fedora Core 4 Linux system.<br />
<br />
<br />
== Configuring OpenSSL ==<br />
Edit /etc/pki/tls/openssl.cnf and make sure the [ CA_default ] section looks like this:<br />
<br />
[ CA_default ]<br />
<br />
dir = /etc/pki/CA # Where everything is kept<br />
certs = $dir/certs # Where the issued certs are kept<br />
crl_dir = $dir/crl # Where the issued crl are kept<br />
database = $dir/index.txt # database index file.<br />
unique_subject = no # Set to 'no' to allow creation of<br />
# several ctificates with same subject.<br />
new_certs_dir = $dir/newcerts # default place for new certs.<br />
<br />
certificate = $dir/cacert.pem # The CA certificate<br />
serial = $dir/serial # The current serial number<br />
#crlnumber = $dir/crlnumber # the current crl number must be<br />
# commented out to leave a V1 CRL<br />
crl = $dir/crl.pem # The current CRL<br />
private_key = $dir/private/cakey.pem# The private key<br />
RANDFILE = $dir/private/.rand # private random number file<br />
<br />
x509_extensions = usr_cert # The extentions to add to the cert<br />
<br />
# Comment out the following two lines for the "traditional"<br />
# (and highly broken) format.<br />
name_opt = ca_default # Subject Name options<br />
cert_opt = ca_default # Certificate field options<br />
<br />
# Extension copying option: use with caution.<br />
# copy_extensions = copy<br />
<br />
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs<br />
# so this is commented out by default to leave a V1 CRL.<br />
# crlnumber must also be commented out to leave a V1 CRL.<br />
# crl_extensions = crl_ext<br />
<br />
default_days = 365 # how long to certify for<br />
default_crl_days= 30 # how long before next CRL<br />
default_md = sha1 # which md to use.<br />
preserve = no # keep passed DN ordering<br />
<br />
# A few difference way of specifying how similar the request should look<br />
# For type CA, the listed attributes must be the same, and the optional<br />
# and supplied fields are just that.<br />
policy = policy_match<br />
<br />
<br />
== Creating the Certificate Authority (CA) ==<br />
<br />
This step will create the CA private key and a self-signed certificate (the CA certificate).<br />
The CA certificate will be stored in /etc/pki/CA/cacert.pem, while the CA private key will be stored in /etc/pki/CA/private/cakey.pem:<br />
'''openssl req -new -x509 -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem'''<br />
'''chmod 600 /etc/pki/CA/private/cakey.pem'''<br />
<br />
A copy of every signed certificate will be stored into /etc/pki/CA/newcerts, with a name matching the certificate serial number plus the .pem extension:<br />
'''mkdir /etc/pki/CA/newcerts'''<br />
The /etc/pki/CA/index.txt file holds a log of every signed certificate:<br />
'''touch /etc/pki/CA/index.txt'''<br />
The /etc/pki/CA/serial file holds the next available X.509 serial number:<br />
'''echo 01 > /etc/pki/CA/serial'''<br />
<br />
== Generating a certificate request and its corresponding private key ==<br />
<br />
The following command will generate a random, 1024-bit private RSA key and its corresponding public key will be wrapped into a PEM-encoded certificate. This certificate is still unsigned and will be submitted later to the CA for signing:<br />
<br />
'''openssl req -new -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/sslkey.pem -out /etc/pki/CA/sslcert.pem'''<br />
<br />
The private key will get written to /etc/pki/CA/sslkey.pem while the public key, encoded inside an unsigned certificate, will get written to /etc/pki/CA/sslcert.pem.<br />
<br />
The -nodes option can be used to avoid using a pass-phrase to protect the private key. This is optional, but some applications are unable to read the private key if it was protected by a pass-phrase, while others like FreeRADIUS can do so with no problems at all.<br />
<br />
<br />
== Signing a certificate ==<br />
<br />
To sign a certificate stored in /etc/pki/CA/sslcert.pem, use the following command:,<br />
'''cd /etc/pki/CA/newcerts'''<br />
'''openssl ca -in /etc/pki/CA/sslcert.pem -out /etc/pki/CA/cert.pem'''<br />
<br />
The resulting signed certificate will get outputted to /etc/pki/CA/cert.pem. Once the certificate has been signed, the unsigned certificate can be safely deleted.</div>192.168.51.51https://wiki.welard.com/index.php?title=Mail_setting&diff=1419Mail setting2009-03-24T07:22:57Z<p>192.168.51.51: </p>
<hr />
<div>[http://www.postfix.org/ Postfix ] Virtual Hosting с [http://www.openldap.org/ OpenLDAP], [http://www.dovecot.org/ Dovecot] как IMAP/POP3,[http://www.onyxbits.de/gnarwl Gnarwl] как автоответчик и [http://www.phamm.org/ Phamm] как интерфейс управления<br />
<br />
[http://www.howtoforge.com/postfix-virtual-hosting-with-ldap-backend-and-with-dovecot-pop3-imap-on-ubuntu-8.10 оригинал статьи]<br />
<br />
* Сначала устанавливаем нужные пакеты <br />
'''yum install OpenLDAP'''<br />
конфиг его здесь /etc/openldap/ldap.conf<br />
<br />
'''yum install openldap-servers'''<br />
в этом есть нужные схемы <br />
и конфиг его здесь /etc/openldap/slapd.conf<br />
<br />
<br />
создаем каталог <br />
'''mkdir /root/work/phamm-inst'''<br />
качаем <br />
'''cd /root/work/phamm-inst'''<br />
'''wget http://open.rhx.it/phamm/phamm-0.5.15.tar.gz'''<br />
раскручиваем <br />
'''tar xvzf phamm-0.5.15.tar.gz'''<br />
<br />
создаем файл каталог <br />
'''mkdir /etc/openldap/schema/phamm''' <br />
<br />
вытягиваем из phamm-0.5.15.tar.gz схему в каталог этот каталог<br />
'''cp phamm-0.5.15/schema/phamm.schema /etc/openldap/schema/phamm<br />
'''cd /etc/openldap/schema/phamm'''<br />
добавляем схемы <br />
'''wget http://open.rhx.it/phamm/schema/ISPEnv2.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/amavis.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/samba.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/pureftpd.schema''' <br />
<br />
правим файл конфигурации /etc/openldap/sldap.conf<br />
после строчек <br />
include /etc/openldap/schema/core.schema<br />
include /etc/openldap/schema/cosine.schema<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/inetorgperson.schema<br />
<br />
добавляем <br />
include /etc/openldap/schema/phamm/phamm.schema<br />
include /etc/openldap/schema/phamm/ISPEnv2.schema<br />
include /etc/openldap/schema/phamm/amavis.schema<br />
include /etc/openldap/schema/phamm/pureftpd.schema<br />
include /etc/openldap/schema/phamm/samba.schema<br />
<br />
Теперь изменяем конфиг ldif_out/cn=config/cn=schema/cn={4}phamm.ldif<br />
'''vi ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
чтобы получить следующее<br />
dn: cn=phamm,cn=schema,cn=config<br />
...<br />
cn: phamm<br />
и удаляем с конца ldif (дата и время могут оличатсья от приведенного нижк)<br />
structuralObjectClass: olcSchemaConfig<br />
entryUUID: 08bf1a06-7a89-102d-9fa6-4bee1e86d7f6<br />
creatorsName: cn=config<br />
createTimestamp: 20090119152440Z<br />
entryCSN: 20090119152440.275296Z#000000#000#000000<br />
modifiersName: cn=config<br />
modifyTimestamp: 20090119152440Z<br />
тоже самое делаем для файлов <br />
cn={5}ISPEnv2.ldif<br />
cn={6}amavis.ldif<br />
cn={7}pureftpd.ldif<br />
<br />
стартуем ldap [http://wiki/index.php/LDAP-configure Установка LDAP сервера]<br />
'''service ldap start''' <br />
'''chkconfig ldap on'''<br />
[http://wiki/index.php/ldap-errors Ldap не стартанул]<br />
<br />
теперь загружаем схемы файлы в OpenLDAP (пароль используем тот который установили при установке ldap сервера)<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{5\}ISPEnv2.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{6\}amavis.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{7\}pureftpd.ldif'''</div>192.168.51.51https://wiki.welard.com/index.php?title=LDAP-configure&diff=1417LDAP-configure2009-03-23T23:24:32Z<p>192.168.51.51: </p>
<hr />
<div>== Установка OpenLDAP сервера на CentOS 5 ==<br />
<br />
'''yum -y install openldap'''<br />
и правим файл настроек <br />
/etc/openldap/slapd.conf<br />
<br />
основные поля что обязательно надо поставить <br />
suffix "dc=server-linux,dc=info"<br />
rootdn "cn=Manager,dc=server-linux,dc=info"<br />
rootpw {MD5}************************<br />
<br />
копируем файл и устанавливаем атрибуты<br />
'''cp /etc/openldap/DB_CONFIG.example /var/lib/ldap/DB_CONFIG'''<br />
'''chown ldap:ldap /var/lib/ldap/DB_CONFIG'''<br />
и стартуем сервер<br />
'''service ldap start'''<br />
и что бы при каждом старте запускался <br />
'''chkconfig ldap on'''</div>192.168.51.51https://wiki.welard.com/index.php?title=LDAP-configure&diff=1416LDAP-configure2009-03-23T23:24:11Z<p>192.168.51.51: </p>
<hr />
<div>== Установка OpenLDAP сервера на CentOS 5 ==<br />
<br />
'''yum -y install openldap'''<br />
и правим файл настроек <br />
/etc/openldap/slapd.conf<br />
<br />
основные поля что обязательно надо поставить <br />
suffix "dc=server-linux,dc=info"<br />
rootdn "cn=Manager,dc=server-linux,dc=info"<br />
rootpw {MD5}************************<br />
<br />
копируем файл и устанавливаем атрибуты<br />
'''cp /etc/openldap/DB_CONFIG.example /var/lib/ldap/DB_CONFIG'''<br />
'''chown ldap:ldap /var/lib/ldap/DB_CONFIG'''<br />
и стартуем сервер<br />
service ldap start<br />
и что бы при каждом старте запускался <br />
chkconfig ldap on</div>192.168.51.51https://wiki.welard.com/index.php?title=LDAP-configure&diff=1415LDAP-configure2009-03-23T23:23:27Z<p>192.168.51.51: </p>
<hr />
<div>== Установка OpenLDAP сервера на CentOS 5 ==<br />
<br />
'''yum -y install openldap'''<br />
и правим файл настроек <br />
/etc/openldap/slapd.conf<br />
<br />
основные поля что обязательно надо поставить <br />
suffix "dc=server-linux,dc=info"<br />
rootdn "cn=Manager,dc=server-linux,dc=info"<br />
rootpw {MD5}************************<br />
<br />
копируем файл и устанавливаем атрибуты<br />
'''cp /etc/openldap/DB_CONFIG.example /var/lib/ldap/DB_CONFIG'''<br />
'''chown ldap:ldap /var/lib/ldap/DB_CONFIG'''<br />
и стартуем сервер</div>192.168.51.51https://wiki.welard.com/index.php?title=Mail_setting&diff=1414Mail setting2009-03-23T23:22:41Z<p>192.168.51.51: </p>
<hr />
<div>[http://www.postfix.org/ Postfix ] Virtual Hosting с [http://www.openldap.org/ OpenLDAP], [http://www.dovecot.org/ Dovecot] как IMAP/POP3,[http://www.onyxbits.de/gnarwl Gnarwl] как автоответчик и [http://www.phamm.org/ Phamm] как интерфейс управления<br />
<br />
[http://www.howtoforge.com/postfix-virtual-hosting-with-ldap-backend-and-with-dovecot-pop3-imap-on-ubuntu-8.10 оригинал статьи]<br />
<br />
* Сначала устанавливаем нужные пакеты <br />
'''yum install OpenLDAP'''<br />
конфиг его здесь /etc/openldap/ldap.conf<br />
<br />
'''yum install openldap-servers'''<br />
в этом есть нужные схемы <br />
и конфиг его здесь /etc/openldap/slapd.conf<br />
<br />
<br />
создаем каталог <br />
'''mkdir /root/work/phamm-inst'''<br />
качаем <br />
'''cd /root/work/phamm-inst'''<br />
'''wget http://open.rhx.it/phamm/phamm-0.5.15.tar.gz'''<br />
раскручиваем <br />
'''tar xvzf phamm-0.5.15.tar.gz'''<br />
<br />
вытягиваем из него схемы для удобства в свой каталог <br />
'''cp phamm-0.5.15/schema/phamm.schema /root/work/'''<br />
'''cd /root/work'''<br />
добавляем схемы <br />
<br />
'''wget http://open.rhx.it/phamm/schema/ISPEnv2.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/amavis.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/samba.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/pureftpd.schema''' <br />
<br />
<br />
создаем файл '''schema.convert''' с содержимым<br />
<br />
include /etc/openldap/schema/core.schema<br />
include /etc/openldap/schema/cosine.schema<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/inetorgperson.schema<br />
include phamm.schema<br />
include ISPEnv2.schema<br />
include amavis.schema<br />
include pureftpd.schema<br />
<br />
<br />
создаем временный каталог <br />
'''mkdir ldif_out'''<br />
и теперь конвертируем схемы в ldif файлы<br />
'''slaptest -f schema.convert -F ldif_out'''<br />
config file testing succeeded<br />
<br />
Теперь изменяем конфиг ldif_out/cn=config/cn=schema/cn={4}phamm.ldif<br />
'''vi ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
чтобы получить следующее<br />
dn: cn=phamm,cn=schema,cn=config<br />
...<br />
cn: phamm<br />
и удаляем с конца ldif (дата и время могут оличатсья от приведенного нижк)<br />
structuralObjectClass: olcSchemaConfig<br />
entryUUID: 08bf1a06-7a89-102d-9fa6-4bee1e86d7f6<br />
creatorsName: cn=config<br />
createTimestamp: 20090119152440Z<br />
entryCSN: 20090119152440.275296Z#000000#000#000000<br />
modifiersName: cn=config<br />
modifyTimestamp: 20090119152440Z<br />
тоже самое делаем для файлов <br />
cn={5}ISPEnv2.ldif<br />
cn={6}amavis.ldif<br />
cn={7}pureftpd.ldif<br />
<br />
стартуем ldap [http://wiki/index.php/LDAP-configure Установка LDAP сервера]<br />
'''service ldap start''' <br />
'''chkconfig ldap on'''<br />
[http://wiki/index.php/ldap-errors Ldap не стартанул]<br />
<br />
теперь загружаем схемы файлы в OpenLDAP (пароль используем тот который установили при установке ldap сервера)<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{5\}ISPEnv2.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{6\}amavis.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{7\}pureftpd.ldif'''</div>192.168.51.51https://wiki.welard.com/index.php?title=LDAP-configure&diff=1413LDAP-configure2009-03-23T23:21:46Z<p>192.168.51.51: </p>
<hr />
<div><br />
== Установка OpenLDAP сервера на CentOS 5 ==<br />
<br />
'''yum -y install openldap'''<br />
и правим файл настроек <br />
'''/etc/openldap/slapd.conf'''<br />
<br />
основные поля что обязательно надо поставить <br />
suffix "dc=server-linux,dc=info"<br />
rootdn "cn=Manager,dc=server-linux,dc=info"<br />
rootpw {MD5}************************<br />
<br />
копируем файл и устанавливаем атрибуты<br />
cp /etc/openldap/DB_CONFIG.example /var/lib/ldap/DB_CONFIG<br />
chown ldap:ldap /var/lib/ldap/DB_CONFIG<br />
и стартуем сервер</div>192.168.51.51https://wiki.welard.com/index.php?title=Ldap-errors&diff=1412Ldap-errors2009-03-23T23:17:24Z<p>192.168.51.51: </p>
<hr />
<div><br />
== Если LDAP сервер не запускается ==<br />
<br />
для Centos 5<br />
настройка [http://wiki/index.php/LDAP-configure Установка OpenLDAP сервера ] сервера <br />
база ldap содержиться в каталоге '''/var/lib/ldap'''<br />
<br />
вероятные причины в нем отсутствует файл '''DB_CONFIG'''<br />
<br />
копируем его с /etc/openldap/DB_CONFIG.example<br />
''' cp /etc/openldap/DB_CONFIG.example /var/lib/ldap/DB_CONFIG'''<br />
и пробуем перестартовать, если возникли ошибки смотрим в<br />
/etc/openldap/slapd.conf</div>192.168.51.51https://wiki.welard.com/index.php?title=Mail_setting&diff=1411Mail setting2009-03-23T23:11:41Z<p>192.168.51.51: </p>
<hr />
<div>[http://www.postfix.org/ Postfix ] Virtual Hosting с [http://www.openldap.org/ OpenLDAP], [http://www.dovecot.org/ Dovecot] как IMAP/POP3,[http://www.onyxbits.de/gnarwl Gnarwl] как автоответчик и [http://www.phamm.org/ Phamm] как интерфейс управления<br />
<br />
[http://www.howtoforge.com/postfix-virtual-hosting-with-ldap-backend-and-with-dovecot-pop3-imap-on-ubuntu-8.10 оригинал статьи]<br />
<br />
* Сначала устанавливаем нужные пакеты <br />
'''yum install OpenLDAP'''<br />
конфиг его здесь /etc/openldap/ldap.conf<br />
<br />
'''yum install openldap-servers'''<br />
в этом есть нужные схемы <br />
и конфиг его здесь /etc/openldap/slapd.conf<br />
<br />
<br />
создаем каталог <br />
'''mkdir /root/work/phamm-inst'''<br />
качаем <br />
'''cd /root/work/phamm-inst'''<br />
'''wget http://open.rhx.it/phamm/phamm-0.5.15.tar.gz'''<br />
раскручиваем <br />
'''tar xvzf phamm-0.5.15.tar.gz'''<br />
<br />
вытягиваем из него схемы для удобства в свой каталог <br />
'''cp phamm-0.5.15/schema/phamm.schema /root/work/'''<br />
'''cd /root/work'''<br />
добавляем схемы <br />
<br />
'''wget http://open.rhx.it/phamm/schema/ISPEnv2.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/amavis.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/samba.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/pureftpd.schema''' <br />
<br />
<br />
создаем файл '''schema.convert''' с содержимым<br />
<br />
include /etc/openldap/schema/core.schema<br />
include /etc/openldap/schema/cosine.schema<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/inetorgperson.schema<br />
include phamm.schema<br />
include ISPEnv2.schema<br />
include amavis.schema<br />
include pureftpd.schema<br />
<br />
<br />
создаем временный каталог <br />
'''mkdir ldif_out'''<br />
и теперь конвертируем схемы в ldif файлы<br />
'''slaptest -f schema.convert -F ldif_out'''<br />
config file testing succeeded<br />
<br />
Теперь изменяем конфиг ldif_out/cn=config/cn=schema/cn={4}phamm.ldif<br />
'''vi ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
чтобы получить следующее<br />
dn: cn=phamm,cn=schema,cn=config<br />
...<br />
cn: phamm<br />
и удаляем с конца ldif (дата и время могут оличатсья от приведенного нижк)<br />
structuralObjectClass: olcSchemaConfig<br />
entryUUID: 08bf1a06-7a89-102d-9fa6-4bee1e86d7f6<br />
creatorsName: cn=config<br />
createTimestamp: 20090119152440Z<br />
entryCSN: 20090119152440.275296Z#000000#000#000000<br />
modifiersName: cn=config<br />
modifyTimestamp: 20090119152440Z<br />
тоже самое делаем для файлов <br />
cn={5}ISPEnv2.ldif<br />
cn={6}amavis.ldif<br />
cn={7}pureftpd.ldif<br />
<br />
стартуем ldap <br />
'''service ldap start''' <br />
'''chkconfig ldap on'''<br />
[http://wiki/index.php/ldap-errors Ldap не стартанул]<br />
<br />
теперь загружаем схемы файлы в OpenLDAP (пароль используем тот который установили при установке ldap сервера)<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{5\}ISPEnv2.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{6\}amavis.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{7\}pureftpd.ldif'''</div>192.168.51.51https://wiki.welard.com/index.php?title=Mail_setting&diff=1410Mail setting2009-03-23T23:11:18Z<p>192.168.51.51: </p>
<hr />
<div>[http://www.postfix.org/ Postfix ] Virtual Hosting с [http://www.openldap.org/ OpenLDAP], [http://www.dovecot.org/ Dovecot] как IMAP/POP3,[http://www.onyxbits.de/gnarwl Gnarwl] как автоответчик и [http://www.phamm.org/ Phamm] как интерфейс управления<br />
<br />
[http://www.howtoforge.com/postfix-virtual-hosting-with-ldap-backend-and-with-dovecot-pop3-imap-on-ubuntu-8.10 оригинал статьи]<br />
<br />
* Сначала устанавливаем нужные пакеты <br />
'''yum install OpenLDAP'''<br />
конфиг его здесь /etc/openldap/ldap.conf<br />
<br />
'''yum install openldap-servers'''<br />
в этом есть нужные схемы <br />
и конфиг его здесь /etc/openldap/slapd.conf<br />
<br />
<br />
создаем каталог <br />
'''mkdir /root/work/phamm-inst'''<br />
качаем <br />
'''cd /root/work/phamm-inst'''<br />
'''wget http://open.rhx.it/phamm/phamm-0.5.15.tar.gz'''<br />
раскручиваем <br />
'''tar xvzf phamm-0.5.15.tar.gz'''<br />
<br />
вытягиваем из него схемы для удобства в свой каталог <br />
'''cp phamm-0.5.15/schema/phamm.schema /root/work/'''<br />
'''cd /root/work'''<br />
добавляем схемы <br />
<br />
'''wget http://open.rhx.it/phamm/schema/ISPEnv2.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/amavis.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/samba.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/pureftpd.schema''' <br />
<br />
<br />
создаем файл '''schema.convert''' с содержимым<br />
<br />
include /etc/openldap/schema/core.schema<br />
include /etc/openldap/schema/cosine.schema<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/inetorgperson.schema<br />
include phamm.schema<br />
include ISPEnv2.schema<br />
include amavis.schema<br />
include pureftpd.schema<br />
<br />
<br />
создаем временный каталог <br />
'''mkdir ldif_out'''<br />
и теперь конвертируем схемы в ldif файлы<br />
'''slaptest -f schema.convert -F ldif_out'''<br />
config file testing succeeded<br />
<br />
Теперь изменяем конфиг ldif_out/cn=config/cn=schema/cn={4}phamm.ldif<br />
'''vi ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
чтобы получить следующее<br />
dn: cn=phamm,cn=schema,cn=config<br />
...<br />
cn: phamm<br />
и удаляем с конца ldif (дата и время могут оличатсья от приведенного нижк)<br />
structuralObjectClass: olcSchemaConfig<br />
entryUUID: 08bf1a06-7a89-102d-9fa6-4bee1e86d7f6<br />
creatorsName: cn=config<br />
createTimestamp: 20090119152440Z<br />
entryCSN: 20090119152440.275296Z#000000#000#000000<br />
modifiersName: cn=config<br />
modifyTimestamp: 20090119152440Z<br />
тоже самое делаем для файлов <br />
cn={5}ISPEnv2.ldif<br />
cn={6}amavis.ldif<br />
cn={7}pureftpd.ldif<br />
<br />
стартуем ldap <br />
'''service ldap start''' <br />
'''chkconfig ldap on'''<br />
[http://wiki/index.php?ldap-errors Ldap не стартанул]<br />
<br />
теперь загружаем схемы файлы в OpenLDAP (пароль используем тот который установили при установке ldap сервера)<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{5\}ISPEnv2.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{6\}amavis.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{7\}pureftpd.ldif'''</div>192.168.51.51https://wiki.welard.com/index.php?title=Mail_setting&diff=1409Mail setting2009-03-23T23:10:50Z<p>192.168.51.51: </p>
<hr />
<div>[http://www.postfix.org/ Postfix ] Virtual Hosting с [http://www.openldap.org/ OpenLDAP], [http://www.dovecot.org/ Dovecot] как IMAP/POP3,[http://www.onyxbits.de/gnarwl Gnarwl] как автоответчик и [http://www.phamm.org/ Phamm] как интерфейс управления<br />
<br />
[http://www.howtoforge.com/postfix-virtual-hosting-with-ldap-backend-and-with-dovecot-pop3-imap-on-ubuntu-8.10 оригинал статьи]<br />
<br />
* Сначала устанавливаем нужные пакеты <br />
'''yum install OpenLDAP'''<br />
конфиг его здесь /etc/openldap/ldap.conf<br />
<br />
'''yum install openldap-servers'''<br />
в этом есть нужные схемы <br />
и конфиг его здесь /etc/openldap/slapd.conf<br />
<br />
<br />
создаем каталог <br />
'''mkdir /root/work/phamm-inst'''<br />
качаем <br />
'''cd /root/work/phamm-inst'''<br />
'''wget http://open.rhx.it/phamm/phamm-0.5.15.tar.gz'''<br />
раскручиваем <br />
'''tar xvzf phamm-0.5.15.tar.gz'''<br />
<br />
вытягиваем из него схемы для удобства в свой каталог <br />
'''cp phamm-0.5.15/schema/phamm.schema /root/work/'''<br />
'''cd /root/work'''<br />
добавляем схемы <br />
<br />
'''wget http://open.rhx.it/phamm/schema/ISPEnv2.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/amavis.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/samba.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/pureftpd.schema''' <br />
<br />
<br />
создаем файл '''schema.convert''' с содержимым<br />
<br />
include /etc/openldap/schema/core.schema<br />
include /etc/openldap/schema/cosine.schema<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/inetorgperson.schema<br />
include phamm.schema<br />
include ISPEnv2.schema<br />
include amavis.schema<br />
include pureftpd.schema<br />
<br />
<br />
создаем временный каталог <br />
'''mkdir ldif_out'''<br />
и теперь конвертируем схемы в ldif файлы<br />
'''slaptest -f schema.convert -F ldif_out'''<br />
config file testing succeeded<br />
<br />
Теперь изменяем конфиг ldif_out/cn=config/cn=schema/cn={4}phamm.ldif<br />
'''vi ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
чтобы получить следующее<br />
dn: cn=phamm,cn=schema,cn=config<br />
...<br />
cn: phamm<br />
и удаляем с конца ldif (дата и время могут оличатсья от приведенного нижк)<br />
structuralObjectClass: olcSchemaConfig<br />
entryUUID: 08bf1a06-7a89-102d-9fa6-4bee1e86d7f6<br />
creatorsName: cn=config<br />
createTimestamp: 20090119152440Z<br />
entryCSN: 20090119152440.275296Z#000000#000#000000<br />
modifiersName: cn=config<br />
modifyTimestamp: 20090119152440Z<br />
тоже самое делаем для файлов <br />
cn={5}ISPEnv2.ldif<br />
cn={6}amavis.ldif<br />
cn={7}pureftpd.ldif<br />
<br />
стартуем ldap <br />
'''service ldap start''' <br />
'''chkconfig ldap on'''<br />
[http://wiki/ldap-errors Ldap не стартанул]<br />
<br />
теперь загружаем схемы файлы в OpenLDAP (пароль используем тот который установили при установке ldap сервера)<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{5\}ISPEnv2.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{6\}amavis.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{7\}pureftpd.ldif'''</div>192.168.51.51https://wiki.welard.com/index.php?title=Mail_setting&diff=1408Mail setting2009-03-23T23:09:20Z<p>192.168.51.51: </p>
<hr />
<div>[http://www.postfix.org/ Postfix ] Virtual Hosting с [http://www.openldap.org/ OpenLDAP], [http://www.dovecot.org/ Dovecot] как IMAP/POP3,[http://www.onyxbits.de/gnarwl Gnarwl] как автоответчик и [http://www.phamm.org/ Phamm] как интерфейс управления<br />
<br />
[http://www.howtoforge.com/postfix-virtual-hosting-with-ldap-backend-and-with-dovecot-pop3-imap-on-ubuntu-8.10 оригинал статьи]<br />
<br />
* Сначала устанавливаем нужные пакеты <br />
'''yum install OpenLDAP'''<br />
конфиг его здесь /etc/openldap/ldap.conf<br />
<br />
'''yum install openldap-servers'''<br />
в этом есть нужные схемы <br />
и конфиг его здесь /etc/openldap/slapd.conf<br />
<br />
<br />
создаем каталог <br />
'''mkdir /root/work/phamm-inst'''<br />
качаем <br />
'''cd /root/work/phamm-inst'''<br />
'''wget http://open.rhx.it/phamm/phamm-0.5.15.tar.gz'''<br />
раскручиваем <br />
'''tar xvzf phamm-0.5.15.tar.gz'''<br />
<br />
вытягиваем из него схемы для удобства в свой каталог <br />
'''cp phamm-0.5.15/schema/phamm.schema /root/work/'''<br />
'''cd /root/work'''<br />
добавляем схемы <br />
<br />
'''wget http://open.rhx.it/phamm/schema/ISPEnv2.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/amavis.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/samba.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/pureftpd.schema''' <br />
<br />
<br />
создаем файл '''schema.convert''' с содержимым<br />
<br />
include /etc/openldap/schema/core.schema<br />
include /etc/openldap/schema/cosine.schema<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/inetorgperson.schema<br />
include phamm.schema<br />
include ISPEnv2.schema<br />
include amavis.schema<br />
include pureftpd.schema<br />
<br />
<br />
создаем временный каталог <br />
'''mkdir ldif_out'''<br />
и теперь конвертируем схемы в ldif файлы<br />
'''slaptest -f schema.convert -F ldif_out'''<br />
config file testing succeeded<br />
<br />
Теперь изменяем конфиг ldif_out/cn=config/cn=schema/cn={4}phamm.ldif<br />
'''vi ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
чтобы получить следующее<br />
dn: cn=phamm,cn=schema,cn=config<br />
...<br />
cn: phamm<br />
и удаляем с конца ldif (дата и время могут оличатсья от приведенного нижк)<br />
structuralObjectClass: olcSchemaConfig<br />
entryUUID: 08bf1a06-7a89-102d-9fa6-4bee1e86d7f6<br />
creatorsName: cn=config<br />
createTimestamp: 20090119152440Z<br />
entryCSN: 20090119152440.275296Z#000000#000#000000<br />
modifiersName: cn=config<br />
modifyTimestamp: 20090119152440Z<br />
тоже самое делаем для файлов <br />
cn={5}ISPEnv2.ldif<br />
cn={6}amavis.ldif<br />
cn={7}pureftpd.ldif<br />
<br />
стартуем ldap <br />
'''service ldap start''' <br />
'''chkconfig ldap on'''<br />
[ldap-errors Ldap не стартанул]<br />
<br />
теперь загружаем схемы файлы в OpenLDAP (пароль используем тот который установили при установке ldap сервера)<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{5\}ISPEnv2.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{6\}amavis.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{7\}pureftpd.ldif'''</div>192.168.51.51https://wiki.welard.com/index.php?title=Mail_setting&diff=1407Mail setting2009-03-23T22:56:20Z<p>192.168.51.51: </p>
<hr />
<div>[http://www.postfix.org/ Postfix ] Virtual Hosting с [http://www.openldap.org/ OpenLDAP], [http://www.dovecot.org/ Dovecot] как IMAP/POP3,[http://www.onyxbits.de/gnarwl Gnarwl] как автоответчик и [http://www.phamm.org/ Phamm] как интерфейс управления<br />
<br />
[http://www.howtoforge.com/postfix-virtual-hosting-with-ldap-backend-and-with-dovecot-pop3-imap-on-ubuntu-8.10 оригинал статьи]<br />
<br />
* Сначала устанавливаем нужные пакеты <br />
'''yum install OpenLDAP'''<br />
конфиг его здесь /etc/openldap/ldap.conf<br />
<br />
'''yum install openldap-servers'''<br />
в этом есть нужные схемы <br />
и конфиг его здесь /etc/openldap/slapd.conf<br />
<br />
<br />
создаем каталог <br />
'''mkdir /root/work/phamm-inst'''<br />
качаем <br />
'''cd /root/work/phamm-inst'''<br />
'''wget http://open.rhx.it/phamm/phamm-0.5.15.tar.gz'''<br />
раскручиваем <br />
'''tar xvzf phamm-0.5.15.tar.gz'''<br />
<br />
вытягиваем из него схемы для удобства в свой каталог <br />
'''cp phamm-0.5.15/schema/phamm.schema /root/work/'''<br />
'''cd /root/work'''<br />
добавляем схемы <br />
<br />
'''wget http://open.rhx.it/phamm/schema/ISPEnv2.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/amavis.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/samba.schema'''<br />
'''wget http://open.rhx.it/phamm/schema/pureftpd.schema''' <br />
<br />
<br />
создаем файл '''schema.convert''' с содержимым<br />
<br />
include /etc/openldap/schema/core.schema<br />
include /etc/openldap/schema/cosine.schema<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/inetorgperson.schema<br />
include phamm.schema<br />
include ISPEnv2.schema<br />
include amavis.schema<br />
include pureftpd.schema<br />
<br />
<br />
создаем временный каталог <br />
'''mkdir ldif_out'''<br />
и теперь конвертируем схемы в ldif файлы<br />
'''slaptest -f schema.convert -F ldif_out'''<br />
config file testing succeeded<br />
<br />
Теперь изменяем конфиг ldif_out/cn=config/cn=schema/cn={4}phamm.ldif<br />
'''vi ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
чтобы получить следующее<br />
dn: cn=phamm,cn=schema,cn=config<br />
...<br />
cn: phamm<br />
и удаляем с конца ldif (дата и время могут оличатсья от приведенного нижк)<br />
structuralObjectClass: olcSchemaConfig<br />
entryUUID: 08bf1a06-7a89-102d-9fa6-4bee1e86d7f6<br />
creatorsName: cn=config<br />
createTimestamp: 20090119152440Z<br />
entryCSN: 20090119152440.275296Z#000000#000#000000<br />
modifiersName: cn=config<br />
modifyTimestamp: 20090119152440Z<br />
тоже самое делаем для файлов <br />
cn={5}ISPEnv2.ldif<br />
cn={6}amavis.ldif<br />
cn={7}pureftpd.ldif<br />
<br />
стартуем ldap <br />
'''service ldap start''' <br />
'''chkconfig ldap on'''<br />
<br />
теперь загружаем схемы файлы в OpenLDAP (пароль используем тот который установили при установке ldap сервера)<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{4\}phamm.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{5\}ISPEnv2.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{6\}amavis.ldif'''<br />
'''ldapadd -x -D cn=admin,cn=config -W -f ldif_out/cn\=config/cn\=schema/cn\=\{7\}pureftpd.ldif'''</div>192.168.51.51