Пример изменения текста:
lexus@reinstein:~$ echo lexus
lexuslexus@reinstein:~$ echo lexus | tr [a-z] [A-Z]
LEXUS
Подробности – в man tr.
Пример изменения текста:
lexus@reinstein:~$ echo lexus
lexuslexus@reinstein:~$ echo lexus | tr [a-z] [A-Z]
LEXUS
Подробности – в man tr.
Для создания 64-мегабайтного файла “64mb-file” в директории /tmp:
dd if=/dev/zero of=/tmp/64mb-file bs=16k count=4096
Скачиваем соответствующий образ:
$ cd /tmp
$ wget ftp://slackware.osuosl.org/pub/slackware/slackware-13.37/usb-and-pxe-installers/usbboot.img
Создаём загрузочную флешку:
# cd /tmp
# dd if=usbboot.img of=/dev/sdc bs=512
Далее загружаемся с флешки, запускается установка, как и с CD, ставим пакеты с HDD/другого носителя/по сети.
Взято с http://www.cyberciti.biz/faq/installing-slackware-linux-bootable-usb-stick/
Наглядная памятка, что поменялось в NAT, начиная с версии OpenBSD 4.7.
Подробности тут http://openbsd.org/faq/pf/nat.html
При подключении RDP-клиента RDP-сервер смотрит на его hostname.
Это может повлечь за собой неприятные ситуации в случаях, если мы поменяем hostname клиента.
Пример из жизни. Сложилась необходимость менять hostname’ы на компьютерах VPN сети, приводя их к новому единому стандарту. После изменения стали поступать жалобы на невозможность подключиться к серверу терминалов. (Менял путём редактирования /etc/hostname.)
Например, rdesktop выдавал вот такое: no valid license available.
Поскольку в технология MS я не силён, то заранее не предусмотрел возможность такого исхода. Ну и соратник мой, попросивший менять именя компьютеров в VPN-сети, тоже видимо не был в курсе таких событий.
Погуглив, узнал, что надо ковырять в сторону hostname клиента. По умолчанию RDP-клиенты определют его автоматически, но есть опции для указания вручную (например, в rdesktop и xfreerdp это опиция “-n”). В принципе, я знал о ней, но никогда раньше не мог понять – зачем указывать имя своего компьютера? Так ли это важно. :-) Теперь знаю.
Связь была очевидна – недавно измененные hostname’ы и рекомендации в Интернете на тему явного указания hostname’a при подключении. Попробовал указать при подключении старое, предыдущее, имя компьютера-клиента. Подключился без проблем.
Но на этом приключения не закончились. Хорошо, что я помнил старое имя компьютера-клиента. А что делать, если там было что-то вроде m-GB41A-tr ? Решение проблемы и искать не пришлось – само всплыло, в виде ругательства команды “sudo” – при попытке выполнить что-то через sudo, все шло хорошо, разве что выплевывалось сообщение “sudo: unable to resolve host <новый hostname>”.
Дело осталось за малым: вспомнить выцепить откуда-то прежнее имя компьютера. Делается это просто: смотрим /etc/hosts. И все видим, что нужно.
PS: hostname я изначально менял путем реадктирования /etc/hostname.
PS2: всё это производилось на Ubuntu (10.04, 10.10, 11.04), однако справедливо для любого GNU/Linux-дистрибутива.
PS3. Что касается Windows-сервера-терминалов, в этом деле я понимаю очень мало, но со слов специалиста, сертификаты хранятся 3 месяца, так что если не вспомнить/не выцепить старые имена компьютеров-клиентов, и менять их, не согласовав с Windows-администратором, то можно обрести немало проблем с доступом на терминальный сервер.
lexus@reinstein:~$ cat /etc/fstab
UUID=80eb0f4c-acd7-4cbd-84c8-d5ae6b9318df /boot ext4 defaults 0 2
UUID=8cbc7571-76b3-4951-a37a-d705f9ec0ba6 / ext4 defaults 0 1
UUID=33b59b34-feeb-492a-8c0c-ca80106ab076 swap swap sw 0 0
UUID=099c8946-6790-4d98-ba0e-4bf880a4d858 /home ext4 defaults 0 2
UUID=0E0E0D510E0D336F /media/Storage ntfs-3g defaults 0 0
Выполняем либо ls -lR /dev/disk/ либо ls -l /dev/disk/by-uuid/ и наслаждаемся понятными записями.
lexus@reinstein:~$ ls -l /dev/disk/by-uuid/
итого 0
lrwxrwxrwx 1 root root 10 2011-06-08 09:21 099c8946-6790-4d98-ba0e-4bf880a4d858 -> ../../sda6
lrwxrwxrwx 1 root root 10 2011-06-08 09:21 0E0E0D510E0D336F -> ../../sdg1
lrwxrwxrwx 1 root root 10 2011-06-08 09:21 33b59b34-feeb-492a-8c0c-ca80106ab076 -> ../../sda5
lrwxrwxrwx 1 root root 10 2011-06-08 09:21 80eb0f4c-acd7-4cbd-84c8-d5ae6b9318df -> ../../sda1
lrwxrwxrwx 1 root root 10 2011-06-08 09:21 8cbc7571-76b3-4951-a37a-d705f9ec0ba6 -> ../../sda2
lrwxrwxrwx 1 root root 10 2011-06-08 09:21 f80ba67d-f7b3-4c8a-aaea-6dd1dbfcb6f0 -> ../../sdf1
Столкнулся с ситуацией, когда в меню GNOME не смог найти – где же выбирать/устанавливать локализацию интерфейса.
В этом случае нас спасёт команда gnome-language-selector , которая откроет нужное нам приложение выбора языка интерфейса.
Иногда бывает, что выбранный и (до)установленный язык не применяется к системе. В таком случае, его нужно перетащить мышкой в списке на самый верх, после чего перезагрузить компьютер.
Иногда пригождается, а из головы вылетает.
Кстати страдающим от вконтактозависимости вот такое правило будет не лишним:
iptables -A OUTPUT -p tcp -m string – -string vkontakte.ru – -algo kmp -j DROP
Просто чтоб не забыть, иногда пригождается.
tail -f /var/path/to/some/logfile
Я привык к slackware-way при “хранении” правил iptables – скрипт rc.firewall, лежащий в /etc/rc.d/ , содержащий в себе логически понятные строчки правил iptables и умеющий принимать значения start/stop/restart.
Но в GNU/Linux, как вы понимаете, существует много вариаций решения одной и той же задачи. Рассмотрим базовую настройку iptables в Ubuntu. Написано по материалам https://help.ubuntu.com/community/IptablesHowTo#Configuration%20on%20startup .
ВнИМАние! Подразумевается, что настраиваете файрвол на локальной машине. Если на удаленной, то когда будете задавать политику по умолчанию для цепочки INPUT, разрешайте (sudo iptables -P INPUT ACCEPT), а уж потом, на последнем этапе, запрещайте через правку конфига, имея уже явно прописанные разрешающие правила.
1 шаг.
Задаём цепочкам политики по умолчанию:
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP # если у вас не включен IP-forwarding, можно и не делать, но, думаю, лишним не будет в любом случае.
# sudo iptables -P OUTPUT DROP # я этого не делал, для себя решайте сами. Не забудьте только в случае блокировки OUTPUT по умолчанию добавить правило:
sudo iptables -A OUTPUT -m state —state ESTABLISHED,RELATED -j ACCEPT
2 шаг.
Разрешаем входящий трафик на loopback-интерфейсе:
sudo iptables -A INPUT -i lo -j ACCEPT
3 шаг.
Создаём правила для входящих соединений на нашу машину:
sudo iptables -A INPUT -p tcp —dport 22 -j ACCEPT
Добавляем при необходимости другие правила/опции.
4 шаг.
Разрешаем входящие соединения со статусом ESTABLISHED и RELATED:
sudo iptables -A INPUT -m state —state ESTABLISHED,RELATED -j ACCEPT
5 шаг.
Сохраняем введённые правила в файл /etc/iptables.rules:
sudo bash -c “iptables-save > /etc/iptables.rules”
6 шаг.
Создаём скрипт /etc/network/if-pre-up.d/iptablesload следующего содержания:
#!/bin/sh
iptables-restore < /etc/iptables.rules
exit 0
7 шаг.
Создаём скрипт /etc/network/if-post-down.d/iptablessave следующего содержания:
#!/bin/sh
iptables-save -c > /etc/iptables.rules
if [ -f /etc/iptables.downrules ]; then
iptables-restore < /etc/iptables.downrules
fi
exit 0
8 шаг.
Делаем только что созданные скрипты исполняемыми:
sudo chmod +x /etc/network/if-pre-up.d/iptablesload
sudo chmod +x /etc/network/if-post-down.d/iptablessave
Готово. Теперь при необходимости можно редактировать файл с правилами и перезапускать скрипт /etc/network/if-pre-up.d/iptablesload для вступления изменений в силу.
О том, что мне не нравится в этом подходе.
Просмотрите ваш файл /etc/iptables.rules . Вам не кажется, что он несколько “захламлён” (в примере я привожу не всё содержимое) ?
# Generated by iptables-save v1.4.4 on Mon May 23 15:20:51 2011
*filter
:INPUT DROP [172:18570]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [681:120764]
[30:1727] -A INPUT -i lo -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp —dport 22 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp -m multiport —dports 135,139,445 -j ACCEPT
[176:17992] -A INPUT -p udp -m udp -m multiport —dports 137,138 -j ACCEPT
#
-A INPUT -p icmp -m icmp —icmp-type 8 -j ACCEPT
#
[556:391583] -A INPUT -m state —state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Mon May 23 15:20:51 2011
И не забудьте обратить внимание при дальнейшей ручной правке файла, чтобы после строк с правилами следующей строкой была строка со словом “COMMIT”, иначе при “перезагрузке” набора правил iptables, эти правила не вступят в силу.
В общем, не привычен мне этот метод.