Многие мои знакомые так или иначе используют протокол SSH (заходя на свои роутеры, веб хостинги и непосредственно на собственные компьютеры дома и в офисе), при этом не все об этом знают.



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

В этой заметке вы узнаете:

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

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

Конкретно для меня стимулом явилась возникшая сложность при работе с переводами. Проблема заключалась в следующем: несмотря на разрешение экрана в 1920х1200 сделать так, чтобы оба текста располагались перед глазами, было практически невозможно. Да и дергаться мышью туда-сюда, управляясь с полосами прокрутки, запоминая положения текстовых фрагментов, довольно таки неудобно. Консольный текстовый редактор, управление которым осуществляется клавиатурой, представлялся для меня логичным решением. Оставалось только разобраться в нем и из огромного массива информации выбрать только то, что нужно.

Забегая вперед, скажу, что информацию пришлось собирать фактически по крупицам. Основное направление в использовании Vim в качестве редактора «для программистов» привело к тому, что вопросам обработки «простого» текста уделяется мало внимания. В конце-концов, с поставленной задачей, как мне кажется, удалось справиться.

Наблюдая выводы таких команд, как top, htop, uptime, w и, возможно, других, пользователь наверняка обращал внимание на строку load average:

Собственно, хочется просто и доступно рассказать про такую замечательную вещь как Logical Volume Management или Управление Логическими Томами.
Поскольку уже давно пользуюсь LVM-ом, расскажу что он значит именно для меня, не подглядывая в мануалы и не выдёргивая цитаты из wiki, своими словами, чтобы было понятно именно тем кто ничего о нем не знает. Постараюсь сразу не рассказывать о всяческих «продвинутых» функциях типа страйпов, снапшотов и т.п.

Потребовалось мне перекодировать некоторое количество видео-файлов. Для этого я написал следующий сценарий:

#!/bin/bash

recode() {
mencoder -o $2 $1 -ovc x264 -x264encopts bitrate=22000:keyint=50 -oac mp3lame -lameopts vbr=3:br=320 -fps 50
}
recode input/00108.mts 00108.avi
recode input/00109.mts 00109.avi
...
...


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

Один мой друг сказал по поводу pv следующее «Я админю семь лет, мне нужна была эта тулза десятки раз, а я даже не знал что она существует». В размышлениях над тем как заполучить инвайт на Харбе, я набрал в поиске pv. И ничего не нашел.

Задача

Когда диски были маленькие, а Интернет большой, владельцы частных FTP-серверов сталкивались со следующей проблемой:
На каждом жестком диске создавалась папочка Video или Soft, и получалось так, что добавив новый жесткий диск, приходилось делать на нем папочки Video2, Soft2, etc.
Задача поменять жесткий диск на диск большего объема приводила к тому, что данные нужно было куда-то переносить, все это происходило нетривиально и с большими downtime'ами.
Разработанная нами система в 2005 году позволила собрать надежный и быстрый массив в 3 терабайта, масштабируемый, расширяемый, в режиме онлайн, добавляя диски или целые сервера с дисками.
Цена всего решения составляла 110% от стоимости самих дисков, т.е. по-сути, бесплатной, с небольшим overhead.

Вот примерная схема устройства нашего хранилища:

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

Сформулируем, что же мы хотим получить в результате:
1. Чтобы канал поровну делился между пользователями.
2. Чтобы канал зря не простаивал.
3. Чтобы онлайн-игры, ssh и telnet не «лагали» даже при полной загрузке канала, например торрентами.

Задача автоматического монтирования флешек решается довольно просто в KDE или GNOME — эти среды можно настроить так, что они сами всё смонтируют, откроют файловый менеджер и покажут значок в трее. Но что делать, если у вас только консоль или стоит, например, awesome? Или вы не хотите разбираться с конкретным DE, а ищите универсальное решение?

Независимое от DE решение есть — udev.

Данная статья является переводом той части статьи на KernelNewbies, которая описывает особенности файловой системы Ext4. Последний раздел статьи, об использовании Ext4, уже на Хабре публиковался.

Ext4 — это результат эволюции Ext3, наиболее популярной файловой системы в Linux. Во многих аспектах Ext4 представляет собой больший шаг вперёд по сравнению с Ext3, чем Ext3 была по отношению к Ext2. Наиболее значительным усовершенствованием Ext3 по сравнению с Ext2 было журналирование, в то время как Ext4 предполагает изменения в важных структурах данных, таких как, например, предназначенных для хранения данных файлов.

Это позволило создать файловую систему с более продвинутым дизайном, более производительную и стабильную и с обширным набором функций.

Так уже получилось что писал статью для howtoforge. И естественно тут же все это оказалось в русском варианте на других сайтах. Только вот незадача: в статье были допущены неточности, и публицисты с других «сайтов» вставили as-is.
Хочу попробовать исправить это оплошность.
Для чего это надо?
Объясню на примере: был у меня фтп с 2мя сетевыми картами, но использовалась одна. Со временем весь 1Гб/с начал забиваться по вечерам — и людям плохо, и у меня iowait растет. Но есть вторая сетевая карта. Так вот такое объединение позволит использовать 2 (3, 4, 5...) как одну с 2Гб/с.

