Сегодня одна вещь заставила поломать голову.
Допустим, у нас есть сервер, на котором есть какой-то шелл-скрипт, который хотят выполнять вот так:
$ ssh user@host sudo ./test.sh
Скрипт, например, содержит строку вида
su -c 'nohup daemon &'
Для проверки концепции я применяю sleep 100, но это не имеет значения:
#!/bin/bash
set -x
su -c 'nohup sleep 100 2>&1 > /dev/null &' root
exit 0
Логично для обычного обывателя предположить, что при выполнении скрипта он запустит некоторую команду, отвяжет ее от терминала и выйдет. Если запустить его из обычного терминала. так и произойдет:
Показаны сообщения с ярлыком linux. Показать все сообщения
Показаны сообщения с ярлыком linux. Показать все сообщения
вторник, 1 сентября 2015 г.
воскресенье, 14 июля 2013 г.
Pulseaudio, twitch and broadcasting
Как-то ради интереса решил постримить то, как я играю в WoT на http://www.twitch.tv/skogut.
Первой проблемой было запилить, собственно, захват видео. Я нашел скриптик, и он, в общем-то работает. Но я немного его подправил под реалии wine + World Of Tanks и свои 4 ядра:
Основное изменение - это поиск окна WoT и определение его местоположения на экране.
С этим все ясно. Следующей проблемой было сделать так, чтобы можно было и говорить в микрофон и зрители стрима могли это слышать. После гугления был обнаружен хинт про module-loopback в pulse. Так я и сделал :)
Однако, с таким подходом, я слышу и себя, что делает для моего мозга ужасную обратную связь, которая мешает нормально говорить.
После вдумчивого чтения документации по модулям pulseaudio, меня осенило.
В pulse есть модуль null-sink, который ничего никуда не выводит. Так вот, достаточно его загрузить, выбрать как устройство, с которого будет идти запись в стрим (через pavucontrol, например).
Далее загружаем аж два module-loopback:
После чего в том же pavucontrol источником звука для этих (для этого надо включить отображение Virtual streams в Recording) мы выбираем 1) Monitor o НашаЗвуковаяПлата для захвата звука из приложения (в данном случае World Of Tanks и любые другие звуки), для второго loopback мы выбираем, собственно, саму звуковую плату (для захвата микрофона). И вуаля - мы слышим звук из игры, мы не слышим себя, зато зритель слышит всё!
Следующим шагом, видимо, будет запиливание автоматического выбора источников звука для loopback с помощью pactl, чтобы не нужно было ничего делать руками в pavucontrol, но я так спешил поделиться радостью, что пока не сделал этого.
#! /bin/bash
# originaly from http://tinyurl.com/twitch-linux from taladan
# www.youtube.com/user/taladan
# gist created by brodul
INRES=`xwininfo -name "WoT Client" | awk '/geometry/ {print $2}' | sed -e 's/\+.*//g'`
#INRES="1280x800" # input resolution
#OUTRES="1280x720" # Output resolution
OUTRES="640x380" # Output resolution
#OUTRES="$INRES" # Output resolution
FPS="18" # target FPS
QUAL="fast" # one of the many FFMPEG preset on (k)ubuntu found in /usr/share/ffmpeg
# If you have low bandwidth, put the qual preset on 'fast' (upload bandwidth)
# If you have medium bandwitch put it on normal to medium
CORNER=`xwininfo -name "WoT Client" | awk '/Corners/ {print $2}' | sed -re 's/\+(.*)\+(.*)/+\1,\2/'`
echo "INRES: $INRES CORNER: $CORNER"
# Write your key in a file named .twitch_key in your home directory
STREAM_KEY=$(cat ~/.twitch_key) # This is your streamkey generated by jtv/twitch found at: http://www.justin.tv/broadcast/adv_other
URL="rtmp://live-ams.twitch.tv/app/"
#BITRATE=2048000
BITRATE=1024000
nice taskset -c 1,2,3 avconv \
-f x11grab -s $INRES -r "$FPS" -i :0.0"$CORNER" \
-f alsa -ac 2 -i pulse \
-vcodec libx264 -s $OUTRES -preset $QUAL \
-acodec libmp3lame -ar 44100 -threads 3 -qscale 3 -b $BITRATE -bufsize 512k \
-f flv "${URL}${STREAM_KEY}"
Основное изменение - это поиск окна WoT и определение его местоположения на экране.
С этим все ясно. Следующей проблемой было сделать так, чтобы можно было и говорить в микрофон и зрители стрима могли это слышать. После гугления был обнаружен хинт про module-loopback в pulse. Так я и сделал :)
pactl load-module module-loopback latency_msec=1 sink=alsa_output.usb-Logitech_Logitech_G930_Headset-00-Headset.analog-stereo
Однако, с таким подходом, я слышу и себя, что делает для моего мозга ужасную обратную связь, которая мешает нормально говорить.
После вдумчивого чтения документации по модулям pulseaudio, меня осенило.
В pulse есть модуль null-sink, который ничего никуда не выводит. Так вот, достаточно его загрузить, выбрать как устройство, с которого будет идти запись в стрим (через pavucontrol, например).
Далее загружаем аж два module-loopback:
pactl load-module module-loopback latency_msec=1 sink=null
pactl load-module module-loopback latency_msec=1 sink=null
После чего в том же pavucontrol источником звука для этих (для этого надо включить отображение Virtual streams в Recording) мы выбираем 1) Monitor o НашаЗвуковаяПлата для захвата звука из приложения (в данном случае World Of Tanks и любые другие звуки), для второго loopback мы выбираем, собственно, саму звуковую плату (для захвата микрофона). И вуаля - мы слышим звук из игры, мы не слышим себя, зато зритель слышит всё!
Следующим шагом, видимо, будет запиливание автоматического выбора источников звука для loopback с помощью pactl, чтобы не нужно было ничего делать руками в pavucontrol, но я так спешил поделиться радостью, что пока не сделал этого.
воскресенье, 2 июня 2013 г.
Как же подгружать правила iptables через Network Manager?
Network Manager - пожалуй, самая ненавистная всеми вещь, которую я, несмотря на общественное мнение, с удовольствием использую.
Так вот, в ней есть замечательная вещь - в ответ на разные события, связанные с интерфейсами, он способен запускать скрипты, которые лежат в /etc/NetworkManage/dispatcher.d, и это можно использовать, в том числе, для подгрузки правил iptables. Самое главное, чтобы скрипт был 1) обычным файлом; 2) владельцем был root; 3) не был доступен на запись кому-то еще; 4) не был suid; 5) разрешен для исполнения владельцем (короче, права должны быть не более разрешающими, чем 755).
Все подробности о том, как этот скрипт исполняется и какие параметры получит, можно выгрести в man NetworkManager(8). Единственная печаль - он не получает никакого имени профиля настроек для интерфейса, а только его имя.
Но уже имея это, можно сунуть пару простых скриптов для настройки IPv4 или IPv6 фильтров (просто сменив iptables на ip6tables):
Так вот, в ней есть замечательная вещь - в ответ на разные события, связанные с интерфейсами, он способен запускать скрипты, которые лежат в /etc/NetworkManage/dispatcher.d, и это можно использовать, в том числе, для подгрузки правил iptables. Самое главное, чтобы скрипт был 1) обычным файлом; 2) владельцем был root; 3) не был доступен на запись кому-то еще; 4) не был suid; 5) разрешен для исполнения владельцем (короче, права должны быть не более разрешающими, чем 755).
Все подробности о том, как этот скрипт исполняется и какие параметры получит, можно выгрести в man NetworkManager(8). Единственная печаль - он не получает никакого имени профиля настроек для интерфейса, а только его имя.
Но уже имея это, можно сунуть пару простых скриптов для настройки IPv4 или IPv6 фильтров (просто сменив iptables на ip6tables):
1: if [ -x /usr/bin/logger ]; then
2: LOGGER="/usr/bin/logger -s -p daemon.info -t FirewallHandler"
3: else
4: LOGGER=echo
5: fi
6: case "$2" in
7: up)
8: if [ ! -r /etc/iptables.rules ]; then
9: ${LOGGER} "No iptables rules exist to restore."
10: return
11: fi
12: if [ ! -x /sbin/iptables-restore ]; then
13: ${LOGGER} "No program exists to restore iptables rules."
14: return
15: fi
16: ${LOGGER} "Restoring iptables rules"
17: /sbin/iptables-restore -c < /etc/iptables.rules
18: ;;
19: down)
20: if [ ! -x /sbin/iptables-save ]; then
21: ${LOGGER} "No program exists to save iptables rules."
22: return
23: fi
24: ${LOGGER} "Saving iptables rules."
25: /sbin/iptables-save -c > /etc/iptables.rules
26: ;;
27: *)
28: ;;
29: esac UFW - Ubuntu firewall - такая нужная вещь? :)
Была как-то давно мысль посмотреть на все эти фронтенды к iptables, написанные для "упрощения жизни". Да, возможно, не все могут понимать синтаксис правил iptables, всю его гибкость и мощь, так что им нужно пользоваться чем-то более простым. Итак, сейчас речь пойдет про ufw - Ubuntu-фронтенд к iptables.
Наверное, использовать именно его - самый простой способ "защититься". Включается он просто -
По-умолчанию он запрещает весь входящий траффик и разрешает исходящий:
Теперь посмотрим, что же стоит за всем этим...
На самом деле ufw создает примерно полтора десятка разных цепочек iptables, рассовывая по ним кучу разных правил, так что разобраться, что же сломалось после его применения будет в разы сложнее:
Что радует (или огорчает) - он по-умолчанию сразу разрешает DHCP запросы, так что хотя-бы DHCP-клиент у вас ломаться не должен. Одновременно с этим он разрешает и сервис avahi. Все остальное нужно разрешать самим. Кроме того, он настраивает логирование заблокированных пакетов, так что в dmesg или syslog они будут.
Как же после этого разрешать что-либо?
Просто разрешить ssh. Или только себе, скажем:
На этом моменте начинает казаться, что ufw писали фанатики синтаксиса ipfw. :)
Дальше - хуже. Удобства от ufw кончаются, как только вам нужно что-то более сложное, например, nat. Тут вам придется таки учить синтаксис iptables:
Такие вот дела, может кому-нибудь и нужен такой малофункциональный фронтенд к пакетному фильтру. У него есть одно достоинство - он загружает и сохраняет правила, что обычно является проблемой. А если кто не хочет и хочет что-то посложнее, в следующей заметке я расскажу, как ноутбучным и десктопным пользователям к NetworkManager прикрутить загрузку правил iptables.
Наверное, использовать именно его - самый простой способ "защититься". Включается он просто -
$ sudo ufw enable
По-умолчанию он запрещает весь входящий траффик и разрешает исходящий:
$ ufw status verbose Status: active Logging: on (low) Default: deny (incoming), allow (outgoing) New profiles: skip
Теперь посмотрим, что же стоит за всем этим...
На самом деле ufw создает примерно полтора десятка разных цепочек iptables, рассовывая по ним кучу разных правил, так что разобраться, что же сломалось после его применения будет в разы сложнее:
# iptables -L -v -n
Chain INPUT (policy DROP 2 packets, 64 bytes)
pkts bytes target prot opt in out source destination
344 31500 ufw-before-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
344 31500 ufw-before-input all -- * * 0.0.0.0/0 0.0.0.0/0
23 2608 ufw-after-input all -- * * 0.0.0.0/0 0.0.0.0/0
5 160 ufw-after-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
5 160 ufw-reject-input all -- * * 0.0.0.0/0 0.0.0.0/0
5 160 ufw-track-input all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ufw-before-logging-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-before-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-after-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-after-logging-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-reject-forward all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
254 23653 ufw-before-logging-output all -- * * 0.0.0.0/0 0.0.0.0/0
254 23653 ufw-before-output all -- * * 0.0.0.0/0 0.0.0.0/0
56 3591 ufw-after-output all -- * * 0.0.0.0/0 0.0.0.0/0
56 3591 ufw-after-logging-output all -- * * 0.0.0.0/0 0.0.0.0/0
56 3591 ufw-reject-output all -- * * 0.0.0.0/0 0.0.0.0/0
56 3591 ufw-track-output all -- * * 0.0.0.0/0 0.0.0.0/0
Что радует (или огорчает) - он по-умолчанию сразу разрешает DHCP запросы, так что хотя-бы DHCP-клиент у вас ломаться не должен. Одновременно с этим он разрешает и сервис avahi. Все остальное нужно разрешать самим. Кроме того, он настраивает логирование заблокированных пакетов, так что в dmesg или syslog они будут.
Как же после этого разрешать что-либо?
$ sudo ufw allow 22/tcp
Просто разрешить ssh. Или только себе, скажем:
$ ufw allow from 172.20.1.4 to any port 22 proto tcp
На этом моменте начинает казаться, что ufw писали фанатики синтаксиса ipfw. :)
Дальше - хуже. Удобства от ufw кончаются, как только вам нужно что-то более сложное, например, nat. Тут вам придется таки учить синтаксис iptables:
/etc/ufw/before.rules: *nat :POSTROUTING ACCEPT [0:0] -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE COMMIT
Такие вот дела, может кому-нибудь и нужен такой малофункциональный фронтенд к пакетному фильтру. У него есть одно достоинство - он загружает и сохраняет правила, что обычно является проблемой. А если кто не хочет и хочет что-то посложнее, в следующей заметке я расскажу, как ноутбучным и десктопным пользователям к NetworkManager прикрутить загрузку правил iptables.
четверг, 15 сентября 2011 г.
Мы с Linux уже 7 лет :)
Только что осознал, что 7 лет назад купил на горбушке два двд с довольно-таки устаревшим на тот момент срезом Debian Sid и снес винду. И с тех пор вот как-то постоянно с Linux в контакте нахожусь. Не скажу, что это сильно отразилось на профессионализме, гг, ну да, я их админю, поддерживаю, иногда ковыряюсь глубоко внутри, много опыта, но все равно не оставляет чувство, что в нем еще огромное количество белых пятен, касающихся его применения в быту и на производстве, так сказать. Это оказало потрясающее влияние, надо сказать. Например, мне очень не хочется сталкиваться с чем-то другим, особенно Windows, потому что привычно и удобно работать все-таки в *nix системах. Нравится сама идеология и философия.
Linux сильно изменился за эти годы. XFree86 ушел, пришел Xorg, научился делать и определять почти все сам, и почти всегда делает это правильно. Появились KDE4, Gnome3, Unity, которые до сих пор не вписываются в старые привычки, PulseAudio и NetworkManager. Долгое время была привычка отрицать наличие этого всего, но постепенно понимаешь, что это все-таки прикольно, юзабельно и удобно. Появился Ubuntu, который я тоже яростно отрицал, пока не попробовал, и вот уже Debian отошел на второй план, а в IRC я узнал про много других интересных дистрибутивов. И не могу сказать что какой-то лучше другого (ну, есть такие, которые я презираю в принципе, потому что не вижу им применения), все они хороши для определенного круга задач. Так что не холиворьте, у всех свои вкусы и пожелания. Все растут, понимают больше и, я уверен, у всех ощущение что "дистрибутивов должно быть много" будет иметь место, особенно если Linux это не только OS для десктопа.
Ну и за эти 7 лет я таки прихожу к мнению что Linux готов для дескопа. Не среднестатистического, но готов. И Windows для этого же самого не среднестатистического десктопа не готов совсем. :)
Linux сильно изменился за эти годы. XFree86 ушел, пришел Xorg, научился делать и определять почти все сам, и почти всегда делает это правильно. Появились KDE4, Gnome3, Unity, которые до сих пор не вписываются в старые привычки, PulseAudio и NetworkManager. Долгое время была привычка отрицать наличие этого всего, но постепенно понимаешь, что это все-таки прикольно, юзабельно и удобно. Появился Ubuntu, который я тоже яростно отрицал, пока не попробовал, и вот уже Debian отошел на второй план, а в IRC я узнал про много других интересных дистрибутивов. И не могу сказать что какой-то лучше другого (ну, есть такие, которые я презираю в принципе, потому что не вижу им применения), все они хороши для определенного круга задач. Так что не холиворьте, у всех свои вкусы и пожелания. Все растут, понимают больше и, я уверен, у всех ощущение что "дистрибутивов должно быть много" будет иметь место, особенно если Linux это не только OS для десктопа.
Ну и за эти 7 лет я таки прихожу к мнению что Linux готов для дескопа. Не среднестатистического, но готов. И Windows для этого же самого не среднестатистического десктопа не готов совсем. :)
суббота, 19 февраля 2011 г.
XPRA - "screen" для X-клиентов
xpra, или X Persistent Remote Applications - это приложение, которое позволит подключаться к запускаемым с его использованием X-клиентам (графическим программам) удаленно или локально, не опасаясь обрыва связи или смерти X-сервера. Эдакий “screen” для графических приложений, который и правда чем-то напоминает обычный screen для терминала.
Итак, как это работает?
Есть правда у него существенный недостаток - у меня в нем совсем не работает ввод кириллицы, да и некоторые приложения совсем плохо работают по сети через X-протокол (ну то есть, может они и хорошо работают, но для этого нужна гигабитная сеть %)). Ну и второе - такое как в tmux, а именно одновременное отображение и работа приложения на двух и более серверах, тут невозможно.
Итак, как это работает?
- Устанавливаем xpra. (свежие ебилды, репозитории со свежачком)
- Запускаем xpra на каком-либо свободном дисплее:
xpra start :1
xpra list - показывает активные дисплеи xpra - Запускаем наше приложение:
DISPLAY=:1 someguiapp
- Идем на удаленную машину... запускаем ssh с X-forwarding:
ssh -X username@hostname
- Делаем xpra attach:
xpra attach
- Видим свое приложение и работаем с ним.
Есть правда у него существенный недостаток - у меня в нем совсем не работает ввод кириллицы, да и некоторые приложения совсем плохо работают по сети через X-протокол (ну то есть, может они и хорошо работают, но для этого нужна гигабитная сеть %)). Ну и второе - такое как в tmux, а именно одновременное отображение и работа приложения на двух и более серверах, тут невозможно.
пятница, 18 февраля 2011 г.
Узнать время в другом часовом поясе
Кросспост с ЛинСовет
Иногда нам хочется узнать время в другом часовом поясе. Иногда (но еще реже) нам нужно, чтобы таймзона нашего пользователя была не такой, как системная. Для этого существует переменная окружения TZ, в которую можно записать значение и получить нужный эффект.
Иногда нам хочется узнать время в другом часовом поясе. Иногда (но еще реже) нам нужно, чтобы таймзона нашего пользователя была не такой, как системная. Для этого существует переменная окружения TZ, в которую можно записать значение и получить нужный эффект.
$ date Fri Feb 18 10:22:53 EET 2011 $ TZ="America/Chicago" date Fri Feb 18 02:22:53 CST 2011Узнать название зоны поточнее всегда можно в каталоге /usr/share/zoneinfo.
четверг, 23 сентября 2010 г.
Не смог не процитировать
Gentoo vs CentOS
"Gentoo - это дистрибутив, гибкость которого в данном случае на руку нам не играет. Дистрибутив должен быть каменным, предсказуемым, логичным. Как пинус. В этом плане Gentoo - как десятиметровый, но гибкий и извивающийся хуй. 10 метров - это, конечно, круто, но чтобы получить удовольствие - надо очень сильно постараться"
источник
"Gentoo - это дистрибутив, гибкость которого в данном случае на руку нам не играет. Дистрибутив должен быть каменным, предсказуемым, логичным. Как пинус. В этом плане Gentoo - как десятиметровый, но гибкий и извивающийся хуй. 10 метров - это, конечно, круто, но чтобы получить удовольствие - надо очень сильно постараться"
источник
воскресенье, 5 сентября 2010 г.
Как определять файловые системы в Linux?
В дополнение к старому методу
Без параметров она печатает информацию (включая UUID, который иногда тоже интересно знать) обо всех разделах всех накопителей:
Эта информация обычно уже закеширована в /etc/blkid.tab, так что если вдруг там чего нету, можно сделать низкоуровневую проверку устройства, вот так:
fdisk -l /dev/sdaи последующим попыткам монтировать каждую фс и т.д., есть более удобный способ - утилита blkid из util-linux.
Без параметров она печатает информацию (включая UUID, который иногда тоже интересно знать) обо всех разделах всех накопителей:
# blkid /dev/sda1: UUID="c4010837-0075-4175-8d5e-bca85f9aa29f" TYPE="ext4" /dev/sda2: UUID="bea54db9-fd2a-4afc-a893-e2aef25678de" TYPE="swap" /dev/sda3: UUID="a703af61-d160-4169-b012-d697ec990435" TYPE="ext4"
Эта информация обычно уже закеширована в /etc/blkid.tab, так что если вдруг там чего нету, можно сделать низкоуровневую проверку устройства, вот так:
# blkid -p /dev/sda1 /dev/sda1: UUID="c4010837-0075-4175-8d5e-bca85f9aa29f" VERSION="1.0" TYPE="ext4" USAGE="filesystem"
UPD: ЖЖ-юзер _zain также предлагает еще один вариант решения:
$ file -s /dev/sda1 /dev/sda1: Linux rev 1.0 ext4 filesystem data, UUID=c4010837-0075-4175-8d5e-bca85f9aa29f (needs journal recovery) (extents) (large files) (huge files)
вторник, 3 августа 2010 г.
Настройка клиента amanda для бекапа через ssh
В продолжение цикла статей про Amanda, привожу маленькое руководство для настройки клиента Amanda, который будет бекапиться сервером с помощью ssh и авторизоваться по ssh-ключам.
emerge --sync, eix-update
Многие начинающие пользователи Gentoo Linux уже знают про eix - утилиту для поиска ebuilds в portage. Они все как один запускают eix-update сразу послее установки, но забывают, что информацию в базе надо обновлять после каждого emerge --sync, ибо она автоматически не обновится.
Можно, конечно, делать эти операции по-отдельности, но eix приходит с утилитой eix-sync, которая выполнит и emerge --sync и eix-update автоматически.
Можно, конечно, делать эти операции по-отдельности, но eix приходит с утилитой eix-sync, которая выполнит и emerge --sync и eix-update автоматически.
Ограничения ssh через authorized_keys
Почти все знают, что с помощью ~/.ssh/authorized_keys можно разрешить пользователю с определенным RSA/DSA ключем логиниться через ssh. Но мало кто знает, что там же можно ограничить возможности ssh для пользователя. :)
если строчку с ключем, которая обычно выглядит так:
ssh-rsa многобукав user@hostname
поправить на
command="/bin/date" ssh-rsa многабукав ...
То при логине с этим ключем автоматически запустится /bin/date и произойдет logout из системы. Другую команду пользователь запустить не сможет (удобно, если ваш скрипт ходит зачем-то на этот хост - для ограничения его возможностей на всякий пожарный).
from="192.168.1.1" - ключ сработает, только если пользователь пришел с хоста 192.168.1.1, иначе спросит пароль. Умеет маски.
no-port-forwarding - запретит случайно использовать опцию -L для проброса портов.
permitopen="google.com:80" - ограничивает возможности ssh -L только форвардингом порта на google.com:80
Опции можно разделять запятыми:
from="backup.example.com",no-port-forwarding,no-X11-forwarding ssh-rsa AAAAA3Nza.... LiPK== user@backup.example.com
Подробности сего действа можно вычитать в man sshd, секция "AUTHORIZED_KEYS FILE FORMAT". Там есть еще пара опций.
если строчку с ключем, которая обычно выглядит так:
ssh-rsa многобукав user@hostname
поправить на
command="/bin/date" ssh-rsa многабукав ...
То при логине с этим ключем автоматически запустится /bin/date и произойдет logout из системы. Другую команду пользователь запустить не сможет (удобно, если ваш скрипт ходит зачем-то на этот хост - для ограничения его возможностей на всякий пожарный).
from="192.168.1.1" - ключ сработает, только если пользователь пришел с хоста 192.168.1.1, иначе спросит пароль. Умеет маски.
no-port-forwarding - запретит случайно использовать опцию -L для проброса портов.
permitopen="google.com:80" - ограничивает возможности ssh -L только форвардингом порта на google.com:80
Опции можно разделять запятыми:
from="backup.example.com",no-port-forwarding,no-X11-forwarding ssh-rsa AAAAA3Nza.... LiPK== user@backup.example.com
Подробности сего действа можно вычитать в man sshd, секция "AUTHORIZED_KEYS FILE FORMAT". Там есть еще пара опций.
воскресенье, 25 июля 2010 г.
Настройка простейшего сервера Amanda
Небольшой пример настройки сервера amanda, который будет бекапить сам себя. Но при желании, сможет бекапить что угодно.
Для Centos 5 я беру пакеты вот отсюда: Zmanda Downloads, потому что тут более-менее адекватно собранная последняя версия есть всегда.
Для Centos 5 я беру пакеты вот отсюда: Zmanda Downloads, потому что тут более-менее адекватно собранная последняя версия есть всегда.
OpenVPN для доступа в Internet
Иногда бывает, что нужно сделать так, чтобы пользователь, после подключения к VPN, смог бы использовать сервер как шлюз по-умолчанию, то есть выходил в интернет через него. Даже если у пользователя уже есть шлюз по-умолчанию. Проблема тут раньше возникала такая: как сделать так, чтобы после установки шлюза по-умолчанию, инкапсулированные в VPN пакеты могли достигнуть этого самого VPN-сервера? Конечно, если все пользователи находятся в известных условиях, можно было накручивать кучу скриптов, которые бы устанаваливали маршрут до VPN-сервера через старый шлюз по-умолчанию, но вот в OpenVPN появилась опция, которая позволяет автоматически настроить маршрутизацию как надо:
1. Прописать маршрут к VPN-серверу через текущий шлюз по-умолчанию.
2. Установить новый шлюз по-умолчанию через VPN-сервер
3. После окончания работы с VPN вернуть все назад.
1. Прописать маршрут к VPN-серверу через текущий шлюз по-умолчанию.
2. Установить новый шлюз по-умолчанию через VPN-сервер
3. После окончания работы с VPN вернуть все назад.
вторник, 20 июля 2010 г.
Настройка многопользовательского сервера OpenVPN
Давеча меня тут попросили настроить один. Да еще так чтобы клиентов было много и авторизовались они по пользователю/паролю.
Устанавливать мы его будем на Centos 5.5, потому что это очень популярная система для серверов. Она перебьет по популярности на серверах что угодно, потому что это собранная из исходных кодов RHEL 5 свободная система, полностью совместимая с ним бинарно, и она стабильна, как ископаемые экскременты мамонтов. Поэтому даже openvpn в ее стандартных репозиториях нет. Поэтому вам нужно подключить себе EPEL или RPMForge.
Устанавливать мы его будем на Centos 5.5, потому что это очень популярная система для серверов. Она перебьет по популярности на серверах что угодно, потому что это собранная из исходных кодов RHEL 5 свободная система, полностью совместимая с ним бинарно, и она стабильна, как ископаемые экскременты мамонтов. Поэтому даже openvpn в ее стандартных репозиториях нет. Поэтому вам нужно подключить себе EPEL или RPMForge.
вторник, 13 июля 2010 г.
Фишки bash, которые помогут иногда не пользоваться sed
Аналог echo $VAR | sed -e 's/.txt$/.htm/' - если нужно сменить расширение файла, например
stasikos@pip-boy4000:~$ VAR=something.txt
stasikos@pip-boy4000:~$ echo ${VAR/.txt/.htm}
something.htm
Или совсем убрать
stasikos@pip-boy4000:~$ echo ${VAR%.txt}
something
Поменять регистр символов
stasikos@pip-boy4000:~$ echo ${VAR^^}
SOMETHING.TXT
stasikos@pip-boy4000:~$ VAR=SoMeThInG.txt
stasikos@pip-boy4000:~$ echo ${VAR,,}
something.txt
Теперь немножко про удобную замену такой вещи как
if [ -z "$VAR" ] ; then ...
fi
stasikos@pip-boy4000:~$ VAR=some
stasikos@pip-boy4000:~$ echo ${VAR:-default_value}
some
stasikos@pip-boy4000:~$ VAR=''
stasikos@pip-boy4000:~$ echo ${VAR:-default_value}
default_value
Это можно использовать при чтении, скажем, конфигурационного файла для скрипта, или для определения дефолтных значений при отсутствии значений переменных окружения
Или выкинуть ошибку если значение переменной не установлено:
stasikos@pip-boy4000:~$ echo ${VAR:?was not configured}
bash: VAR: was not configured
Больше интересного чтива можно найти в man bash по словам "Parameter Expansion"
stasikos@pip-boy4000:~$ VAR=something.txt
stasikos@pip-boy4000:~$ echo ${VAR/.txt/.htm}
something.htm
Или совсем убрать
stasikos@pip-boy4000:~$ echo ${VAR%.txt}
something
Поменять регистр символов
stasikos@pip-boy4000:~$ echo ${VAR^^}
SOMETHING.TXT
stasikos@pip-boy4000:~$ VAR=SoMeThInG.txt
stasikos@pip-boy4000:~$ echo ${VAR,,}
something.txt
Теперь немножко про удобную замену такой вещи как
if [ -z "$VAR" ] ; then ...
fi
stasikos@pip-boy4000:~$ VAR=some
stasikos@pip-boy4000:~$ echo ${VAR:-default_value}
some
stasikos@pip-boy4000:~$ VAR=''
stasikos@pip-boy4000:~$ echo ${VAR:-default_value}
default_value
Это можно использовать при чтении, скажем, конфигурационного файла для скрипта, или для определения дефолтных значений при отсутствии значений переменных окружения
Или выкинуть ошибку если значение переменной не установлено:
stasikos@pip-boy4000:~$ echo ${VAR:?was not configured}
bash: VAR: was not configured
Больше интересного чтива можно найти в man bash по словам "Parameter Expansion"
вторник, 22 июня 2010 г.
Сюрпризы iptables, или как не стоит делать DNAT
iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to-destination 192.168.0.20:80 это плохая команда
И вот почему :)
Допустим, у вас есть некий маршрутизатор с Linux, который имеет 4 интерфейса:
eth0 - 11.1.1.1/30 - который используется для связи с провайдером
eth1 - 12.1.1.1/28 - ваш сабнет с DMZ, куда все пакеты просто маршрутизируются с опциональной фильтрацией на этом же маршрутизаторе
eth2.100 - 192.168.0.1/24 - подсеть, для которой настроен SNAT на интерфейс eth0 (кстати, тут тоже надо настраивать этот самый SNAT правильно) и в которой находятся еще сервера, порты для которых пробрасываются с целью экономии публичных адресов из 12.1.1.0/28
eth2.200 - 192.168.1.1/24 - такая же подсеть, но для обычных компьютеров, и для которой тоже настроен SNAT на eth0.
Итак, что же будет, если мы решим пробросить порт 80 с 11.1.1.1 на 192.168.0.20:80, той командой, которая написана в начале поста? Будет полная фигня, потому что любой пакет с dst-port 80, пришедший из инетрнета будет перенаправлен на 192.168.0.20:80, а не на, возможно, существующие в 12.1.1.0/28 веб-сервера. Так что команду лучше писать примерно так:
iptables -t nat -A PREROUTING -d 11.1.1.1.1 -p tcp --dport 80 -i eth0 -j DNAT --to-destination 192.168.0.20:80
попутно выработав привычку делать так всегда, дабы не обременять себя и других унылым траблшутингом.
Точно так же следует поступать и с SNAT:
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/23 -j SNAT --to-source 11.1.1.1
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0.0/23 -j SNAT --to-source 12.1.1.1
дабы хороший траффик с публичными адресами из 12.1.1.0/28 вдруг не стал натиться в 11.1.1.1
И вот почему :)
Допустим, у вас есть некий маршрутизатор с Linux, который имеет 4 интерфейса:
eth0 - 11.1.1.1/30 - который используется для связи с провайдером
eth1 - 12.1.1.1/28 - ваш сабнет с DMZ, куда все пакеты просто маршрутизируются с опциональной фильтрацией на этом же маршрутизаторе
eth2.100 - 192.168.0.1/24 - подсеть, для которой настроен SNAT на интерфейс eth0 (кстати, тут тоже надо настраивать этот самый SNAT правильно) и в которой находятся еще сервера, порты для которых пробрасываются с целью экономии публичных адресов из 12.1.1.0/28
eth2.200 - 192.168.1.1/24 - такая же подсеть, но для обычных компьютеров, и для которой тоже настроен SNAT на eth0.
Итак, что же будет, если мы решим пробросить порт 80 с 11.1.1.1 на 192.168.0.20:80, той командой, которая написана в начале поста? Будет полная фигня, потому что любой пакет с dst-port 80, пришедший из инетрнета будет перенаправлен на 192.168.0.20:80, а не на, возможно, существующие в 12.1.1.0/28 веб-сервера. Так что команду лучше писать примерно так:
iptables -t nat -A PREROUTING -d 11.1.1.1.1 -p tcp --dport 80 -i eth0 -j DNAT --to-destination 192.168.0.20:80
попутно выработав привычку делать так всегда, дабы не обременять себя и других унылым траблшутингом.
Точно так же следует поступать и с SNAT:
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/23 -j SNAT --to-source 11.1.1.1
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0.0/23 -j SNAT --to-source 12.1.1.1
дабы хороший траффик с публичными адресами из 12.1.1.0/28 вдруг не стал натиться в 11.1.1.1
Advanced Maryland Automatic Network Disk Archiver!
В годы молодости, когда опыт работы с Linux был маленьким, все равно хотелось
делать бекапы. Тогда и были найдены такие вещи как Amanda и Bacula, но новичку
было не так просто разобраться с ними и я пользовался маленьким и простым
backup-manager. Вот уже прошли годы и я умею и Bacula и Amanda, и хотелось бы
рассказать совсем чуть-чуть про то что начинается с А.
Amanda напоминает штуковину, которую многие бы написали самостоятельно. Но в то
же время она несколько своеобразна.
делать бекапы. Тогда и были найдены такие вещи как Amanda и Bacula, но новичку
было не так просто разобраться с ними и я пользовался маленьким и простым
backup-manager. Вот уже прошли годы и я умею и Bacula и Amanda, и хотелось бы
рассказать совсем чуть-чуть про то что начинается с А.
Amanda напоминает штуковину, которую многие бы написали самостоятельно. Но в то
же время она несколько своеобразна.
четверг, 9 июля 2009 г.
Tripwire и prelink
В эти моменты я думал что все очень плохо...
Все началось с того что ради тестов поставил tripwire на один сервер, настроил, сгенерировал базу, настроил проверку по крону...
И на следующее утро получил письмо от tripwire с информацией о том что исполняемые файлы tripwire изменили свой размер, контрольную сумму, дату изменения и даже номер inode.
rpm -V показал только что изменились конфигурационные файлы (это я)
Это как-то немного успокоило, но не надолго.
Потом были вопросы к секурити-спецу, попытки понять как это могло случиться и т.д.
Кончилось тем что был скачан rpm с tripwire, распакован и были сверены контрольные суммы файлов пакета с файлами, которые установлены. Они отличались.
Далее был гугл, который намекнул на то что кое-где встречается prelink...
он был натравлен на свежевынутые из rpm файлы, и, о чудо! Контрольные суммы установленных файлов и обработанных prelink - одинаковые.
Почему ничего не изменялось пока шифровалась/инициализировалась политика, проводились проверки/тесты - не понятно, но утро было достаточно забавным.
Все началось с того что ради тестов поставил tripwire на один сервер, настроил, сгенерировал базу, настроил проверку по крону...
И на следующее утро получил письмо от tripwire с информацией о том что исполняемые файлы tripwire изменили свой размер, контрольную сумму, дату изменения и даже номер inode.
rpm -V показал только что изменились конфигурационные файлы (это я)
Это как-то немного успокоило, но не надолго.
Потом были вопросы к секурити-спецу, попытки понять как это могло случиться и т.д.
Кончилось тем что был скачан rpm с tripwire, распакован и были сверены контрольные суммы файлов пакета с файлами, которые установлены. Они отличались.
Далее был гугл, который намекнул на то что кое-где встречается prelink...
он был натравлен на свежевынутые из rpm файлы, и, о чудо! Контрольные суммы установленных файлов и обработанных prelink - одинаковые.
Почему ничего не изменялось пока шифровалась/инициализировалась политика, проводились проверки/тесты - не понятно, но утро было достаточно забавным.
воскресенье, 5 июля 2009 г.
Красная шляпка и IPSec
Когда все просто - транспортный режим и нужно только зашифровать весь траффик от хоста А до хоста Б все понятно - делаем ifcfg-ipsec0 с содержимым вида
ну и потом ifup ipsec0. Но вот захотелось посмотреть, как же можно прикрутить более сложную политику, скажем, требовать шифрования или аутентификации только для пакетов на определенный порт и тут магия вдруг неожиданно исчезла... (пробовал A.A.A.A:AA или A.A.A.A[AA]). Ковыряние в ifup-ipsec не помогло совершенно.
Неужели дальше все делается только руками?
ONBOOT=yes
TYPE=ipsec
DST=A.A.A.A
IKE_METHOD=PSK
ну и потом ifup ipsec0. Но вот захотелось посмотреть, как же можно прикрутить более сложную политику, скажем, требовать шифрования или аутентификации только для пакетов на определенный порт и тут магия вдруг неожиданно исчезла... (пробовал A.A.A.A:AA или A.A.A.A[AA]). Ковыряние в ifup-ipsec не помогло совершенно.
Неужели дальше все делается только руками?
Подписаться на:
Сообщения (Atom)