Полезные мелочи в работе веб-разработчика или «Как я мог без этого жить»

Злой троянец увел у меня аккаунт на хабр, после чего под моим аккаунтом начали публиковаться какие-то тупые мультики. К сожалению узнал я об этом только когда НЛО перевело меня в read-only, а рейтинг ушел в отрицательное значение. Не беда: повод наконец написать пост, который давно собирался.

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

1) Используй ssh-ключи, Люк!


Ключи я открыл для себя давно, хотя регулярно встречаются люди для которых они в новинку. Ключи ssh позволяют настроить один раз подключение и больше не хранить в «блокнотике» пароли ко всем сайтам
$ ssh-keygen -t dsa

Соглашаемся на стандартное расположение ключа: /home/user/data/.ssh/id_dsa,
Вводим (или не вводим) passphrase. Лучше все-таки вводить: система будет помнить ваш пароль от логина до логаута, то есть вводить постоянно этот пароль не нужно. Зато на порядок возрастет безопасность.
После этого мы получим два файла: ~/.ssh/id_dsa и ~/.ssh/id_dsa.pub.
Первый это личный (приватный) ключ — его лучше скопировать на флешку и спрятать про запас. Второй это ключ публичный, его-то мы и будем сообщать всем своим серверам.

Наиболее простой способ перенести ключ на сервер это выполнить у себя в консоли вот эту команду:
$ ssh user@hostname "umask 077; cat >> .ssh/authorized_keys" < ~/.ssh/id_dsa.pub

и в последний раз ввести пароль к SSH удаленного компьютера

2) Используй конфиги ssh, Люк!


Все работает прекрасно, но надо каждый раз вводить длинные логины и хостнеймы. Надо оптимизировать!
Редактируем файл ~/.ssh/config, добавляем:
Host host
User user
Hostname hostname

Проверяем права на файл ~/.ssh/config, если они разрешают писать кому-то кроме нас, меняем на другие:
$ chmod 644 ~/.ssh/config

Допустим компьютер, к которому мы хотим подключиться находится за натом. Нам нужно зайти по SSH на один сервер, затем уже с него перейти на нужный компьютер. Если это нужно делать по множеству раз в день это очень, очень быстро надоест.
Прописываем новое правило в конфиг:
Host computer.hostname
Hostname 192.168.1.10
User user
ProxyCommand ssh hostname nc %h %p

Вот и все! Теперь можем написать ssh computer.hostname, пользователь будет подставлен автоматически, соединение будет установлено напрямую с нужным компьютером. Главное не забыть ему тоже положить свой публичный ключ.
В добавок опишу две полезные директивы
LocalForward localhost:8080 192.168.10.10:80 #Пробрасывать удаленный порт к себе каждый раз, когда происходит подключение по SSH.
Port 8022 #указать порт SSH сервера, удобно когда он живет не на стандартном порту.

3) Сила в автодополнениях


Вводить каждый раз четыре буквы host? Это же утомительно! Как правило, автодополнение парсит файлы ssh-конфига, достаточно начать писать хостнейм и нажать таб, чтобы имя хоста было дописано автоматически. Если этого не происходит, нужно баш этому научить.
Добавляем строчку
complete -W "$(echo `cat ~/.ssh/config | grep -iE '^(Host|HostName) ' | awk '{print $2}'`)" ssh

в файл ~/.bash_profile

Туда же можно дописать следующий код:
function __mysql_list_all_opts {
local i IFS=$'\n'
mysql --help|egrep '^ -'|awk '{print $1 "\n" $2}'|egrep '^-'|sed s/,$//|sort
}

__mysql_all_opts=
function __mysql_compute_all_opts {
: ${__mysql_all_opts:=$(__mysql_list_all_opts)}
}

function _mysql_complete {
local cur prev opts

COMPREPLY=()
cur=`_get_cword`
prev=${COMP_WORDS[COMP_CWORD-1]}

case $prev in
*)
if [[ "$cur" == -* ]]; then
__mysql_compute_all_opts
opts=${__mysql_all_opts}
else
opts=$(mysql -uroot -s -e 'show databases')
fi
;;
esac

