3vi1_0n3 9 мая 2013 в 09:39

*nix-way: Даже если тебя съели, у тебя есть как минимум два выхода

2 мин

31K

*nix * Настройка Linux * Системное администрирование *

+69

126

Комментарии 126

frol 9 мая 2013 в 10:03

Создать пустой файл:

> <file>

echo "" > <file>

tee <file>
ctrl+D

Создать файл с текстом:

cat > <file>
<text>
ctrl+D

echo "<text>" > <file>

tee <file>
<text>
ctrl+D

Aux 9 мая 2013 в 10:07

Пустой файл можно создать командой touch.

justthefish 9 мая 2013 в 10:10

А еще так:
:> <filename>
То же самое с существующим файлом сделает его пустым. Иногда так удобно вручную чистить логи.

frol 9 мая 2013 в 10:16

Всё-равно мой первый вариант на 1 символ короче и магии в нём на одно двоеточие меньше :)

madkite 9 мая 2013 в 14:31

Да, но эта магия работает далеко не на всех шеллах. Вариант с двоеточием надёжнее.

firefish 9 мая 2013 в 10:21

[зануда]

echo -n "" > <file>

или

echo -n > <file>

[/зануда]

djem 9 мая 2013 в 11:11

Юмора ради, — вариант через Ж (не во всех *sh, но работает):

/dev/ass > /tmp/shit

akalend 9 мая 2013 в 16:23

как вариант
cp /dev/null [filename]

Komzpa 9 мая 2013 в 16:36

не сработает — получится или блочное устройство-копия /dev/null (под рутом) или сфейлит (под юзером).

djem 9 мая 2013 в 16:41

А Вы попробуйте? Получается вполне регулярный пустой файл. По крайней мере под Debian 6 и MacOS.

Komzpa 9 мая 2013 в 16:51

zsh, debian sid:

kom@ideacat ~ % cp /dev/null ll
cp: cannot create special file 'll': Operation not permitted

djem 9 мая 2013 в 17:02

Интересно… Под zsh на 6.0.7 под обычным пользователем у меня то же проблем нет. А можете попробовать так: /bin/cp /dev/null ll?

ValdikSS 9 мая 2013 в 18:06

Аналогично, zsh, получается пустой файл.

andrewsh 9 мая 2013 в 19:31

Перепробовал все шеллы, которые стояли, получается пустой файл. Чини шелл ;)

andrewsh 9 мая 2013 в 19:34

Не получается только тогда, когда передаю -r, то есть recursive. Может, у тебя где-то в alias запихано?

djem 9 мая 2013 в 16:30

Иногда нужно создать файл определённого размера. Вот варианты:

dd if=/dev/zero of=file.txt bs=1G count=1
truncate -s 1g file.txt
fallocate -l 1g file.txt
mkfile 1024m file.txt

Уверен, что можно придумать ещё много.

ZyXI 9 мая 2013 в 17:28

Вопрос: какой из этих методов создаст файл, реально занимающий заданный размер, а какой — т.н. «разреженный» (sparse) файл?

ValdikSS 9 мая 2013 в 18:07

Первый точно. Только надо bs=1M count=1000

Indexator 9 мая 2013 в 18:30

Может тогда bs=1M count=1024?

ValdikSS 9 мая 2013 в 18:31

Да нет.
N and BYTES may be followed by the following multiplicative suffixes: c =1, w =2, b =512, kB =1000, K=1024, MB =1000*1000, M =1024*1024, xM =M GB =1000*1000*1000, G 1024*1024*1024, and so on for T, P, E, Z, Y.

Indexator 10 мая 2013 в 16:37

Так я с этим и не спорю… Поэтому, чтобы получить 1G, вам нужно иметь count=1024, а у вас 1000…

ValdikSS 10 мая 2013 в 16:40

Вы правы, что-то я затупил.

EvilsInterrupt 9 мая 2013 в 18:52

Тыкайте в русскую версию приведенной Вами вики странички ;)

nazim 9 мая 2013 в 10:05

Почитайте здесь: coding-journal.com/restoring-your-unix-system-after-rm-rf/

nazim 9 мая 2013 в 19:27

Как ни странно, самую интересную и информативную ссылку по теме заминусовали. Статья описывает восстановление системы после частичной потери корневого каталога и смонтированных в нём файловых систем. Автору удалось залить uuencoded tar бинарник на повреждённую систему через терминал, собрать его обратно в исполняемый вид с помощью echo и base64, а потом восстановить систему с резервов. На мой взгляд, восхитительно.

