Free Runner

Намедни перебрались в новый офис, после подключения и настройки роутера обнаружилась неведомая фигня: открывались только Google, Yandex и пара-тройка других сайтов, а при попытке открыть остальные — сброс по таймауту. Техподдержка и звонок другу не помогли, все пожимали плечами. Вооружившись ping и traceroute выяснил, что сайты на самом деле доступны, вот только фиг открываются. С горем пополам, на Google ВиО, который открывался, как и сам сайт Google, напал на след проблемы, реально онлайн рулетка, попадется не попадется . Как оказалось, на всех машинках значение MTU выставлялось автоматически (хотя в настройках роутера было указано явно — 1450). На линуксовых машинах это решалось в пару кликов — в настройках сетевого адаптера через NetworkManager, в оффтопике — несколько сложнее:

#просматриваем список интерфейсов
netsh interface ipv4 show subinterfaces
#настраиваем нужный
netsh interface ipv4 set subinterface "Беспроводное сетевое соединение" mtu=1450 store=persistent
#отключаем автоматическую установку MTU
netsh int tcp set global autotuninglevel=disabled

После этого идем в редактор реестра по адресу:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\

Среди вложенных директорий находим ту, которая содержит ip нашей машины, полученный от роутера, и добавляем новый DWORD (32 bit) параметр, с названием MTU, после чего выставьте его значение в десятичном формате — 1450. Опосля перезагрузитесь, и вуаля.

Вот такая компьютерная помощь на дому

Почему извращаемся с Windows?

Давайте представим себе некоторую абстрактную ситуацию, в которой заядлому линуксоиду приходится, в следствие должностных обязанностей, плотно засесть под Windows. При этом, часть его работы подразумевает ряд операций, которые, если не Linux-only, то в нем, родимом, выполняются куда как сподручнее.

При этом, основную часть времени ему все таки придется проводить в Windows, так что dual-boot в такой ситуации не есть оптимальный вариант. Таки на ум приходит следующее решение (как сказал один знакомый программер: «coLinux своими руками, млин»)

Исходные данные

Итак, дано:

• Windows Vista/7 в качестве хост-системы
• Ваш любимый дистрибутив в качестве гостевой системы
• VirtualBox, потому что с VMWare издавна как-то не сложилось

Поехали

• Для начала, естественно, скачаем и установим VirtualBox.
• После чего установим Putty.
• При создании виртуальной машины выбираем удобные для себя настройки, за исключением одно маленького но, для гостевой системы сразу определяем 2 сетевых интерфейса:
  • NAT, из-за него наш Linux будет выходить во внешний мир
  • Виртуальный адаптер хоста, через него мы будем стучаться по ssh к нашему гостевому Linux
• Уже непосредственно во время установки системы, или сразу после этого, настраиваем сетевые интерфейсы:
  • Пусть eth0 — первый, который NAT, ему говорим все получать автоматически по DHCP
  • Пусть eth1 — второй, который виртуальный адаптер хоста, говорим ему, что у него ip 192.168.56.10, маска 255.255.255.0
• Систему установили, сетевые интерфейсы настроили (то есть убедились, что при загрузке гостевой системы у первого сетевого интерфейса ip вида 10.0.2.15, у второго тот, что указан ранее).
• Пишем bat’ники, которые позволят запускать виртуалку в режиме Headless, то бишь без запуска GUI VirtualBox’а:

  • cd "C:\Program Files\Oracle\VirtualBox\"
    start VBoxManage startvm YOURVM --headless
    

  • cd "C:\Program Files\Oracle\VirtualBox\"
    start VBoxManage controlvm YOURVM --poweroff
    

• Собственно все, запускаем машинку в режиме headless, стучимся к ней с помощью Putty, работаем.

Intro

Использовать системы контроля версий в таких задачах как разработка ПО или создание сайтов нынче хороший тон. Так уж сложилось, что в момент выбора куда смигрировать с SVN я решил использовать Mercurial, на тот момент мне эта система показалась немного более простой и удобной, нежели Git. С увеличением количества разработчиков в проекте, ну или просто, если хочется, что бы в репозитории был порядок, неизбежно все приходят к использованию веток. Даже в небольших проектах у меня всегда 2 ветки: default и devel, остальные возникают и исчезают по необходимости. В default, всегда находится стабильный, оттестированый код (хотя чего греха таить, баги тут тоже обитают), devel — общая для всех ветвь разрабатываемого кода, от которой, в процессе, могут создаваться дополнительные ветки для реализации новых фич. Вообще механизм веток в Mercurial не столь прозрачен, на мой взгляд, как в Git, там, как раз таки, данный механизм реализован более удачно. Мне привычнее использовать named branches.

Создание ветки

hg branch test
hg ci -m "new branch for testing code"
hg push --new-branch

Слияния веток

hg up default
hg merge test
hg ci -m "merge with test branch"
hg push

Закрытие ветки

hg up test
hg ci -m "close test branch" --close-branch
hg push

Вот так, довольно просто, можно использовать ветки в Mercurial. Это далеко не единственный вариант, например есть еще перемещаемые маркеры, они же bookmarks.

После установки модуля mod_suexec в Slackware 13.37 выскочило вот такое предупреждение: «Warning: SuexecUserGroup directive requires SUEXEC wrapper». Лечится довольно просто.

Во-первых, все зависит от способа установки, я устанавливал в лоб, скачал rpm-пакет c rpm.pbone.net, который соответствовал моей платформе и версии апача (i686, apache-2.2.19), выдернул из cpio архива 2 файла: mod_suexec.so, который копируется в /usr/lib/httpd/modules и suexec, который копируется в /usr/sbin. Если вы устанавливали таким способом, то нужно проверить, где апач будет искать suexec:

httpd -V | grep SUEXEC_BIN

Если в выводе увидите -D SUEXEC_BIN=»/usr/sbin/suexec», то все ок, а если -D SUEXEC_BIN=»/usr/bin/suexec», то нужно сделать линк:

ln -s /usr/sbin/suexec /usr/bin/suexec

После этого, нужно подправить права, если это необходимо:

chown root:root /usr/sbin/suexec
chmod 4750 /usr/sbin/suexec

Рестартуем апач и можем спокойно использовать директиву SuexecUserGroup