Дабы не плодить процессы в кроне.
flock -n /tmp/flock.lock -c "rsync -avz -e ssh 'name@host:/path' /path"
flock устанавливает блокировку на указанный файл, в случае успеха выполняет нашу команду.
«Я» — каждый пользователь мира *nix. «Ubuntu» — человечное отношение к другим пользователям мира *nix.
Дабы не плодить процессы в кроне.
flock -n /tmp/flock.lock -c "rsync -avz -e ssh 'name@host:/path' /path"
flock устанавливает блокировку на указанный файл, в случае успеха выполняет нашу команду.
Решил реализовать уведомление на почту о том, что кто-то авторизовался в ssh. Сперва решение выглядело вот так:
echo -e "Remote connection from\t $SSH_CONNECTION \nLogin $USER" | /bin/mail -s "[SSH] Login on $(hostname)" мояпочта@сайт.ru
Добавляем эту строку в /etc/ssh/sshrc (в случае, если этого файла нет, а его скорее всего не будет, его следует создать)
У этого решения есть существенный недостаток — письма будут отсылаться после любой аутентификации по ssh. Даже если это вы залогинились, письмо все равно вам придет. Дабы не получать массу писем и ввиду того, что я начал изучать python, решил попробовать написать на нем. Получился скрипт сравнивающий с нашего ли ip залогинились, в противном случае шлет email на указанную почту.
#!/usr/bin/env python import smtplib, os, platform from email.MIMEMultipart import MIMEMultipart from email.MIMEText import MIMEText server = smtplib.SMTP('smtp.сайт.ru', 25) sender = 'root@'+platform.node() to = 'мояпочта@сайт.ru' ip = 'xxx.xxx.xxx.xxx' sship = os.environ['SSH_CONNECTION'] loginname = os.environ['LOGNAME'] msg = MIMEMultipart() msg['Subject'] = '[SSH] Login on ' + platform.node() msg['From'] = sender msg['To'] = to text = 'Remote connection from\t' + sship + '\nLogin ' + loginname msg.attach (MIMEText(text, 'plain')) textmail = msg.as_string() if ip in sship: print ('hi. Welcome!') else: print ('who is it?') server.sendmail(sender, to, textmail)
Сохраняем скрипт в файл, например, noticessh.py и прописываем путь к нему в /etc/ssh/sshrc. К сожалению не со всеми версиями второго питона работает, так же мешает авторизовываться по sftp в случае, если sftp работает через ssh. FileZilla, например, ругается «Оut of memory!» Надо бы допилить, но на данный момент к сожалению знаний по питону не достаточно.
Вчера столкнулся с таким интересным явлением, когда у совершенно стороннего чужого домена в качестве А записи в DNS с был указан ip нашего ресурса. Т.о. этот совершенно чужой домен показывал контент нашего портала и даже индексировался поисковиками. Для чего это было сделано не знаю, возможно ради повышения ТИЦ и PR своего домена.
Исправил это безобразие записью в .htaccess
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} чужойсайт.ru
RewriteRule ^(.*)$ http://нашсайт.ru/ [R=301,L]
После обновления Ubuntu с 13.04 до 13.10 обнаружилась, что в Tor Browser нельзя ничего ввести с клавиатуры ни в строке адреса (URL), ни в строке поиска, ни вообще где бы то ни было.
Виновником оказался IBus. Как я понял, для русского языка данная программа не очень нужна, поэтому её можно отключить.
Читать далее «Tor Browser и Ubuntu 13.10 Saucy Salamander»
Сегодня при попытке сделать apt-get update получил сообщение:
W: Произошла ошибка при проверке подписи. Репозиторий не обновлён и будут использованы предыдущие индексные файлы. Ошибка GPG: http://apt.postgresql.org precise-pgdg Release: Следующие подписи неверные: KEYEXPIRED 1381654177
W: Не удалось получить http://apt.postgresql.org/pub/repos/apt/dists/precise-pgdg/Release
W: Некоторые индексные файлы не скачались. Они были проигнорированы или вместо них были использованы старые версии.
В wiki PostgreSQL Global Development Group (PGDG) я обнаружил новость от 10.10.2013 о том, что «новый pgdg-keyring увеличивает дату пригодности ключа». «Отлично!», — подумал я: «Как же мне обновить пакет, если я даже список пакетов с их сервера забрать не могу?»
Читать далее «Обновление PGDG apt-key»
Я уже писал о My traceroute. Сегодня мне понадобилось получить вывод удобный для копирования. Оказывается все уже придумано.
mtr --report --report-cycles 10 ya.ru > ya.ru.txt
Закончилось место в /var, cron начал ругаться и сыпать на почту алармы. Смотрю df -h место занято на 99%. Делаю du -hs /var места свободного как минимум 50%.
$ lsof | grep deleted
cmasm2d 3291 root 1w REG 253,1 476834734 82306 /var/spool/compaq/cma.log.1 (deleted)
и таких строк очень много.
Я нашел два способа очистить место. Перезапустить процесс держащий удаленные файлы на привязи (так я поступил с заббикс агентом) или сделать размер файла чуток поменьше.
$ ls -l /proc/3291/fd/
итого 0
lr-x------ 1 root root 64 Авг 28 12:16 0 -> /dev/null
l-wx------ 1 root root 64 Авг 28 12:16 1 -> /var/spool/compaq/cma.log.1 (deleted)
l-wx------ 1 root root 64 Авг 28 12:16 2 -> /var/spool/compaq/cma.log.1 (deleted)
lrwx------ 1 root root 64 Авг 28 12:16 3 -> /dev/hpilo/d0ccb6
cat /dev/null > /proc/3291/fd/1
Файл останется открытым, но размер у него будет 0 байт
Теперь df -h покажет более приятную глазу картинку.
Если есть еще варианты решения, буду благодарен.
Почему вообще du и df показывают разный объем доступного дискового пространства?
Вам нужно разобраться, что на самом деле делают команды du и df. du проходит по дереву каталогов, замеряя, насколько большой объем занимает каждый файл, и выдает общий объем. df просто запрашивает файловую систему об оставшемся объеме. Это выглядит как одно и то же, однако файл без записи в каталоге затронет df, но не повлияет на du.
Когда программа использует файл, а вы его удалили, файл на самом деле не удаляется из файловой системы, пока программа не прекратит его использовать. Однако файл тут же удаляется из списка каталога. Вы можете легко это видеть при помощи такой программы, как more. Предположим, что у вас имеется файл, настолько большой, что его присутствие влияет на вывод команд du и df. (Так как в настоящее время диски могут быть настолько большими, это может быть очень большой файл!) Если вы удалите этот файл в процессе работы more над ним, на команду more это не повлияет и она не сообщит, что не может просматривать файл. Запись о файле просто удалена из каталога, так что другие программы или пользователи не смогут к нему обратиться. du покажет, что файл исчез — она просматривает дерево каталогов, а файла там не будет. df показывает, что он все еще здесь, так как файловая система знает, что more все еще использует это пространство. Как только вы закончите работу с more, команды du и df придут в соответствие.
http://www.freebsd.org/doc/ru_RU.KOI8-R/books/faq/disks.html#idp77037104
Так получилось, что на новой работе, ввиду того, что админы с какой-то периодичностью сменялись, оказался сервер с древним openfire, от которого никто не знал пароль. Работает, ну и пусть себе дальше работает. А у меня же руки чешутся, вот и решил поиметь таки на него доступ.
Все оказалось не очень сложно.
Открываем конфиг файл (аккуратно, кто не знаком с vim, может использовать nano)
vim /opt/openfire/conf/openfire.xml
добавляем выделенные жирным строки
<!-- root element, all properties must be under this element -->
<jive>
<admin>
<authorizedJIDs>admin@example.com, new@example.com</authorizedJIDs>
</admin>
<adminConsole>
<!-- Disable either port by setting the value to -1 -->
<port>9090</port>
<securePort>9091</securePort>
</adminConsole>
Перезапускаем openfire
service openfire restart
МФУ настраивает очень легко, благо драйвера для принтера выложены на официальном сайте.
Для настройки сканера нужно установить scan-key-tool и brscan4. Забираем также с оффсайта
Не забываем добавить себя в группу lp.
usermod -a -G lp username
Отключить запуск unity и вообще графической оболочки в ubuntu 12.04 можно подправив файл /etc/default/grub
Нужно изменить строку
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
на
GRUB_CMDLINE_LINUX_DEFAULT="text"
и выполнить
sudo update-grub