Записки linux админа

Если вдруг стало неуютно с кедами. Взято отсюда  http://www.psychocats.net/ubuntu/pureubuntu  и отредактировано после выставления в apt.conf Debug::pkgProblemResolver "true"; Что бы не удаляло wine, abiword, gnupg и gstreamer. # apt-get remove akonadi-facebook akregator amarok amarok-common amarok-utils apport-kde apturl-kde ark audiocd-kio bluedevil calligra-data calligra-libs colord-kde cryptsetup dolphin dragonplayer freespacenotifier  gstreamer0.10-qapt gtk2-engines-oxygen gtk3-engines-oxygen gwenview ibus-qt4 kaccessible kaddressbook kamera kamoso kate kcalc kde-base-artwork kde-baseapps-bin kde-baseapps-data kde-config-gtk-style kde-config-tablet kde-config-telepathy-accounts kde-config-touchpad kde-style-oxygen kde-telepathy kde-telepathy-approver kde-telepathy-auth-handler kde-telepathy-contact-list kde-telepathy-data kde-telepathy-filetransfer-handler kde-telepathy-integration-module kde-telepathy-minimal kde-telepathy-send-file kde-telepathy-text-ui kde-wal...

У меня дома, если отваливается nfs/smb шара, то перестают работать хоткеи в Mate. После долгих поисков, удалось найти такой баг: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563592 И аналогичное решение для Mate: $ mateconf-editor выключаем /apps/gnome_settings_daemon/plugins/housekeeping/active Перезапускаем mate и всё хорошо.

На одном сервере появились вот такие вот подарки: error.log [Mon Apr 29 20:17:54 2013] [error] [client 50.63.136.60] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.test0:) acess.log 50.63.136.60 - - [29/Apr/2013:20:17:54 +0200] "GET /w00tw00t.at.ISC.SANS.test0:) HTTP/1.1" 400 523 "-" "-" Считаем # grep "w00tw00t.at.ISC.SANS" /var/log/apache2/access.log | awk '{ print $1}' | sort | uniq -c       1 42.121.99.77      85 50.63.136.60       3 81.161.248.17       1 87.98.227.69       3 94.23.26.88 Это привет от DFind Scanner и кулцацкеров. Ну, Fail2ban нам поможет. У меня UFW, так что action.d/ufw-all.conf [Definition] actionstart = actionstop = actioncheck = actionban = ufw insert 1 deny from actionunban = ufw delete deny from И сам банхаммер: jail.conf [apache-w00tw00t] enabled  = true port     = http,htt...

Я так долго ждал новой версии! В репах нет, но видна новая версия в PPA # add-apt-repository ppa:deluge-team/ppa # apt-get update Однако PPA меня огорчил # apt-cache show deluge-gtk Package: deluge-gtk Source: deluge Version: 1.3.5-1ubuntu4 Но тут  http://ppa.launchpad.net/deluge-team/ppa/ubuntu/pool/main/d/deluge/  есть сорсы root@antix-pc:/etc/apt# apt-cache showsrc deluge-gtk Package: deluge Binary: deluge-common, deluged, deluge-console, deluge-web, deluge-gtk, deluge, deluge-webui, deluge-torrent Version: 1.3.6-0~quantal~ppa1 Так что, чего ждать $ mkdir deluge136 $ cd deluge136 $ sudo apt-get build-dep deluge $ apt-get source deluge $ cd deluge-1.3.6/ $ debuild -us -uc -i -I $ cd .. $ sudo dpkg -i *.deb Трям. P.S. и похоже, что оно даже не виснет, в отличии от версии 1.3.5 из репозитория ;-)

Обновлял вики с версии 1,16 до 1,20,2 Сначала читаем  Upgrading Guide Потом страдаем: 1) как минимум юзеру надо права на дроп таблиц 2) будут плагины, которые просто морально устарели и не заработают смотреть ерор лог апача 3) много плагинов придётся кропотливо обновлять и читать INSTALL/README (не, серёзно) например tar cjvf Variables.tar.bz2 Variables rm -fr Variables wget --content-disposition 'https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Variables.git;a=snapshot;h=refs/heads/master;sf=tgz' tar xvf Variables-master-8a5e73f.tar.gz mv Variables-master-8a5e73f Variables 4) семантик вики надо обновлять в первую очередь, от неё зависят много других плагинов (у меня, по крайней мере) 5) лучше по отключать эти плагины, пока не обновишь семантик вики

Иногда бывает так: root@server:/var/www/wiki/extensions# wget 'https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Variables.git;a=snapshot;h=refs/heads/master;sf=tgz' ... 2013-02-19 03:25:02 (18.2 MB/s) - `gitweb?p=mediawiki%2Fextensions%2FVariables.git;a=snapshot;h=refs%2Fheads%2Fmaster;sf=tgz' saved [10239/10239] FAIL И тогда, мы делает так: root@server:/var/www/wiki/extensions# wget --content-disposition 'https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Variables.git;a=snapshot;h=refs/heads/master;sf=tgz' ... 2013-02-19 03:27:10 (16.0 MB/s) - `Variables-master-8a5e73f.tar.gz' saved [10239/10239] WIN!!!