COMP_WORDBREAKS=${COMP_WORDBREAKS//:}
COMPREPLY=( $(compgen -W "$opts" -- $cur) )
}

complete -F _mysql_complete mysql

Аналогично можно прописать и mysqldump

После того как мы откроем новую консоль bash у нас консоль будет дополнять имя удаленного компьютера и имя локальной базы!
Если у вас стоит пароль на подключение к базе нужно сделать следующий шаг.

4) Не вводим пароль для консольного мускуля


Каждый раз запуская консольный клиент mysql или mysqldump нужно не забывать передавать ему логин и пароль. Что бы этого избежать достаточно раз и навсегда создать файл ~/.my.cnf со следующим содержимым:
[client]
user = 'root'
password = 'password'

[mysql]
pager = less -iMSx4 -FX

Секцию mysqld добавлять по желанию. Она позволит вам не мучаться оптимальным подбором лимита, при работе с базой из командной строке. Если вывод длиннее чем количество строк на экране — вывод автоматически будет направлен в команду less. По которой можно удобно перемещаться вертикально и горизонтально и даже делать поиск!

5) Итоги:


Что бы получить дамп базы данных с удаленного сервера раньше приходилось выполнять серию компанд. В худшем случае (пример основан на реальных событиях):
localhost $ ssh -P 8022 user@hostname #идем на сервер
hostname $ ssh user2@computer #идем на удаленный комп
computer $ mysqldump -u root -p password long_database_name > ~/filename.sql
computer $ exit
hostname $ scp user2@computer:~/filename.sql ~/filename.sql
hostname $ ssh user2@computer
computer $ rm ~/filename.sql
computer $ exit
hostname $ exit
localhost $ scp -P 8022 user@hostname:~/filename.sql ~/filename.sql
localhost $ ssh -P 8022 user@hostname
hostname $ rm ~/filename.sql
hostname $ exit
localhost $ cat ~/filename.sql | mysql -u root -p password long_database_name
localhost $ rm ~/filename.sql #залили наконец, удаляем

Теперь вместо всего этого ужаса достаточно выполнить одну команду:
$ ssh computer mysqldump long_database_name | mysql long_database_name

В реальности и того меньше, т. к. перед каждой командой можно нажать таб:
ssh com[tab] mysqldu[tab] lon[tab] | mys[tab] lon[tab]

Нет желания слать файл в распакованном виде? Не беда, будем на лету паковать с той стороны в зип, а с этой — распаковывать.
$ ssh computer 'mysqldump long_database_name | gzip' | gunzip | mysql longdatabase_name

В качестве дополнительных плюшек получили возможность качать прямо с удаленного компьютера за натом файлы к себе, не пересохраняя их по дорге.
$ scp computer:~/test.txt ~/


