Ответы пользователя по тегу Linux
  • Можно ли посмотреть, что печатает в консоли Linux пользователь подключенный по SSH?

    есть такая утилита `w`:
    w - Show who is logged on and what they are doing
    просто одна только буковка в терминале
    в последней колонке указывается последняя команда, которую ввел юзер
    на сервере при подключении удаленно по ssh работает и отображает корректно
    sazhyk упоминал, что можно настроить bash-окружение так, чтобы история дампилась сразу же в ~/.bash_history:
    нужно добавить следующие строки в ~/.bashrc или в ~/.bash_profile:
    shopt -s histappend
    PROMPT_COMMAND="history -a;$PROMPT_COMMAND"

    источник: web.archive.org/web/20090815205011/http://www.cube...
    Ответ написан
    Комментировать
  • Как перенести docker root dir на другой диск?

    на сколько я помню, я нагло удалял старую папку рабочую папку с докером, изменял в конфиге /etc/defaults/docker путь к папке и перезапускал его. он у меня исправно работал. но это было еще на v1.7 и на убунте 14.04, если мне не изменяет память. сейчас он у меня живет в родной папке и я не переносил его никуда т.к. заменил свою SSD-шку на ноуте на более объемную.
    тут ребята пишут: https://github.com/docker/docker/issues/3127#issue...
    кажется, я именно так и делал - прописывал в конфиге
    опишите более подробно что вы делаете и какое у вас окружение (какая ОСь, к примеру)
    Ответ написан
    Комментировать
  • Откуда начинает выполнятся дочерний процесс?

    если писать на С и использовать fork, то дочерний процесс начинает исполняться с места, где был вызван fork. тогда код разделяется на два подпространства: родительский процесс и форкнутый процесс
    stackoverflow.com/a/11734354
    судя по коду, в питоне аналогично - процесс исполняется с места форка
    Ответ написан
  • Зачем запускать сервисы в контейнере от имени непривилегированного пользователя?

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

    далее, не просто так для каждого сервиса выделяется пользователь, которые имеет права делать только то, что ему нужно и не более. если Вы хотите чтобы Ваш сервис был переносим из контейнера вне контейнер и наоборот, то нужно позаботиться о том, что в контейнере он себя чувствовал и вел точно так же, как и на любом другом линуксе. окружение для сервиса должно быть прозрачным и легко заменяемым. если Вы захотите переселить этот сервис из контейнера в на хост-машину и внутри контейнера Вы не заботились о его правах (запустили под рутом и все), то при запуске на хосте у Вас могут возникнуть проблемы т.к. Ваш сервис может все и, скорее всего, придется перепиливать сервис для того, чтобы он мог работать так, как нужно вне контейнера

    у меня сложилось впечатление, что контейнеризация сервисов для Вас является серебряной пулей безопасности. к примеру, есть хостинг и на нем есть дырявые сайты, которые чуть ли не каждый день хакают и через них сливают данные с других сайтов т.к. не проставлен open_basedir и все работает под апачем без разделения через SuID или без mpm-itk. и тут Вы познакомились з контейнеризацией и теперь запустили каждый сайт в своем личном окружении и все чики-пики с безопасностью. пример надуманый мною и не факт, что оно так у Вас на самом деле, но суть не в том

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

    вот с чем я сталкивался лично и что мне просто не давало жить. представим, что Вы создали сервис, который дополнительно еще генерирует какие-то файлы. файлы хранится в некоторой папочке в `/foo/bar/beez_service`, но Вы в эту папку монтируете другую папку хост-машины. Ваш сервис запущен от рута. Ваш сервис пишет лог и все эти файлы генерируются с правами рута и с неким chmod-ом, который был указана через umask или еще как-то. обычно над этим не заморачиваются и файлы имеют chmod 0664 - обычным пользователем удалить его невозможно. это как минимум неудобно. я понимаю, Вы можете ответить, что монтировать папки не всегда нужно, что можно использовать `sudo` на хост-машине, что не особо нужно удалять файлы через хост-машину и так далее
    Ответ написан
    Комментировать
  • Где хранятся задания cron?

    в Unix задачи cron-а лежат в нескольких местах:
    1. /etc/cron.d - здесь можно создавать файлы с заданиями крону, которые он будет загружать и исполнять по указанному расписанию. в этих файлах нужно указывать пользователя, от имени которого будет исполнено задание
    */10 * * * * root /root/backup.db.sh
    2. /etc/cron.daily, /etc/cron.hourly, /etc/cron.monthly, /etc/cron.weekly - здесь кладем скрипты, которые будут исполняться ежедневно, ежечасно, ежемесячно и еженедельно. это такие себе подготовленные расписания, которые подгружаются и исполняются в определенное время
    3. crontab -e - исполнение этой команды с ключом откроет текстовый редактор для редактирования заданий крону текущего пользователя. будьте внимательны - эти задания относятся к текущему пользователю и будут исполняться от его имени
    соответственно, самый просто способ для динамического редактирования заданий для крона - это манипуляция с заданиями в /etc/cron.d
    Ответ написан
    Комментировать
  • Чем проще и лучше делать инкрементальный бекап?

    Советую посмотреть в сторону rdiff-backup. Утилита делает дифференциальный бекап файлов. Далее Вы должны с помощью rsync забирать бекапы с сервера. Можете не забирать, а хранить а сервере, но если с сервером что-то случится (CloudMouse), то толку от тех бекапов на сервере не будет никакого
    Ответ написан
    Комментировать