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

Всё в принципе просто, хотя тырнет информацией не блещет $ 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   ...