November 25th, 2013

404

Концептуальная проблема с пакетами в системе (devops)

Выписываю свои первые мысли по вопросу. У меня нет ещё готовой точки зрения и я хочу просто пока что сформулировать проблему и аргументы с каждой из точек зрения.

Вопрос простой: как должен свой софт появляться на серверах? Понятно, что репозитории, бранчи и так далее. Но ключевой вопрос, который, в радикально-религиозном формате звучит так: слакваря или пакеты?

Другими словами, make install или dpkg -i (yum localinstall, не важно)?

Сначала изложу формально религиозную позицию (которой я долгое время придерживался, и от которой мне не хочется отходить даже под давлением реальности).

Правильный метод установки ПО - посредством пакетов (для дальнейшего удобства я буду идти по debian-way). Другими словами, софт, поставленный без участия dpkg, это превращение системы в Слакварю, в адское смешение неявных зависимостей, невозможность спокойного обновления.

Для того, чтобы обновление проходило штатными методами, пакеты должны быть выложены на свой собственный миррор.

Для того, чтобы пакет полностью соответствовал требованиям, он должен содержать changelog.

Если пакет обязательно зависит от какой-то библиотеки, то она должна быть запакетирована ровно таким же образом.

Если все всё будут всегда пакетировать, то в мире наступит мир, покой и счастье.

Это такая ясная простая позиция системного администратора, который вволю нахлебался всяких там кривоустановщиков вида ./NVIDIA*, ./LSI* и т.д., помноженная на отлов глюков разных версий явы для разных проприентарных поделок.

Однако, есть и противоположная позиция - позиция разработчика. У него - миллион и одна зависимость. Он использует кучу библиотек из pypy, rubygems, epel, hackage, opam и т.д. На сервере могут одновременно работать программы, которым нужна одна и та же библиотека, но с разными версиями. Например, одному нужна libfoo [>1.5, <2], другому libfoo [>2].

Более того, сами библиотеки так же могут начинать зависеть от конфликтного множества.

Таким образом, разрабочик хочет иметь себе комфортную систему управления зависимостями - pip, bunder, cabal, etc.

Казалось бы, ситуация ясная: системные пакеты - это системные пакеты, а свой софт собирает зависимости с помощью своего управлятора зависимостями.

Это так, ровно до того момента, пока очередной библиотеке не оказывается необходимо жить в присутствии системной библиотеки. Особенно, в районе -dev, которой по совести нужно иметь соответствующую ей не-dev версию.

И вот тут приходит некая непонятная мне конструкция, решения которой я не вижу.

Как подружить эти миры?

Злой голосок с соседнего стола нашёптывает, что если всё разворачивать одинаковыми рецептами шефа, то всё будет работать или не работать одинаково.

Но выход ли это? А, главное, у меня есть ощущение, что я не выписал проблему целиком.
404

Everyone spyes on you

even firefox.

В связи с говносвязью через dns-туннели, начал пристально созерцать wireshark в реальном времени. Обнаружил, что firefox ходит на левые адреса с вопросом "safebrowsing сюда?". Отключается в about:config browser.safebrowsing.enabled в false.

Минус одна tcp-сессия на каждый сайт. В моих условиях это важно.
404

list vms under kvm

Казалось бы, тривиальная задача. Однако, я не нашёл красивого решения. Задача "список виртуалок" в отрыве от любых систем управления гипервизорами, то есть "правда-матка". Для xen'а это был list_domains и xc.domain_getinfo().

Ближайшее, что я нашёл - это ps axu|grep qemu.

Вывод примерно такой:

105 11787 5.2 0.3 5362636 118088 ? Sl Nov21 290:28 qemu-system-x86_64 -machine accel=kvm:tcg -name instance-0000002d -S -machine pc-i440fx-1.5,accel=kvm,usb=off -cpu Nehalem,+rdtscp,+pdpe1gb,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 512 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 5747cfe8-668d-4590-a1cc-b590466dab86 -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2013.2,serial=02050d04-0904-0205-0000-000000000000,uuid=5747cfe8-668d-4590-a1cc-b590466dab86 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0000002d.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/5747cfe8-668d-4590-a1cc-b590466dab86/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=24,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:6d:21:ff,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/5747cfe8-668d-4590-a1cc-b590466dab86/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

Жирное - uuid, который видно в nova. Как получить информацию напрямую от гипервизора я пока не нашёл.
404

о пыхах


настоящей вспышкой является такая, которая после срабатывания после нескольких месяцев простоя оставляет после себя легкий запах горелой пыли с защитного экрана.

Запись сделана с помощью приложения LiveJournal для Android.