Решил сделать подборку консольных команд по загрузке и выгрузке файлов. Постоянно приходится этим пользоваться. И если с загрузкой всё довольно просто, то выгрузку приходится вспоминать, как сделать, так как редко нужно.
Скачать файл под своим именем:
Скачать и сохранить с заданным именем:
Для curl я обычно применяю пару дополнительных ключей:
И у wget, и у curl есть одинаковая опция по ограничению скорости загрузки через ключ
Скачать скрипт и сразу запустить его 😱:
Автоматическая установка докера. Я постоянно пользуюсь.
Для аутентификации в curl достаточно через ключ
Скачать набор файлов из текстового списка, где каждая строка это отдельная ссылка:
Если добавить ключ
Скачать целиком сайт. Работает нормально, сам проверял несколько раз, скачивая некоторые сайты:
7 — глубина вложенности страниц от указанной, можно сделать меньше или больше в зависимости от сайта, чтобы не качать уже мусорные ссылки.
Скачать файл с ssh сервера через scp:
Запрос пароля появится в консоли. Можно его сразу указать, только имейте ввиду, что пароль останется в history:
И то же самое, только с ключом:
Скачать файл по ftp:
Скачать файл по smb:
Выгрузка (загрузка на сервер) файлов по ftp, ssh, smb:
Причём можно сразу загрузить группу файлов с именами, которые можно задать по стандартной маске в bash:
#bash #terminal #curl
Скачать файл под своим именем:
curl -O https://site.com/file.tar.gzwget https://site.com/file.tar.gzСкачать и сохранить с заданным именем:
curl -o file_new.tar.gz https://site.com/file.tar.gzwget -O file_new.tar.gz https://site.com/file.tar.gzДля curl я обычно применяю пару дополнительных ключей:
-s — режим silent, отключает вывод служебной информации, актуально для скриптов;-k — игнорирует ошибки TLS, например, с недоверенным сертификатом.И у wget, и у curl есть одинаковая опция по ограничению скорости загрузки через ключ
--limit-rate 10M. Суффиксы k, M, G обозначают килобайты, мегабайты, гигабайты.Скачать скрипт и сразу запустить его 😱:
curl -sSL https://get.docker.com/ | shАвтоматическая установка докера. Я постоянно пользуюсь.
Для аутентификации в curl достаточно через ключ
-u добавить имя пользователя и пароль. Работает как с basic auth, так и с kerberos, ntlm. Для кербероса надо только не забыть домен добавить к имени пользователя. curl -O -u user:password https://site.com/file.tar.gzСкачать набор файлов из текстового списка, где каждая строка это отдельная ссылка:
wget –I urls.txtЕсли добавить ключ
-b, то скачивание будет идти в фоновом режиме. Актуально, когда качаешь по списку набор iso. Это может долго длиться.Скачать целиком сайт. Работает нормально, сам проверял несколько раз, скачивая некоторые сайты:
wget -r -k -l 7 -p -E -nc http://site.ru/7 — глубина вложенности страниц от указанной, можно сделать меньше или больше в зависимости от сайта, чтобы не качать уже мусорные ссылки.
Скачать файл с ssh сервера через scp:
curl -O -k -u user scp://192.168.1.1:22/data/file.tar.gzЗапрос пароля появится в консоли. Можно его сразу указать, только имейте ввиду, что пароль останется в history:
curl -O -k -u user:password scp://192.168.1.1:22/data/file.tar.gzИ то же самое, только с ключом:
curl -O -k -u user --key ~/.ssh/id_rsa scp://192.168.1.1:22/data/file.tar.gzСкачать файл по ftp:
curl -O ftp://user:password@ftpserver.ru/data/file.tar.gzСкачать файл по smb:
curl -O -u "domain\user:password" smb://server.local/share/file.tar.gzВыгрузка (загрузка на сервер) файлов по ftp, ssh, smb:
curl -T file.tar.gz -u user:password ftp://ftpserver.ru/data/curl -k -T file.tar.gz -u user scp://ftpserver.ru/data/curl -k -T file.tar.gz -u user --key ~/.ssh/id_rsa scp://ftpserver.ru/data/curl -T file.tar.gz -u "domain\user:password" smb://server.local/share/Причём можно сразу загрузить группу файлов с именами, которые можно задать по стандартной маске в bash:
curl -T "file[1-100].tar.gz" ftp://ftpserver.ru/data/#bash #terminal #curl
Расскажу про простой и быстрый способ увидеть лог smtp сессии при обращении к какому-то почтовому серверу. Как вы уже знаете из прошлой заметки про curl, она умеет работать с различными протоколами. В том числе и с smtp.
В общем случае самый эффективный способ поговорить с smtp сервером, это обратиться к нему на 25 порт телнетом. И надавать ему туда своих команд. Примеров в сети много. Но это долго и не всегда нужно. Можно воспользоваться curl:
Содержимое email.txt примерно такое:
В консоли будете наблюдать лог smtp сессии. Если что-то не так, увидите ошибку.
Я вспомнил про curl, потому что один сервер мониторинга Zabbix никак не хотел отправлять почту через конкретный локальный почтовый сервер. Все другие клиенты с ним нормально работают, а Zabbix никак. При этом сам Zabbix сервер с другими почтовыми серверами тоже нормально работал.
Мне захотелось разобраться в проблеме, поэтому погрузился в тематику. Выяснил, что Zabbix отправляет почту через curl. Со стороны почтового сервера было не очень понятно, в чём конкретно проблема, он просто ругался на неправильную аутентификацию. Немного поигрался в консоли с curl и понял, в чём проблема.
Curl почему-то по умолчанию предлагает аутентификацию DIGEST-MD5 и она по какой-то причине происходит с ошибкой. По идее, клиент дальше должен пробовать другие методы, но конкретно в этой ситуации curl получал ошибку аутентификации и больше никаких попыток не делал. Дело было на сервере Centos 7, где curl очень старой версии. В сети нашёл информацию, что на нём реально могут быть проблемы с аутентификацией. Обновил утилиту до последней версии, но мне это не помогло.
Дальше разбираться не стал. Слишком много времени ушло, а проблема не критичная. Обошёл её, сделав исключение для конкретного IP адреса.
Вот эта же проблема, описанная на форуме Zabbix, а вот предложенное решение по обновлению curl на centos 7, которое мне не помогло.
#linux #curl #zabbix
В общем случае самый эффективный способ поговорить с smtp сервером, это обратиться к нему на 25 порт телнетом. И надавать ему туда своих команд. Примеров в сети много. Но это долго и не всегда нужно. Можно воспользоваться curl:
# curl smtp://mail.site.ru:25 -v \--mail-from sysadmin@site.ru \--mail-rcpt sysadmin@site.ru \--user 'sysadmin@site.ru:password' \--upload-file ~/email.txtСодержимое email.txt примерно такое:
From: sysadmin@site.ruTo: sysadmin@site.ruSubject: test emailDate: Mon, 17 Apr 2023 00:17:16Dear Sysadmin,Welcome to this test email. What a lovely day.В консоли будете наблюдать лог smtp сессии. Если что-то не так, увидите ошибку.
Я вспомнил про curl, потому что один сервер мониторинга Zabbix никак не хотел отправлять почту через конкретный локальный почтовый сервер. Все другие клиенты с ним нормально работают, а Zabbix никак. При этом сам Zabbix сервер с другими почтовыми серверами тоже нормально работал.
Мне захотелось разобраться в проблеме, поэтому погрузился в тематику. Выяснил, что Zabbix отправляет почту через curl. Со стороны почтового сервера было не очень понятно, в чём конкретно проблема, он просто ругался на неправильную аутентификацию. Немного поигрался в консоли с curl и понял, в чём проблема.
Curl почему-то по умолчанию предлагает аутентификацию DIGEST-MD5 и она по какой-то причине происходит с ошибкой. По идее, клиент дальше должен пробовать другие методы, но конкретно в этой ситуации curl получал ошибку аутентификации и больше никаких попыток не делал. Дело было на сервере Centos 7, где curl очень старой версии. В сети нашёл информацию, что на нём реально могут быть проблемы с аутентификацией. Обновил утилиту до последней версии, но мне это не помогло.
Дальше разбираться не стал. Слишком много времени ушло, а проблема не критичная. Обошёл её, сделав исключение для конкретного IP адреса.
Вот эта же проблема, описанная на форуме Zabbix, а вот предложенное решение по обновлению curl на centos 7, которое мне не помогло.
#linux #curl #zabbix
Думаю те, кто используют curl в консоли, не раз сталкивались с тем, что не получается что-то скачать через эту утилиту. Копируешь ссылку из браузера, отдаёшь curl, но в итоге грузится либо какая-то заглушка, либо вообще ничего не грузится.
Это возникает из-за того, что утилиту curl легко распознать и заблокировать с её помощью загрузку. Делают это скорее всего для того, чтобы отвадить ботов и другие системы автоматизации, которые используют эту утилиту. Для того, чтобы обходить это ограничение, существует проект curl-impersonate.
Авторы подготовили специальную сборку curl, которая максимально похожа на обычные браузеры: Chrome, Edge, Safari или Firefox. Авторы считают, что чаще всего curl определяется на этапе TLS handshake. Для того, чтобы обойти эти проверки, они собирают curl с TLS библиотеками, которые используют браузеры, а не OpenSSL, как у обычной curl. Также по умолчанию используются шифры и заголовки, такие же, как у браузеров.
Для каждого браузера есть свой набор параметров, поэтому загрузка с помощью модифицированного curl выглядит примерно так:
Под каждый браузер своя сборка.
Для использования достаточно загрузить подготовленные бинарники из репозитория: https://github.com/lwthiker/curl-impersonate/releases. На стандартном Debian 11 мне больше ничего не пришлось делать. В репе авторы указывают, что нужны некоторые пакеты:
У меня они уже стояли. Есть и Docker образы.
Проект интересный и полезный. Модифицированную версию curl имеет смысл использовать для мониторинга, если у вас есть возможность выбирать бинарник. Мониторинг будет более достоверен и максимально приближен к реальным браузерам, насколько это возможно для консольной утилиты.
⇨ Исходники
#curl #terminal #linux
Это возникает из-за того, что утилиту curl легко распознать и заблокировать с её помощью загрузку. Делают это скорее всего для того, чтобы отвадить ботов и другие системы автоматизации, которые используют эту утилиту. Для того, чтобы обходить это ограничение, существует проект curl-impersonate.
Авторы подготовили специальную сборку curl, которая максимально похожа на обычные браузеры: Chrome, Edge, Safari или Firefox. Авторы считают, что чаще всего curl определяется на этапе TLS handshake. Для того, чтобы обойти эти проверки, они собирают curl с TLS библиотеками, которые используют браузеры, а не OpenSSL, как у обычной curl. Также по умолчанию используются шифры и заголовки, такие же, как у браузеров.
Для каждого браузера есть свой набор параметров, поэтому загрузка с помощью модифицированного curl выглядит примерно так:
# curl_chrome110 https://www.wikipedia.orgПод каждый браузер своя сборка.
Для использования достаточно загрузить подготовленные бинарники из репозитория: https://github.com/lwthiker/curl-impersonate/releases. На стандартном Debian 11 мне больше ничего не пришлось делать. В репе авторы указывают, что нужны некоторые пакеты:
# apt install libnss3 nss-plugin-pem ca-certificatesУ меня они уже стояли. Есть и Docker образы.
Проект интересный и полезный. Модифицированную версию curl имеет смысл использовать для мониторинга, если у вас есть возможность выбирать бинарник. Мониторинг будет более достоверен и максимально приближен к реальным браузерам, насколько это возможно для консольной утилиты.
⇨ Исходники
#curl #terminal #linux
Вы знали, что curl умеет отправлять почту через внешние smtp серверы? Я в целом знаю, что curl умеет всё, что только можно придумать про передачу данных, но конкретно вопрос не прорабатывал, хотя вскользь уже упоминал об этом, но в рамках решения другой задачи, поэтому особо не погружался в тему. Поэтому для отправки почты из консоли всё время ставлю какую-то дополнительную утилиту, типа mailx. На самом деле это не обязательно. Сейчас покажу, как отправлять почту через curl, не светя пароль в консоли.
Сразу ссылка на документацию. Оправляем почту полностью через ключи curl:
Содержимое mail.txt примерно следующее:
Причём с помощью curl очень удобно управлять адресом отправителя. В mail.txt его любой указать можно, а не тот, от которого идёт отправка. Впрочем, как и другие заголовки.
Не очень хорошая идея светить почтовый пароль в консоли. Можно его спрятать в
Каждый сервер на новой строке. Удобно, если используется отправка через несколько разных серверов. В соответствии с указанным smtp сервером берутся настройки учётной записи из файла
Так как мы используем ключ
Если используется шифрованное соединение и порт 465, то достаточно просто указать адрес сервера в виде
Для того, чтобы явно указать HELO / EHLO при отправке, добавьте его через слеш после адреса сервера. Примерно так:
#terminal #curl
Сразу ссылка на документацию. Оправляем почту полностью через ключи curl:
# curl -v --url "smtp://mail.server.ru:25" --mail-from "root@server.ru" --mail-rcpt "user@gmail.com" --user 'root@server.ru:password123' --upload-file ~/mail.txtСодержимое mail.txt примерно следующее:
From: "Vladimir" <root@server.ru>To: "User" <user@gmail.com>Subject: Mail from curlHello! How are you?Причём с помощью curl очень удобно управлять адресом отправителя. В mail.txt его любой указать можно, а не тот, от которого идёт отправка. Впрочем, как и другие заголовки.
Не очень хорошая идея светить почтовый пароль в консоли. Можно его спрятать в
.netrc файл. Для этого его надо создать в домашней директории пользователя ~/.netrc. Содержание такое:machine mail.server.ru login root@server.ru password password123machine mail.server02.ru login user@server02.ru password password12345Каждый сервер на новой строке. Удобно, если используется отправка через несколько разных серверов. В соответствии с указанным smtp сервером берутся настройки учётной записи из файла
.netrc. Команда на отправку с использованием .netrc будет такая:# curl -v --url "smtp://mail.server.ru:25" --mail-from "root@server.ru" --mail-rcpt "user@gmail.com" --netrc --upload-file ~/mail.txtТак как мы используем ключ
-v, в консоли видим весь лог общения с почтовым сервером, что может быть удобно для отладки. Если не указывать никаких ключей для TLS, то будет использоваться нешифрованное соединение. Если нужно только шифрованное, то можно добавить ключ --ssl-reqd, а если хотите чтобы при поддержке сервером шифрование использовалось, а если поддержки нет, то нет, тогда добавьте ключ --ssl. Если используется шифрованное соединение и порт 465, то достаточно просто указать адрес сервера в виде
smtps://mail.server.ru. Отдельно указывать порт и ключи для ssl не обязательно. Для того, чтобы явно указать HELO / EHLO при отправке, добавьте его через слеш после адреса сервера. Примерно так:
smtp://mail.server.ru/client_helo.server.ru#terminal #curl
Когда готовил материал по отправке email сообщений через curl, подумал, он же наверное и читать умеет. И не ошибся. Curl реально умеет читать, и не только, почту по imap. Это открывает очень широкие возможности по мониторингу почтовых серверов с помощью утилиты.
Меня не раз спрашивали, как удобнее всего настроить мониторинг почтовых сообщений в ящике, чтобы приходили уведомления при получении письма определённого содержания. Я обычно советовал либо на самом почтовом сервере прямо в ящике анализировать текст писем, если это возможно. Либо использовать какие-то программы типа fetchmail, imapsync или обычные почтовые клиенты. И уже в них как-то анализировать письма.
Но с curl всё получается намного проще. Она много чего умеет. Расскажу по порядку. Сразу важная сноска, которая сильно затормозила меня в этом вопросе. Когда будете пробовать, возьмите свежую версию curl. Более старые некоторые команды для imap не поддерживают. Я сначала наткнулся на это в старом сервере Centos 7. Потом уже перешёл на современный Debian и там всё получилось.
Сразу перенесём логин с паролем в отдельный файл
Проверяем количество сообщений в imap папке INBOX:
Получили число 405. Посмотрим, сколько из них непрочитанных:
147 непрочитанных сообщений. Думаю, идею вы поняли. С помощью curl можно напрямую передавать серверу команды imap.
Смотрим список директорий в ящике:
Или просто:
Ищем в ящике письма с темой test:
или так:
Сообщения от определённого адресата:
Получили UIDs писем. Смотрим содержание письма с конкретным UID. Для этого надо добавить ключ
или так:
И так далее. Письмо после проверки можно пометить прочтённым, переместить в другую директорию, удалить. Чтобы осмысленно дёргать imap сервер, достаточно посмотреть описание протокола. Информация по нему легко находится в поиске.
Команды imap рассмотрены в упоминаемом недавно курсе по сетям от Созыкина Андрея. Вот конкретный урок: ▶️ Протокол IMAP. Вообще, было интересно во всём этом разобраться. Если надо будет настроить мониторинг очередного почтового сервера, попробую что-то применить с помощью curl.
Первое, что приходит в голову в плане мониторинга - отправлять письмо с меткой времени в теле, а потом забирать его и анализировать эту метку. Если метка старая, значит письма не ходят. Это надёжнее, чем просто проверять статус служб и доступность портов. Тут и smtp, и imap сервер проверяются. И реализуется полностью с помощью curl и zabbix.
#curl #terminal
Меня не раз спрашивали, как удобнее всего настроить мониторинг почтовых сообщений в ящике, чтобы приходили уведомления при получении письма определённого содержания. Я обычно советовал либо на самом почтовом сервере прямо в ящике анализировать текст писем, если это возможно. Либо использовать какие-то программы типа fetchmail, imapsync или обычные почтовые клиенты. И уже в них как-то анализировать письма.
Но с curl всё получается намного проще. Она много чего умеет. Расскажу по порядку. Сразу важная сноска, которая сильно затормозила меня в этом вопросе. Когда будете пробовать, возьмите свежую версию curl. Более старые некоторые команды для imap не поддерживают. Я сначала наткнулся на это в старом сервере Centos 7. Потом уже перешёл на современный Debian и там всё получилось.
Сразу перенесём логин с паролем в отдельный файл
~/.netrc:machine mail.server.tld login username password supersecretpwПроверяем количество сообщений в imap папке INBOX:
# curl "imap:/mail.server.tld" -n -X 'STATUS INBOX (MESSAGES)'* STATUS INBOX (MESSAGES 405)Получили число 405. Посмотрим, сколько из них непрочитанных:
# curl "imap://mail.server.tld" -n -X 'STATUS INBOX (UNSEEN)'* STATUS INBOX (UNSEEN 147)147 непрочитанных сообщений. Думаю, идею вы поняли. С помощью curl можно напрямую передавать серверу команды imap.
Смотрим список директорий в ящике:
# curl "imap://mail.server.tld" -n -X 'LIST "" "*"'* LIST (\HasNoChildren \Marked \Trash) "/" Trash* LIST (\HasNoChildren \UnMarked \Junk) "/" Junk* LIST (\HasNoChildren \UnMarked \Drafts) "/" Drafts* LIST (\HasNoChildren \Sent) "/" Sent* LIST (\HasChildren) "/" INBOXИли просто:
# curl "imap://mail.server.tld" -nИщем в ящике письма с темой test:
# curl "imap://mail.server.tld/INBOX?SUBJECT%20test" -n* SEARCH 62 404 405 406или так:
# curl "imap://mail.server.tld/INBOX" -n -X 'SEARCH HEADER Subject test'Сообщения от определённого адресата:
# curl "imap://mail.server.tld/INBOX" -n -X 'SEARCH From vladimir@zeroxzed.ru'* SEARCH 292 404 405 406Получили UIDs писем. Смотрим содержание письма с конкретным UID. Для этого надо добавить ключ
-v, так как оно передаётся в отладочной информации, как и все остальные ответы сервера:# curl -v "imap://mail.server.tld/INBOX" -n -X 'FETCH 406 BODY[TEXT]'или так:
# curl -v "imap://mail.server.tld/INBOX;UID=406/;BODY=TEXT" -nИ так далее. Письмо после проверки можно пометить прочтённым, переместить в другую директорию, удалить. Чтобы осмысленно дёргать imap сервер, достаточно посмотреть описание протокола. Информация по нему легко находится в поиске.
Команды imap рассмотрены в упоминаемом недавно курсе по сетям от Созыкина Андрея. Вот конкретный урок: ▶️ Протокол IMAP. Вообще, было интересно во всём этом разобраться. Если надо будет настроить мониторинг очередного почтового сервера, попробую что-то применить с помощью curl.
Первое, что приходит в голову в плане мониторинга - отправлять письмо с меткой времени в теле, а потом забирать его и анализировать эту метку. Если метка старая, значит письма не ходят. Это надёжнее, чем просто проверять статус служб и доступность портов. Тут и smtp, и imap сервер проверяются. И реализуется полностью с помощью curl и zabbix.
#curl #terminal
