Search
Write a publication
Pull to refresh
17
0
Send message
А по мне так нормально написано. Как и любой Howto нужно читать через призму собственных требований/предпочтений и данный howto хорошая точка отправки. Хорошо, что автор указал про usb-modeswitch — на него сейчас часто приходится наступать.
Что не понравилось — то, что автор не нашёл решения на «ньюансы использования»:
… даже если что-то глючит и модем отключается от сети? Ну тогда поможет следующий скрипт…
По мне, так это костыль, думаю есть более правильное решение.
… Пока что я не могу предоставить нормального решения, поскольку сам ещё не занялся этим. Предполагают, что это из-за того, что программа usb-modeswitch не отрабатывает корректно...
Значит нужно ожидать этих проблем и бороться самому(.
В условиях плохого приёма соединение часто обрубается… Дело в том, что у портов ЮСБ есть ограничение на отдаваемый ток, при превышении которого, насколько я помню, порт отрубается.
А можно какие-нибудь доказательства? У меня складываются сомнения, что это так.
Спасибо за хорошую статью! Описано кратко, внятно и ясно. Жду продолжения, особенно:
… пример практической реализации мини-АТС на реальной аппаратной платформе можно будет рассмотреть в следующей статье.
Скроллинг назад под screen у меня абсолютно нормальный (Shift+PgUp), не считая возврата к предыдущему состоянию, когда минуты в caption внизу страницы меняют своё значение. А вот обычный скроллинг страниц, к примеру man bash — притормаживает. Другие претензии к screen в плане удобства, которые у меня были вначале — отсутствие «пикания» и автозавершения команд — исправлены и рецепт приведёт в статье.
Я старался не проводить в статье обзор методов аудита в Linux. Это статья для тех, кто как я, решит остановиться на этом методе из обзорной статьи про script, screen, sudo, auditd.
Вариант с подключением на уровне системы к ttyX думаю лучше, но я с ним не знаком и их не было в статье, на основании которой был выбран метод (см.выше).
Решение не найдено, кроме применения административных мер к пользователю («С какой целью запускал отключение логов?»).
Спасибо за информацию.
Скрипт чуть модифицирован (не работали команды типа ssh user@server «ls -al /; sleep 5; echo Works», а также изменён метод записи в лог-файл — теперь это простое echo >>) и внесён в статью.
Думаю для таких вариантов нужно более серьёзные решения (auditd, к примеру), но там непросто читать лог-информацию.
К примеру на команду
“hostname audit-test.home.private”

В логе окажется:
type=SYSCALL msg=audit(1358306046.744:260): arch=c000003e syscall=170 success=yes exit=0 a0=2025010 a1=17 a2=7 a3=18 items=0 ppid=23922 pid=26742 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=16 comm="hostname" exe="/usr/bin/hostname" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="system-locale"
У меня строка выглядит вот так (ну и разноцветно):
hostname | открытые окна        | load average   | date            | time
server   | 0*$(L) bash  1 bash  | 0.00 0.00 0.00 | Wed, 07/17/2013 | 13:14

Спасибо за информацию. Отключает логирование! Думаю как заблокировать эту команду.
Спасибо за информацию. Считаю это не совсем нужным действием — отвечать нужно ли подключать, ведь для того, чтобы отключиться от screen и оставить работать процессы в фоне — надо проделать «телодвижения», соответственно зачем их проделывать, если потом отвечать «не подключать screen». А если просто выйти (^d или exit), то и screen убивается.
Нет, не хватает. Тогда при выходе из screen (^d или просто exit) попадаем в bash без логирования. Поэтому и надо убить родительский процесс.
Логирует всё, что выводит текст. Есть даже побочные эффекты этого — если запустить top и забыть выключить, то будет очень много логов.
Насколько мне известно auditd не логирует вывод информации на экран.
При такой команде всё равно попадает в screen и лог работает.
Не будет, просто исключатся возможные махинации с PATH и, соответственно, запуск собственного screen-а или kill-а.
Я проверил и удалённо, и локально — логируется. С другой машины ввёл:
ssh root@server -t /bin/bash -l
root@server's password: 
root@server:~# this is a test message
bash: this: command not found

Выхожу, смотрю логи:
root@server:~# cat /var/log/screen/root@server-20130716-\ 9\:32\:04.log 
root@server:~# 
root@server:~# this is a test message
bash: this: command not found
root@server:~# ogout

Как вариант есть возможность в ~/.ssh/authorized_keys сделать:
command="/bin/bash". Вижу сразу 2 нюанса:
1) Необходимо добавлять этот файл каждому пользователю
2) Авторизацию придётся запрещать по логину — только по ключу.
А где ещё быть утилитам screen и kill и, главное, зачем?
Для меня это имеет смысл, когда приходится одни и те же скрипты запускать на Linux и OpenWRT. У них пути разные и which очень помогает.
P.S. Кстати изменения в текст статьи внёс — путь указал точно.
Полагаю это всё должно делаться из под рута и пока будет делаться, всё это будет логироваться:).
Не логируется! Идей пока нет как решить, но чую, что если будут, то это будут большие костыли…
Есть идеи?

Information

Rating
Does not participate
Location
Алматы (Алма-Ата), Алма-Атинская обл., Казахстан
Registered
Activity