pnick 10 мая 2013 в 07:46

Бесспорно, интересно. А причем тут оно?

nazim 10 мая 2013 в 08:29

Я посчитал, что текст по ссылке наиболее точно отражает ситуацию описанную автором. Правда удалили не один файл, а почти весь корень.

«Но вот представьте, что возникает ситуация, когда кто-то нечаянно, по глупости или из нехороших побуждений удалил исполнимый файл, который являлся бинарным файлом какой-то команды, которой вы более или менее часто пользовались. И что тогда делать?»

UUSER 9 мая 2013 в 10:08

>Создать пустой файл
touch

>Добавление пользователя в группу
gpasswd

>Удаление файла
unlink, rm, find. -name file -delete

Hint 9 мая 2013 в 10:15

У меня как-то возникала ситуация, когда нечаянно, по глупости ввел chmod -R 644 /.
И тут уже ни одна другая команда не помогла :) Всегда Permission denied (в том числе при входе по ssh).

MniD 9 мая 2013 в 14:57

А я как-то набрал sudo rm -rf ./*, но потерял в точку, опомнился через пару минут, когда подумал что долго удаляет, хорошо что только системные папки потереть немного успело, до хома не дошло =)

weirdan 9 мая 2013 в 15:25

А вот скажите, почему было не использовать rm -rf *? И не ошибешься, и набирать меньше.

yurnov 9 мая 2013 в 17:42

я вместо rm /dir1/dir2/dir3/* набрал rm /dir1/dir2/dir3 /*
под рутом. Спасло то, что без -r, довольно легко удалось востановить систему (не linux)

Zelgadis 9 мая 2013 в 19:04

Так это вы писали установщик драйверов под нвидию.

yurnov 9 мая 2013 в 20:05

чесно говоря — не понял коментария

Zelgadis 9 мая 2013 в 20:08

Не совсем драйвера, память меня подвела: github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac

Осторожно! Открытие этой страницы может повесить браузер из-за кол-ва комментариев на ней.

giner 10 мая 2013 в 08:37

Если у вас система не настроена пароноидально, то:
cp /bin/ls /tmp/chown
cat /bin/chown > /tmp/chown
/tmp/chown +x /bin/chown
rm /tmp/chown

arcan1s 9 мая 2013 в 10:18

useradd $username; mkdir /home/$username; chown $username:$username /home/$username; passwd $username

я понимаю, что *nix-way, но зачем так извращаться над простой командой?

PS в арче мейнтейнеры сказали, то adduser не нужно. И удалили из реп.

AlexWinner 9 мая 2013 в 11:17

В CentOS adduser создает юзера без пароля, надо отдельно вбивать. ЕМНИП.

3vi1_0n3 9 мая 2013 в 11:21

Не изменяет, так и есть. По крайней мере, в 5.x

giner 10 мая 2013 в 08:43

Пароль отдельно, но для создания домашней директории достаточно добавить --create-home.
В CentOS adduser является символической ссылкой на useradd, а в debian-based — отдельная команда, обёртка для useadd.

humbug 9 мая 2013 в 10:24

А я как-то удалил /usr/bin =(

SamOwaR 9 мая 2013 в 10:36

Всегда нужно держать под рукой загрузочный диск/флешку (например SystemRescueCd), busybox в нескольких директориях тоже не повредит. А вообще странно выглядит ситуация, случайно удалить ifconfig или passwd, под рутом? Для работы с пользователями всегда можно vi /etc/passwd и потом pwconv. Ну и бэкапы, они рулят!

3vi1_0n3 9 мая 2013 в 11:08

Согласен насчет busybox'а.
Вообще есть еще одно отличное средство — жесткие ссылки на все необходимые системные файлы, размещенные в труднодоступной директории. Тогда при удалении этих файлов содержимое останется и будет доступно по другому имени файла, плюс экономия дискового пространства.
Загрузочный диск/флэшка при удаленных системах неприменимы.
А хорошие PHP-разработчики, например, бывает иногда делают весьма странные вещи, в результате которых что-то нужное пропадает. Перенаправление с пайпом перепутают, например.
И бэкапы — это да, это наше всё. Как говорится, есть две категории людей — те, кто не делает бэкапы, и те, кто уже делает.
Иногда просто быстрее сделать действие другой командой, чем восстанавливать бэкап, особенно если последний полный был 7-10 инкрементальных назад.

SamOwaR 9 мая 2013 в 12:34

Загрузочный диск/флэшка при удаленных системах неприменимы.

Однажды (когда ещё source control системы были мало распространены, да и вообще очень плохо работали с большими бинами) мне очень пригодилась e2undel — получилось полностью восстановить новый файл, случайно удалённый художником на samba-шаре (бэкапы делаю ночью, он туда ещё не успел).

Как говорится, есть две категории людей — те, кто не делает бэкапы, и те, кто уже делает.

В самое яблочко!

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

Размер бэкапа самой системы такой маленький (~2GB), а современные носители такие большие, что ИМХО, можно не заморачиваться, и держать рядышком загрузочную копию рабочей системы, а ночью mount-rsync-umount.

Ingtar 9 мая 2013 в 10:40

ip addr = ip a
и
ip route = ip ro (ну и ip ru до кучи)

А вот за route -e и route -C я вам от всей души благодарен. Не знал.

ValdikSS 9 мая 2013 в 15:37

ip route = ip r еще

Indexator 10 мая 2013 в 00:00

Вы, похоже, не уловили смысл статьи. Вы все делаете одной и той же утилитой, которая понимает сокращения…

Amet13 9 мая 2013 в 11:08

Может быть не совсем подходит, но в качестве альтернативы можно использовать:

Останов системы:
shutdown -h now
=
init 0
=
telinit 0

Вывод архитектуры компьютера:
arch
=
uname -m

Перезагрузка:
shutdown -r now
=
reboot

Вывод дерева директорий:
tree
=
lstree

Проверка файловой системы:
fsck.msdos
=
dosfsck

3vi1_0n3 9 мая 2013 в 11:19

Еще

reboot
=
init 6

BuriK666 9 мая 2013 в 11:31

fsck.msdos это симлинк на dosfsck

olegafx 9 мая 2013 в 12:28

shutdown -h now
=
halt -p

sledopit 9 мая 2013 в 13:27

Фигня эта ваша перезагрузка через shutdown. Если диск отвалился или рут на сдохшем nfs'e, то спасёт только magic sysrq:

echo b > /proc/sysrq-trigger

Там ещё много интересных плюшек.

Fedcomp 9 мая 2013 в 14:46

poweroff

yermulnik 9 мая 2013 в 22:12

Перезагрузка:
shutdown -r now
=
reboot

Я не знаю, как под линуксами, но, насколько я помню, под фрёй эти две команды отличаются. Отличаются не результатом, а процедурой выполнения: первая попытается, так сказать, культурно завершить все процессы, используя rc.d скрипты (init.d в понимании линуксов) и далее перезагрузка, вторая — пошлёт всем SIGTERM, после чего SIGKILL для непонятливых процессов, и перезагрузка. Например, это может быть критично для «задумчивых» процессов, которые по SIGTERM не очень оперативно шатдаунятся.

klirichek 10 мая 2013 в 03:59

последний момент (с fsck) сильно зависит от файла.
Очень часто dosfsck это симлинк на fsck.msdos.

casperrr 24 мая 2013 в 11:31

halt

AterCattus 9 мая 2013 в 11:13

позанудствую)

Это у вас perl way: «There's more than one way to do it».
*nix way о другом)

3vi1_0n3 9 мая 2013 в 11:16

Философия UNIX (*nix-way) предполагает наличие большого количества простых программ для выполнения простых действий, а результаты работы можно передавать между разными программами через потоки.

У меня *nix-way об этом.
А несколько способов — это как одни эти самые простые действия заменить на другие.

AterCattus 9 мая 2013 в 11:19

Простые программы, на основе группирования вызовов которых можно сделать что-то большее — это ваш пример pingtrace.sh. Остальное, все же, perl way.

J_o_k_e_R 9 мая 2013 в 11:16

usermod -G не добавит в группу, а заменит все дополнительные группы пользователя на список groupname. Чтоб было так, как Вы хотите, должно быть

usermod -aG <groupname> <username>

-G, --groupsГРУППА1[, ГРУППА2,...[, ГРУППАN]]]
A list of supplementary groups which the user is also a member of.
Each group is separated from the next by a comma, with no
intervening whitespace. The groups are subject to the same
restrictions as the group given with the -g option.

If the user is currently a member of a group which is not listed,
the user will be removed from the group. This behaviour can be
changed via the -a option, which appends the user to the current
supplementary group list.

3vi1_0n3 9 мая 2013 в 11:26

Спасибо, поправил

tushev 9 мая 2013 в 15:16

Ага. Я уже в какой то статье нашел рекомендацию ввести «usermod -G» для добавления себя в группу. Потом с ноутбука жены искал статьи на тему «Как восстановить права на sudo через „rescue console“.

giner 10 мая 2013 в 08:58

верно, useradd -G — опасная команда :)
я использую gpasswd -a вместо неё

lanseg 9 мая 2013 в 12:29

ls ещё можно заменить на «echo *»

giner 10 мая 2013 в 08:59

может не сработать если файлов в директории очень много, скажет что-то типа «слишком длинная строка» или просто обрежет её

SamOwaR 9 мая 2013 в 12:54

2) Просмотр таблицы маршрутов

cat /proc/net/route

3) Просмотр списка сетевых интерфейсов

cat /proc/net/dev
ls /sys/class/net

10) Создание жесткой ссылки

link file_name link_name

olegcorner 9 мая 2013 в 12:58

Касательно п. 1 можно еще использовать
$ sed = filename | sed 'N;s/\n/\t/'

Что же касается остального… Почти все указанные утилиты входят в так называемый core пакет — пакет базовых утилит системы. Поэтому, например, если у вас кто-то (?) удалит cat хотя-бы, то практически ни один скрипт инициализации системы работать не будет. Вывод, я думаю ясен.
Про утилиту ip, netstat, ifconfig — ip входит в состав пакета iproute, все остальные используют этот пакет.
Если его удалить из системы, сетевой стек вообще никак не поднимется. Ifconfig даже в Debian не рекомендуется к использованию.
Касательно adduser — он практически не используется — useradd из core делает все одной командой.
Там выше еще было про выключение. Скажу сразу — отмирает. Все новые версии дистрибутивов переходят на systemd — там все по-другому. Да, Debian тоже уйдет туда — выхода другого нет, нарушится связь пакетов. Впрочем, в новоиспеченной 7 уже намекнули на него в /etc.
Напоследок насчет случайного удаления.
Для того, чтобы что из указанного удалить, нужно иметь права root. Такие права имеет только администратор системы. Или пользователь из группы wheel, который, соответственно имеет доступ к root через sudo.
Если администратор позволяет присутствовать в системе sudo — гнать надо поганой метлой!
Если администратор позволил себе удалить что-то из указанного, тогда не спасет, но может помочь получить моральную компенсацию потчевание виновника КАНДЕЛЯБРОМ.
Впрочем, от восстановления, трудного и неприятного, это не спасет.
Простая переустановка пакетов здесь тоже не поможет. В силу специфики системы.
Поставил-бы плюсик, да кармы не хватает.

ivlis 9 мая 2013 в 13:30

>> Если администратор позволяет присутствовать в системе sudo — гнать надо поганой метлой!

Можно не пользоваться sudo пока ты один администратор в системе. Потом уже начнаются проблемы.

sledopit 9 мая 2013 в 13:36

С sed целый список есть.

Насчёт удаления: бывают случаи, когда выходит из строя дисковая система и нужно срочно ~~спасаться бегством~~ что-то сделать. Такие штуки больше для этиз случаев, а не для «юзеры удаляют системные бинарники? не переживайте, у нас всё равно много способов сделать нужные вещи» (:

и про sudo: я правильно понимаю, что по вашему мнению его вообще не должно быть в системе? ( или всё таки быть должно, но должно быть корректно настроено? )

ps. ну и magic sysrq будет работать независимо от загрузки systemd/inetd/whateverd. (:

olegcorner 9 мая 2013 в 13:51

и про sudo: я правильно понимаю, что по вашему мнению его вообще не должно быть в системе? ( или всё таки быть должно, но должно быть корректно настроено? )

Здесь палка о двух концах. Лучше, конечно, чтобы админ был один. В другом случае sudo только для админ группы.

stavinsky 9 мая 2013 в 13:37

А чем Вас sudo не устроил? Вы из под root учетки все делаете?

olegcorner 9 мая 2013 в 13:56

Я делаю в root то, что нужно делать в root. И в Arch, и в Debian. Если нужно быстро — $ su - 'command' Сеанс закрывается сразу, никаких задержек, как по умолчанию в sudo, нет.
Т.е. в sudo есть сохранение сеанса, в течение этого времени можно зайти без пароля. Теоретически можно использовать.

Ernillew 9 мая 2013 в 14:34

То есть на локалхосте который вы админите всего один админ и потребности в sudo не возникает. А еще, судя по всему, у вас пользователи имеют пароли. Хм, вы вообще слышали о безопасности-то?

stavinsky 9 мая 2013 в 14:58

И это единственная причина по которой надо в «поганой метлой гнать» админа использующего sudo?
Кстати наш коллега написал статью, рекомендую к ознакомлению su или sudo

J_o_k_e_R 9 мая 2013 в 19:10

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

giner 10 мая 2013 в 09:06

Это так же как и про бэкапы, есть те, кто ещё не использует sudo и те, кто уже использует.
Без sudo привыкаешь сидеть под рутом. А сиденье под рутом чревато «ой, почему оно вставилось, а я хотел только скопировать?!» в то время, когда пытаешься скопировать с экрана терминала пару нужных строк.

J_o_k_e_R 10 мая 2013 в 20:58

После вот такого — sudo мне использовать на боевых серверах совсем расхотелось.

И (не)привычка сидеть под рутом — дело внутренней культуры. Я никогда sudo не пользовался, но под рутом работать так и не привык, даже неуютно как-то.

А копировать с терминала лучше всего вбив # в приглашение shell'а.

giner 10 мая 2013 в 21:26

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

> А копировать с терминала лучше всего вбив # в приглашение shell'а.
сработает только если всего одну строку копируете, но если несколько

Ingtar 9 мая 2013 в 13:40

Если администратор позволяет присутствовать в системе sudo — гнать надо поганой метлой!

А как должна быть организована работа отдела администраторов? Интересуюсь с целью повышения квалификации :)

olegcorner 9 мая 2013 в 14:06

Имелось ввиду sudo для некоторых пользователей. Хотя, работа отдела администраторов должна быть жестко увязана с работой отдела безопасности. И тут есть много механизмов обойтись без sudo. Расписывать здесь нет смысла. Все равно я против sudo в системе. Иногда это даже спасает от необдуманных действий.

olegcorner 9 мая 2013 в 14:20

P.S. А у вас в отделе все по простому?
А так я уже видел спецов из уважаемых учреждений. И вот результат работы их админисраторов (это не опечатка).
Взлом сайта Верховной Рады Украины

Ingtar 9 мая 2013 в 14:42

Немножко не понял, что имеется в виду «по простому»)
Права sudo только у администраторов. Всяким остальным выдаются права на отдельные каталоги или файлы по необходимости. На мой взгляд разумно, но увидев ваш коментарий подумалось, что есть правильное решение. Захотелось его узнать)

olegcorner 9 мая 2013 в 14:51

Конечно же, есть правильное решение. Но, я думаю этот топик не предназначен для обсуждения этого вопроса, потому что слишком большой объем займет. Все зависит от бюджета организации и ценности системы. Если это какой-нибудь а-ля пельменная на колесах, или хостинг на коленке, то, конечно, трудно обеспечить надлежащую защиту. Не принимайте близко к сердцу. Ничего обидного здесь нет. Это только бизнес-вопросы. Просто админ-отдел это не только админы и системы, это нужно понимать. Просто вот такой он сс… sudo :)

Ingtar 9 мая 2013 в 14:57

Потому и хотелось услышать про правильный процесс организации работы с учетными записями. Если вдруг у вас будет вдохновение — напишите об этом статью?) Думаю, она будет полезной.

olegcorner 9 мая 2013 в 15:25

Не знаю, будет ли она полезной в наше время. Слишком, наверное, старомодной она получится. И не айтишной. Знаете, это для примера, чтобы был понятен ход мысли. Однажды только у одной веб-студии я наткнулся на идеальную рекламу. Звучала она примерно так — «У нас интернет-магазин обойдется вам не дороже 15000 долларов США, но если у вас нет хотя бы 3 миллионов на его работу, не заказывайте его у нас. Интернет-магазин это придаток бизнеса, но не его основа.» Примерно так. Перефразируя, скажу, что информационные системы — это не мир, это его придаток. Т.е. безопасность системы определяется не только наличием или отсутствием sudo, но и еще многими факторами, напрямую, казалось-бы, не связанными с работой ИТ-отделов. Коротко, между карточкой учета кадров и лабиринтным коридором в администраторскую еще очень много звеньев (и денег). И эти процессы — не прерогатива администратора системы, и даже не начальника админ-отдела.
Так что, если нет другой возможности, пользуйтесь sudo, не забывайте про длинные пароли, ограничение сеанса sudo и пр. Остальное оставьте владельцу предприятия — пусть у него голова болит. Просто иногда предупреждайте. Лучше письменно.
И желаю вам отсутствия притаившихся гостей и «чужих ягодиц» на ваших серверах.

Ingtar 9 мая 2013 в 15:48

Спасибо большое за пожелание :)
Обнаружить белого пушистого зверька, хитро смотрящего на тебя — всегда очень невиданно и неприятно)