быстрый вариант # mysqladmin flush-hosts -ppassword медленный # vim /etc/mysql/my.cnf set-variable = max_connect_errors=500

После неудачного опыта использования zfs on linux, решили временно вернуться к чему-то более стабильному, но довольно быстрому. Мой выбор пал на raid10 + ext4 с отключённым журналом. Создавать можно и по дефолту, но есть рекомендации по подбору параметров для создания ФС -  https://raid.wiki.kernel.org/index.php/RAID_setup#ext2.2C_ext3.2C_and_ext4 А ещё есть полезный калькулятор -  http://busybox.net/~aldot/mkfs_stride.html Пример для RAID10 # mdadm --create --verbose /dev/md0 --level=10  --raid-devices=4 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 # mkfs.ext4 -b 4096 -E stride=128,stripe-width=256 -L RAID10 /dev/md0 Далее надо отключить журнал и подобрать параметры монтирования. # tune2fs -o journal_data_writeback /dev/md0 # tune2fs -O ^has_journal /dev/md0 # e2fsck -f /dev/md0 # dumpe2fs /dev/md0 | more # vim /etc/fstab /dev/md0 /opt ext4 defaults,data=writeback,noatime,nodiratime 0 0

Предположим, после авто деплоймента по шаблонному preseed файлу, надо добавить в RAID дополнительные диски: Дополнительные винты разбиваем как основные (например добавляем sdc): если MBR: sfdisk -d /dev/sda | sfdisk /dev/sdc если GPT: sgdisk -R=/dev/sdc /dev/sda sgdisk -G /dev/sdc и добавляем их в массив # partprobe # mkswap /dev/sdc2 # mkswap /dev/sdd2 # sgdisk -t 3:fd00 /dev/sdd # sgdisk -t 3:fd00 /dev/sdc # mdadm /dev/md0 -a /dev/sdc3 # mdadm /dev/md0 -a /dev/sdd3 # mdadm -G /dev/md0 --raid-devices=4 Это актуально для RAID с чередованием (например - raid5). Если массив уже создан как RAID1, а дисков больше чем 2, то лучший вариант сварить RAID10: # mdadm --zero-superblock /dev/sda4 # mdadm --zero-superblock /dev/sdb4 # mdadm --zero-superblock /dev/sdc4 # mdadm --zero-superblock /dev/sdd4 # dd if=/dev/zero of=/dev/sda4 bs=512 count=100 # dd if=/dev/zero of=/dev/sdb4 bs=512 count=100 # dd if=/dev/zero of=/dev/sdc4 bs=512 count=100 # dd if=/dev/zero of=/dev/sdd...

Всё в принципе просто, хотя тырнет информацией не блещет $ cat /etc/apt/apt.conf.d/99proxy Acquire::http {   Proxy "http://10.10.10.1:3128/";   Proxy::ppa.launchpad.net "DIRECT"; } Все репозитории, кроме тех, для которых прописано "DIRECT" - будут идти через прокси.

После перехода одного клиента с RHEL6 на репозитоий от Scientific Linux 6 стали приходить нотификации от nagios - check_mount.pl отказывался видеть примонтированную шару, хотя она была и # /usr/lib64/nagios/plugins/check_mount.pl -m /someshare /someshare is mounted! рапотровал что всё ok. Однако  # /usr/lib64/nagios/plugins/check_nrpe -H localhost -c check_mount /someshare is not mounted! валился. Стал разбираться и нашёл причину - SELinux (ну кто бы сомневался). Игры с restorecon не помогли. Возможно ребут с Relabeling помог бы ( http://www.centos.org/docs/5/html/5.2/Deployment_Guide/sec-sel-fsrelabel.html ), но перезагружать сервак не хотелось, да и просто fixfiles делать тоже не улыбалось. Из несотыковок со старым сервером (там где ещё был чистый RHEL6) было [root@new ~]# ps auxZ | grep nrpe|grep -v grep unconfined_u:system_r:nrpe_t:s0 nrpe     23079  0.0  0.0  40944  1312 ?       ...

Стандартная процедура, которая обычно не вызывает никаких проблем. Однако иногда попадаются "интересные" таблицы разделов, из-за который приходится подумать. Есть proxmox, а на нём виртуалка. # qemu-img info vm-100-disk-1.qcow2 # qemu-img resize vm-100-disk-1.qcow2 +50G # qm start 100 Заходим на виртуалку и видим # fdisk -l /dev/vda Disk /dev/vda: 182.5 GB, 182536110080 bytes 16 heads, 63 sectors/track, 353686 cylinders, total 356515840 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000df459    Device Boot      Start         End      Blocks   Id  System /dev/vda1   *        2048      499711      248832   83  Linux /dev/vda2          501758   251656191   125577217   ...