Поделюсь небольшой находкой, маленькой программой для восстанавления удаленные файлы. Какое-то время назад было очень нужно, но программы Scalpel, тогда не нашел, к сожалению. На мой взгляд, из всех известных мне способов — это один из наиболее простых. Scalpel появился из проекта Foremost.

И так любителям rm -rf посвящается:

Есть у меня своя домашняя сеть, с linux сервером, и подключена она к интернет с помощью беспроводного соединения — на крыше антена и роутер, к серверу подключено витой парой. Все вобщем то неплохо, канал с гарантированой полосой в обоих направлениях, постоянный IP адрес, довольно надежный — падает редко. Но вот есть у него один минус — цена кусается.
Ценовая политика провайдера построена так, что для того, чтоб увеличить скорость в два раза — платить тоже надо в два раза больше. А скорости хочется больше! И надежности тоже — как то во время сильных заморозков роутеру стало «холодно» и интернета вечером и ночью небыло.
Поэтому задумал я провести домой второй интернет-канал, выбар пал на одного известного на Украине провайдера, предоставляющего доступ по ADSL. У него и тарифы недорогие и модем ADSL стоит недорого. Так я и сделал, подключился, воткнул ADLS модем в свич — все работает. Но от старого доброго беспроводного канала отказываться мне нехотелось, поэтому задумал я сделать так, чтоб интернет трафик шел сразу по обеим каналам, так, чтоб я мог воспользоваться суммарной пропускной способностью. Да еще и чтоб при падении одного канала всю нагрузку на себя брал другой.

Здесь я хочу рассказать о настройке шлюза на Linux'e, для использования 2-х (и более) провайдеров интернета.
Для настройки мы будем использовать возможности iptables и утилиты ip из пакета, который как правило называется iproute2. А для решения поставленной задачи пакеты мы будем маршрутизировать на основе «policy routing» (т.е. маршрутизация на основе политик), а не «destination routing» (маршрутизация на основе адреса получателя).

Продолжим настройку нашего шлюза, про который я говорил в предыдущей статье. Напомню, там мы настроили правила маршрутизации, теперь нам надо заняться iptables. Сейчас мы настроим сеть состоящую из шлюза и сервера. На шлюзе будет работать SSH и DNS, а сервер у нас будет виндовый на нем у нас RDP и SMTP. Сеть будет настроена таким образом, что через любой из внешних айпишников мы сможем подключаться к любому из серверов, а SMTP сервер будет выходить наружу через основного провайдера.

Статья посвящена работой с потоками данных в bash. Я постарался написать ее наиболее доступным и простым языком, чтобы было понятно даже новичкам в Linux.


В одной из моих статей мы рассматривали запись звука в файл с помощью команды:

cat /dev/audio > /tmp/my.sound

Эта команда читает файл (устройство) /dev/audio с помощью команды cat и перенаправляет информацию из него в файл /tmp/my.sound (с помощью оператора >).

Как обещал в одном из комментов — публикую свой опыт перехода на линуксы. Рассказ будет несколько сумбурным. Потому что я не писатель и, собственно, таким и был переход.
Все началось с планирования бюджета на 2009-й год. Составив бюджет я понес его начальству. Увидев сумму в 400 т.р. статьи «Расходы на ПО» начальство задумалось.
— С линуксами знаком?
— Ну дома стоит…
— Контору на них перевести сможешь?
— Терминал-сервер оставить надо на винде (1с и еще ряд задач), а вот остальные машины, в принципе, реально.
Так и начался переход. Дистрибутив выбрали убунту. Во-первых, потому что дружелюбный, а во-вторых, потому что с остальными дистрами я толком не общался.

События происходят за садовым кольцом в стандартной фирме, использующей, в основном, решения от Microsoft, не выделяясь в этом плане на фоне остальных. С некоторых пор в фирме работает линуксоид, который терпеть не может работать в ОС Windows.

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

Помните я про kill -9 $$ рассказывал?

Так вот, немного повторюсь: kill -9 $$ — «выход» из консоли без сохранения истории.
Как это работает: $$ — идентификатор текущего процесса консоли; kill -9 думаю объяснять не надо? Ну на всякий случай: kill -9 убивает указанный процесс (дочерние процессы также убьются, сами).

Но перед тем как бесследно исчезать из консоли не мешало бы всё таки подчистить файл ~/.bash_history, и самый интересный файл: /var/log/lastlog, именно в нём записан последний IP с которого логинились. Файл этот не обычный plain text, поэтому править его надо осторожно. Открываем и везде меняем свой IP.
В общем то его можно совсем удалить, тогда при логине в консоль вообще не будет строчки с last login, у меня на Debian, например, он сам не создается.

Таким образом, зная пароль, можно практически незаметно попасть в систему и так же незаметно оттуда исчезнуть.

^{Для операций с файлом lastlog нужны права root.}

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

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

В данном случае, мы не будем использовать мощные программы, или даже целые системы для резервного копирования данных, ограничимся самым доступным что у нас есть. А именно — Bash скриптом.