Если тема сообществу покажется интересной — продолжу.
Могу рассказать про то как настроить iTerm под маком, что б работать с ssh было необыкновенно удобно
Про то как азы баш скриптинга могут сэкономить кучу времени при работе с командной строкой
Про плюсы команды screen и как ее удобно настроить
А так же про забытого дедушку z-modem и чем он может помочь современному разработчику в повседневной жизни.

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 66

    +1
    Расскажите как настроить iTerm под маком, что не пробовал — не комфортно.
      0
      Присоединяюсь к вопросу.
      • UFO just landed and posted this here
          +1
          С клавишами там беда, но не совсем — во всех MC замечательно работает замена F1-F9 через альт.
          Например, вместо F10 нажимаем Alt+0, F5 = Alt +5 b n/g/
            +1
            К сожалению немного хуже: Alt + Esc + 5, Alt + Esc + 9 и т.д.
            Сейчас работаю за линуксом, а тут немного не так.
              +2
              Не Alt, а Meta. А уж как Meta настроена конкретно на вашей системе — другой вопрос. Последовательный вариант с клавишей Esc или параллельный с клавишей Alt — наиболее распространённые варианты.

              Немного непонятно, зачем вы в следующем комменте F5 вводите как Alt+Esc+5 — достаточно вводить как Esc, 5 (с отпусканием Esc перед нажатием пятёрки). Или это специфика iTerm? В попадавшихся мне gnome-terminal, konsole, PuTTY и xterm Esc как Meta везде работала.
                0
                я же говорю, учусь от случая к случаю. (: Спасибо, буду знать
              0
              Для iTerm2, чтобы он вел себя так же, как линуксовый терминал, с хоткеями в mc, нужно зайти в настройки iTerm2 -> Profiles -> вкладка Keys и внизу отметить +Esc
              0
              В основе лежат две статьи о том как показывать на фоне картинку с именем сервера, на котором работаем и поставить приятные для глаза цвета. Кроме того автор предоставил свои файлы настроек для терминала, которые я себе поставил и практически не кастомизировал — и так все очень удобно.

                +1
                Поставить iTerm2, zsh и oh-my-zsh.
                +2
                А что не так?
                Я пользуюсь вполне успешно. Некоторые хоткеи mc не работают, но из меню вполне доступны.
                  +2
                  В последнее время предпочитаю iTerm 2 — производит намного лучшее впечатление.
                    0
                    Был на маке — пользовался Guake.
                      +1
                      славная рифма получилась
                    0
                    Да, и ещё пускай автор расскажет, как пропатчить KDE под FreeBSD.
                      0
                      А чем плох стандартный терминал?
                        +2
                        Поставить iTerm2?
                          0
                          попробуй iVisor
                          +1
                          Спасибо, открыл для себя много нового, особенно про .ssh/config.

                          От себя лишь добавлю совет: отключайте в конфигах на серверах вход по паролю, оставляйте только ключи (естественно перед отключением входа по паролю надо себе дать права sudo и закинуть свой ключ). Ключи только с passphrase (на всякий случай).

                          И еще.

                          Вводим (или не вводим) passphrase. Лучше все-таки вводить: система будет помнить ваш пароль от логина до логаута, то есть вводить постоянно этот пароль не нужно. Зато на порядок возрастет безопасность.

                          Passphrase — не пароль к учетной записи на сервере, а «пароль» к ключю rsa. Он используется для получения доступа к private сертификату (как-то сумбурно, но в общем так — поправьте если заблуждаюсь).
                            +1
                            > private сертификату

                            нет, таки к приватному ключу. В openssh сертификаты не применяются.
                              0
                              Прошу прощения, конечно ключ — я тут просто сертификат параллельно генерирую для https, вот и проскочило ненароком.
                            +2
                            Блин, неужели всё-таки придётся когда-то начать обучаться линуксу?..
                              +6
                              давно уже пора было обучиться
                                +24
                                Графический интерфейс суть от тебя глубинную скрывает. В bash-консоли силу истиную найдешь ты.
                                +7
                                Наиболее простой способ перенести ключ на сервер это выполнить у себя в консоли вот эту команду

                                man ssh-copy-id
                                  –1
                                  Да, но к сожалению работает не везде: под маком приходится делать вот такой вот трюк.
                                    0
                                    Не знал. Но по крайней мере те, у кого она работает, узнают о ней.
                                      +1
                                      А у меня под маком работает ssh-copy-id. А почему может не работать?
                                        0
                                        Потому что ее нет. И нужно отдельно поставить. Например так phildawson.tumblr.com/post/484798267/ssh-copy-id-in-mac-os-x
                                          0
                                          У меня она есть. Я просто думал у автора именно «не работает» и спросил почему она может не работать. Но ниже увидел его коммент, что он не знает как ее поставить и даже отписал более простой способ установки — через homebrew.
                                        0
                                        тогда стоит использовать scp
                                          0
                                          А если в ~/.ssh/authorized_keys уже есть чей-то ключ? scp его же заменит?
                                      +3
                                      Для переноса ключа на сервер можно использовать команду ssh-copy-id.
                                        +5
                                        А ещё стоит поставить zsh + oh-my-zsh, это если не охота разбираться в настройках. Работа в консоли станет гораздо удобнее. Ну и полазить по commandlinefu.com бывает полезно.
                                          +2
                                          Наиболее простой способ перенести ключ на сервер это выполнить у себя в консоли вот эту команду:
                                          $ ssh user@hostname «umask 077; cat >> .ssh/authorized_keys» < ~/.ssh/id_dsa.pub


                                          Для этого существует команда ssh-copy-id:
                                          $ssh-copy-id -i id_rsa.pub user@host
                                            0
                                            Да! Но она не работает под маком! :(
                                              +2
                                              brew install ssh-copy-id
                                                0
                                                Мешать брю с портами (если они стоят, что есть частое явление) — это не самое true решение. А в портах этого пакета нет.
                                              –1
                                              Она есть только в Linux, на маке ее нет, например.
                                                +1
                                                Можно поставить через homebrew.
                                                0
                                                macports же.
                                                +2
                                                > $ ssh user@hostname «umask 077; cat >> .ssh/authorized_keys» < ~/.ssh/id_dsa.pub

                                                Сегодня на одном сервере столкнулся с тем, что подобный финт не сработал. А всё потому, что в настройках sshd был указан другой путь к файлу с ключами:
                                                AuthorizedKeysFile .ssh_authorized/keys

                                                Ну а также необходимо убедиться, что авторизация по ключам вообще работает:
                                                PubkeyAuthentication yes
                                                  0
                                                  Сорри за оффтоп, но
                                                  Злой троянец увел у меня аккаунт на хабр, после чего под моим аккаунтом начали публиковаться какие-то тупые мультики.


                                                  Почему то вспомнился Softpatent, подумалось, что может одумались))
                                                    –1
                                                    ssh-copy-id для копирования ключей лучше всего подходит.
                                                      –1
                                                      >Лучше все-таки вводить: система будет помнить ваш пароль от логина до логаута, то есть вводить постоянно этот пароль не нужно.

                                                      чиво? это о чем написано?
                                                        0
                                                        автор забыл написать об ssh-add, а только намекнул на это :) Зря вообще-то, это был бы хороший совет, мне очень удобно.
                                                          0
                                                          и об ssh-agent, ага
                                                            0
                                                            Поделитесь, в чем плюсы ssh-agent? я так и не понял чем это может быть полезно
                                                              +1
                                                              а куда вы будете ваши ключи совать через ssh-add? в вакуум? :)
                                                        0
                                                        Касательно ssh-ключей, ситуация, на мой взглят, двоякая. Существует вероятность в какой–то момент просто остаться без доступа к серверам.

                                                        Была у нас как–то ситуация: админ компании сначала ушёл в отпуск, а после отпуска просто исчез. Дозвониться или как–то ещё выйти на контакт не удавалось. Все доступы к серверам на площадках были у него, а авторизовывался он там через ключи (грубо говоря, запускал в консоли скрипт типа connect some_server), чтобы не вводить постоянно пароли.

                                                        И вот исключительно благодаря этим ключам, отыскав пароль к его рабочей машине мы смогли от его имени войти на сервера и получить к ним полный доступ. С одной стороны, это, конечно, было хорошо для нас, а вот с другой — огромная дыра в безопасности.

                                                        Я за хранение паролей в зашифрованном менеджере паролей и за ввод их каждый раз при авторизации.
                                                          +1
                                                          ссш-ключ можно защитить парольной фразой и вводить её один раз в начале сеанса — это достаточно разумный компромисс, на мой взгляд.
                                                            0
                                                            Вот для этого и нужно вводить passphrase — если вы включите компьютер и попробуете зайти на удаленный сервер у вас спросят этот пароль. После того как пароль будет дан компьютер вас запомнит… до тех пор пока вы не выйдете из системы. Та же идеология что и с менеджером паролей, только пароли к серверам вы не вытаскиваете, не храните и меньше шанс что потеряете/покажете где не надо.
                                                              +1
                                                              Т.е. один пароль меняем на другой, только называем его passphrase? :)
                                                                0
                                                                нет: вместо кучи чужих паролей (к хостингам, которые нельзя сменить, к серверам которыми пользуются многие люди) мы используем ключи. Что бы защитить этот ключ генерируем свой пароль, его-то и нужно запомнить. Это ваш универсальный пароль для доступа к любому серверу, удобно же!
                                                              0
                                                              а вот если бы вы не смогли получить доступ к его машине?
                                                                0
                                                                Ну, при физическом доступе к серверу, вроде как, можно получить над ним управление (точно сказать не могу, не моя епархия), так что отправили бы свеженанятого админа в датацентр разбираться в ситуации и решать проблемы. :)
                                                                  0
                                                                  необязательно отправлять админа куда-то. Админу достаточно попросить об этом у службы поддержки датацентра. Но в целом мысль верная :)
                                                                  0
                                                                  KVM и сброс рута
                                                                +2
                                                                Ещё иногда удобно «пробросить порт» через ssh:
                                                                # ssh user@remoute_host -L<local_port>:<local_host>:<remoute_port>
                                                                  +1
                                                                  Точнее сказать
                                                                  ssh user@remote -L [<local_host>:]<local_port>:<remote_host>:<remote_port>
                                                                  

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

                                                                  Ещё полезна обратная фича
                                                                  ssh user@remote -R [<local_host>:]<local_port>:<remote_host>:<remote_port>
                                                                  

                                                                  которая даст доступ с <remote_host>:<remote_port> к <local_host>:<local_port>.

                                                                  Следует также упомянуть полезные ключи -N и -f. Первый указывает, что на удаленной стороне не нужно ничего выполнять, второй отправляет в бэкграунд. Удобна их комбинация, если надо только пробросить порт.
                                                                  +1
                                                                  Да, статья отличная. Очень хочется продолжения в том же духе…
                                                                    +1
                                                                    Хотел вот это (и еще ряд фиксов) прислать личным сообщением:
                                                                    Как правило, автодополнение парсит файлы ssh-конфига, достаточно начать писать хостнейм и нажать таб, чтобы имя хоста было дописано автоматически. Если этого не происходит, нужно баш этому научить.

                                                                    … но форма почему-то не валидируется, якобы не указан получатель (хотя он указан). Так что придется чуть-чуть запакостить тред.

                                                                    (Вообще, жаль, что на хабре до сих пор нет вики-режима, как на StackOverflow и К°. Было бы несравнимо проще и читать, и помогать другим в подготовке более читабельного текста.)
                                                                      +1
                                                                      спасибо, исправил
                                                                      0
                                                                      а вообще много неплохих советов. Сам я до большинства сам дошёл разными путями с одним отличием — у меня tcsh, а не bash :)
                                                                      Кстати, автодополнение хостов полезно настроить не только для команды ssh, но также для sftp и scp.
                                                                      Отдельно хотелось бы запросить рассказ про ssh-agent. Сам я настроил такое в XFCE, однако в Гноме было прикольнее, там парольная фраза хранилась в брелке сеанса, то есть её вообще надо было сохранить всего один раз.
                                                                        0
                                                                        Еще классная штука — forced commands. Прописываем в ключах текст вроде: command="/home/remoteuser/cron/validate-rsync" (перед ключом, напр перед текстом ssh-dss .....) и удаленный пользователь автоматически будет делать эту команду.

                                                                        Например, простенький веб-интерфейс (даже на другой машине) сможет коннектится на нужный сервер и добавлять-удалять правило на файрволе или ребутить машину или рестартовать апач итд, в общем — делать некоторые нужные операции, которые требуют рута. Но даже если эту машинку поломают и ключик уведут — зайти с ним на систему и сделать rm -rf не получится — только /etc/init.d/apache restart.
                                                                          0
                                                                          Если компьютеров за NAT'ом огромное количество и каждый день подключаешься к разным, редко когда два дня подключаешься к одному и тому же — можно ли как-то пробросить в ProxyCommand и пароль к target computer?

                                                                          Only users with full accounts can post comments. Log in, please.