Laravel по-русски

Alex_php +1

Сообщений: 8

Куда класть дамп базы?

Привет всем. Я когда просто на php делал сайт, то прям в корне проекта создавал папку dump и туда складывал БД. Для этого я просто делал экспорт базы используя phpMyAdmin.

Сейчас я делаю проект на Ларавел 5.1. Там в корне есть папка database, а в ней папки с сидами и миграции. Вот тут внутри database я создал папку dump и сюда положил дамп базы.

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

DBR +17

Сообщений: 168

Re: Куда класть дамп базы?

Если папка не должна быть под контролем гита, то в storage. Иначе куда тебе удобно.

Для каких целей ты куда-то кладешь дамп базы?

Alex_php +1

Сообщений: 8

Re: Куда класть дамп базы?

}%Для каких целей ты куда-то кладешь дамп базы?

Ну это вроде как резервная копия у меня. Ну и еще когда сайт на хостинг переносить буду, то мне там на хостинге надо будет зайти в phpMyAdmin и сделать Импорт базы данных. Поэтому  я и делаю дамп бд

Proger_XP +345

Топ 30%

Мастер

Сообщений: 1,312

Статей: 33

Re: Куда класть дамп базы?

Не особо она резервная — от удаления папки проекта не спасёт, от потери хостинга/сервера тоже и т.д.

Лучше для этого загружать дамп на FTP (многие хостеры предоставляют сколько-то там места под бекапы бесплатно), либо хотя бы на другом диске на этом же сервере.

Главное никогда не держать дампы в корне сайта (public), а то видел я сайты, где всю БД можно было скачать через http://example.com/dump.sql или /backup.tar…

Это же разовая операция, дамп можно и с локальной системы загрузить.

constb +141

Мастер

Сообщений: 624

Re: Куда класть дамп базы?

Ну это вроде как резервная копия у меня. Ну и еще когда сайт на хостинг переносить буду, то мне там на хостинге надо будет зайти в phpMyAdmin и сделать Импорт базы данных. Поэтому  я и делаю дамп бд

добавлю что если есть доступ по ssh можно лить из базы в базу напрямую – сдампить локально, тут же пропустить через gzip и завернуть в ssh а на той стороне разгзиповать и сразу залить на вход в mysql.

по шагам:

1) настроить подключение к mysql локально чтобы mysqldump не просил пароля – создать в папке пользователя .my.cnf с содержимым

[client]
host=localhost
user=dbuser
password=secret

права на файл должны быть 0600 – незачем кому попало палить твои пароли. проверить подключение запустив mysql dbname – если появился prompt значит всё ок (выход из него – \q если что)

2) аналогичным образом настроить подключение без пароля для mysql на удалённом сервере – создать .my.cnf там с доступами к удалённой базе, установить права и проверить подключение

3) проверить что mysqldump дампит локальную базу –  mysqldump --opt  > dump.sql

4) проверить что ssh подключается и запускает команды на удалённой стороне – ssh user@remotehost.com 'mysql dbname' – он может запросить пароль, если не настроена авторизация по ключу

5) когда всё работает, переливаем базу:

mysqldump --opt dbname | gzip | ssh user@remotehost.com 'zcat | mysql dbname'

повторить перелив столько раз сколько нужно

ps. на некоторых системах zcat может называться gzcat
pps. если настроить ssh по ключу – не надо будет каждый раз вводить пароль про подключении

Proger_XP +345

Топ 30%

Мастер

Сообщений: 1,312

Статей: 33

Re: Куда класть дамп базы?

Раз уж зашёл разговор про ssh, то внесу свои пять копеек:

1. Просто для импорта не обязательно и скорее даже не желательно указывать пароль в конфиге MySQL — пароль (логин, имя и всё прочее) можно передать через параметры.
2. Авторизацию по ключу тоже можно сделать через командную строку ключом -i и не трогать конфиг ssh.
3. Вместо явного вызова gzip можно/лучше использовать встроенное сжатие в ssh (тот же gzip) ключом -C.
4. Надо учесть, что в зависимости от сервера сжатие может наоборот понизить скорость передачи, так как если канал широкий (даже стандартный 100 Мбит/с), то будет большая нагрузка на ЦП и он может тормозить передачу.
5. Выйти из mysql можно ещё по Ctrl+D (выйти из ssh — тоже).
6. ssh-туннель не нужен, если к MySQL можно подключиться по сети (а не только локально). В этом случае лучше всего настроить сертификаты (параметры ssl_…), чтобы соединение до БД было зашифрованным.

С туннелем (-A — все базы и таблицы):

shmysqldump -A -uroot -pPASSWORD | ssh -i id_rsa -C root@HOST "mysql -uroot -pPASSWORD"

Ключ можно сгенерировать через shssh-keygen -f id_rsa, это создаст id_rsa и id_rsa.pub; последний нужно скопировать в /root/.ssh/authorized_keys на конечном сервере.

Без туннеля:

shmysqldump -A -uroot -pPASSWORD | mysql -hHOST -uroot -pPASSWORD --ssl-...

В обоих случаях можно смотреть за скоростью передачи, если после mysqldump поставить pv (ей же можно ограничить скорость передачи ключом -L):

shmysqldump -A ... | pv -L1M | ... (дальше ssh или mysql)

constb +141

Мастер

Сообщений: 624

Re: Куда класть дамп базы?

Просто для импорта не обязательно и скорее даже не желательно указывать пароль в конфиге MySQL — пароль (логин, имя и всё прочее) можно передать через параметры.

как раз никогда так не делаю. не раз приходилось находить пароли в .bash_history там правда были ситуации когда у заказчика у самого едва есть хоть какие-то доступы от предыдущего работника. тем не менее, хранить их в ~/.my.cnf как-то надёжнее – точно знаешь где что лежит с какими правами доступа. и если кому-то передаёшь проект – сразу получается передаёшь его с доступами

о том чтобы на 100 мбит gzip съел ядро целиком что-то не видел такого. по-моему только на старом железе или виртуалках с сильно ограниченным бюджетом на cpu такое возможно. особенно учитывая что распаковка гораздо проще в плане ресурсов.

в остальном конечно вкусовщина и зависит от того в какой среде работаешь

Авторизацию по ключу тоже можно сделать через командную строку ключом -i и не трогать конфиг ssh.

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

Вместо явного вызова gzip можно/лучше использовать встроенное сжатие в ssh (тот же gzip) ключом -C.

напротив с gzip-ом вручную можно выбрать степень компрессии, -C по-моему такого не позволяет

Выйти из mysql можно ещё по Ctrl+D (выйти из ssh — тоже).

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

ssh-туннель не нужен, если к MySQL можно подключиться по сети (а не только локально). В этом случае лучше всего настроить сертификаты (параметры ssl_…), чтобы соединение до БД было зашифрованным.

для туннелей у меня тоже есть специальная софтина никогда не настраивал ssl-соединение к базе напрямую, вообще стараюсь сводить к минимуму количество открытых портов на сервере. 22, 80, 443 – и пожалуй хватит. а то бывает некоторые догадываются то мемкэш на улицу выставить, то редис, а потом удивляются когда их ломают. с mysql вроде удалённых эксплойтов в последнее время не было, но чем чёрт не шутит

С туннелем (-A — все базы и таблицы)

на всякий случай уточню – только на идентичных версиях mysql локальной и удалённой! в выгрузку включаются системные таблицы самой mysql а они могут отличаться по структуре. аккаунты пользователей удалённой базы в этом случае тоже будут перезаписаны.

В обоих случаях можно смотреть за скоростью передачи, если после mysqldump поставить pv (ей же можно ограничить скорость передачи ключом -L)

откуда pv взять? у меня что-то её нет…

Proger_XP +345

Топ 30%

Мастер

Сообщений: 1,312

Статей: 33

Re: Куда класть дамп базы?

Если у кого-то есть доступ к .bash_history (который по умолчанию имеет права 0600), то есть большой шанс, что имеем дело с root’ом и в таком случае вытащить пароли напрямую из MySQL (или сбросить их) не составляет труда.

С передачей паролей в командной строке гораздо большая проблема это их отображение в чистом виде в списке процессов (ps -ef). С другой стороны, большая часть серверов, особено всякие VPS, имеют одного логического пользователя — root’а, и одного физического (т.е. только админ ходит на этот сервер). Здесь нет смысла скрывать пароль ни в ps, ни в истории.

На заметку. С MySQL 5.7 появилась возможность задавать login path («путь входа»), что заменяет старый и не очень безопасный способ с паролем в конфиге. В login path можно сохранить пароль и другие параметры входа (БД. хост и прочее), причём пароль шифруется. А дальше можно войти под этими настройками просто через shmysql --login-path=FOOBAR.

Доступы лучше всего передавать явно, чтобы они были записаны где-то ещё. Иначе будет как у большинства пользователей, когда они меняют браузер/ОС/компьютер — "ой, а где мои пароли? я их все сохраняла в браузере, где мой браузер??". То есть чтобы после переезда/переустановки ОС не обнаружить, что половина доступов потерялась, так как лежала не пойми где в неявном виде.

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

Виртуалки на 400 МГц вполне существуют. Также, на некоторых есть правило в договоре на запрет использования всей мощности в течении длительного времени — то есть ненадолго 3 ГГц тебе можно взять (на всплеск посетителей), но если ты используешь слишком много ресурсов слишком долго — их тебе обрезают и мягко намекают, что пора бы перейти на другой тариф.

Хотя в целом gzip требует самый минимум ресурсов.

Скорость передачи зависит от обоих сторон — и от пакующей/передающей, и от принимающей/распаковывающей.

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

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

Если у тебя один ключ на всё, то даже не обязательно использовать -i или добавлять ключ на сервер явно. В случае, если ты с этого сервера выходишь на другие сервера, нужно использовать «сквозной ключ» (agent forwarding). Если ты на Windows, то наверняка пользуешься putty — там есть небольшая программка pageant, в неё добавляешь все ключи, которые у тебя есть; она висит в трее. Для *nix есть аналог (ssh-agent).

Дальше, когда ты подключаешься к хосту, то ты не указываешь ни ключ, ни пароль. Если агент запущен, то ssh возьмёт ключ оттуда сам. И даже больше — если ты потом с этого (удалённого) хоста подключаешься ещё дальше (то есть ты > хост > новый хост), то и там авторизация будет взята из твоего локального агента. Таким образом, ключи вообще никуда не копируются, а берутся с локальной системы.

Для выбора уровня есть -o CompressionLevel=9. Но обычно изменение уровня сжатия отражается на размере меньше, чем на 10%, а вот использование ЦП сильно растёт. Разумнее всего выбирать самый низкий уровень (1). По умолчанию, насколько я помню, уровень 6, что тоже нормально.

Это правильно, но всегда можно ограничить, кто может подключаться к порту. MySQL подволяет это сделать на уровне авторизации (т.е. хост + имя пользователя + пароль), хотя да, она работает внутри MySQL и поэтому есть вероятность схватит эксплоит.

Лучше всего iptables:

iptables -A INPUT -p tcp --dport 3309 -s 1.2.3.4 -j ACCEPT

Это открывает доступ к 3309 только для 1.2.3.4. Но нужно либо выставить для INPUT политику DROP/REJECT, либо после правила добавить:

iptables -A INPUT -p tcp --dport 3309 -j REJECT

Правда, это уже дебри и лучше MySQL не выставлять в мир, а то можно ведь прописать правила не туда и после перезагрузки/отключения сети они исчезнут…

Да, -A опасный аргумент.

pv = pipeline view, его нужно ставить. На Ubuntu ставится из apt. Для CentOS pv есть в EPEL.

constb +141

Мастер

Сообщений: 624

Re: Куда класть дамп базы?

С другой стороны, большая часть серверов, особено всякие VPS, имеют одного логического пользователя — root’а, и одного физического (т.е. только админ ходит на этот сервер). Здесь нет смысла скрывать пароль ни в ps, ни в истории.

формально – да, так и есть. просто я стараюсь вырабатывать хорошие привычки для обращения с паролями, чтобы не оказаться в ситуации когда надо было проявить осторожность, а я сделал как попало, и кто-то из-за этого пострадал. про login path почитаю, но вообще с 5.7 как раз приходится работать редко, обычно у меня или родная для jessie версия 5.5 или на центосе я подключаю ius-репозиторий и с него ставлю марию 10.1. по-моему там далеко не всё из 5.7 поддерживается.

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

это конечно, у меня рабочие доступы записываются в тасках приватного проекта «пароли» в асане (asana.com). в остальном, опять же вопрос привычки. я просто привык использовать ~/.my.cnf – у рута он с рутовым доступом, у юзера – с пользовательским. если на серваке несколько проектов с разделением прав, у каждого пользователя свой .my.cnf

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

именно поэтому прописываю везде один ключ с машины – таким образом если рабочая машина передаётся другому разработчику, она передаётся сразу с рабочими доступами. и по поводу «выписывать» – тоже обычно не выписываю. запросто бывает когда после большого перерыва года с два-три старый заказчик внезапно «выходит из сумрака» и ему что-то надо сделать, и он такой «ну у вас же где-то остались доступы», потому что свою копию он давно потерял и забыл где. я оказываюсь единственным у кого есть хоть какие-то доступы к серверу – меня уже с двух прошлых работ время от времени теребят – «а у тебя случайно не осталось …?», ну конечно у меня осталось!

В случае, если ты с этого сервера выходишь на другие сервера, нужно использовать «сквозной ключ» (agent forwarding). Если ты на Windows, то наверняка пользуешься putty — там есть небольшая программка pageant, в неё добавляешь все ключи, которые у тебя есть; она висит в трее. Для *nix есть аналог (ssh-agent).

putty agent'ом на винде пользовался постоянно, а вот с ssh agent'ом – как-то не сложилось. надо бы тоже поразбираться, удобная штука по идее. а вот про «сквозные ключи» вообще первый раз в жизни слышу, что удивительно – фича-то архикрутая! у меня как раз на прошлой работе сисадмин разводил паранойю и до боевого окружения достучаться можно было только через специальный ssh gate. сейчас я удалённо туда хожу когда есть заказы – приходится цепляться через две машины – сначала на мою бывшую рабочую в офисе, с которой есть доступ на ssh gate, потом с гейта куда надо – так задалбывает пароли топтать по клаве! ладно ещё в iTerm есть password manager… вот тут как раз бы такая возможность очень была кстати.

Лучше всего iptables

а я вот с iptables так и не подружился. количество параметров ком. строки оказалось для меня больше чем я могу запомнить. когда нужно закрывать порты – apt-get install ufw. то же самое по сути, но в простой и удобной обёртке. и правила он сам загружает после рестарта.

pv = pipeline view, его нужно ставить. На Ubuntu ставится из apt. Для CentOS pv есть в EPEL

ага, нашёл, буду разбираться. удобная штука

Proger_XP +345

Топ 30%

Мастер

Сообщений: 1,312

Статей: 33

Re: Куда класть дамп базы?

ИМХО, плохой выбор. Асана это менеджер задач, пароли там наверняка индексируются внутренней базой и, конечно, хранятся в открытом виде. Лучше использовать специализированный сервис, хотя к онлайн-сервисам для хранения паролей доверие у меня низкое (достаточно почитать про 1Password, у которого раза три за время существования находили критические проблемы).

Локальный KeePass + плагин для браузера — наше всё. Плюс синхронизация в Dropbox.

У тебя один ключ на проект/сервер? Обычно наоборот, ключи разработчиков прописываются, когда они приходят в проект, и удаляются, когда уходят. Часто ведь ключ разработчика не только для рабочих серверов, но и для личных данных.

Надо погрозить им пальцем и сказать, чтобы кончали заниматься фигнёй. Хорошо если ты человек порядочный, а так «забудет» один из разработчиков свой ключ, а потом — «ой, а нас взломали!».

Бекапы тоже поди не делают?

Это нормальная практика для «особо секретных» проектов (с точки зрения админов/владельцев) — вход в локальную сеть через шлюз. Правда, обычно шлюзом делают VPN, чтобы не надо было поднимать туннели — VPN-то можно подключить один раз и забыть, он сам поднимается и т.п. — как ещё один кабель от локальной сети. Идёт запрос на ресурс внутренней сети — VPN используется, нет — соединение идёт по обычному каналу.

От паролей надо отказаться и везде использовать ключи, они намного более стойкие и их нельзя увести, не взломав твой комп (т.к. по сети передаётся «ответ» от твоего ключа, а не сам ключ). И сквозная авторизация работает только по ключу.

В putty авторизация включается в Connection | SSH | Auth | Attempt authentication using Pageant плюс Allow agent forwarding (это позволяет пропустить ключ дальше, чтобы авторизоваться на хосте за этим хостом). В *nix-овых ssh сам использует ssh-agent, если он запущен; настройка для пропуска авторизации может стоять, может нет, включить её можно ключом -A ( shssh -A user@host).

Для ssh-agent, кстати, есть какой-то GUI, правда я им не пользовался.

Если нужно постоянно подключаться к ресурсу через туннель (т.е. ты > ssh > конечный хост), то тут полезна функция проброса портов самим ssh. То есть на автозапуск настраиваешь подключение к хосту с ключом проброса, у тебя локально открывается порт и к конечному хосту ты подключаешься, используя этот локальный порт, а не адрес хоста. Либо наоборот — удалённый ssh подключается к конечному хосту. открывает локальный порт и ты подключаешься к нему, а запрос перекидывается дальше (можно и простым iptables на шлюзе такой редирект сделать).

Например, если есть gate_ip — шлюз и remote_ip — удалённый хост (доступ только со шлюза):

shssh root@gate_ip -D1080
# либо
ssh rrot@gate_ip -L12345:remote_ip:22

Настройки авторизации (-i, -A, -C и т.д.) подставить по вкусу. Также можно добавить ключ -N, он не будет открывать терминал (т.е. не получится выполнять команды на gate_ip), что сэкономит какие-то ресурсы, ибо для фонового туннеля терминал не нужен.

Первый случай открывает локальный порт 1080 по протоколу SOCKS5. Через этот порт можно ходить на любой хост, только запросы будут идти не от локальной машины, а с gate_ip. Такой себе VPN. В Firefox (в отличии от Chrome/IE) прокси настраивается элементарно в настроках > сеть. Но для работы через этот порт софт должен поддерживать проксирование через SOCKS5.

ssh проксирование поддерживает через специальную опцию, правда, нужен ещё установленный netcat (он стандартный и обычно идёт с ОС):

shssh root@localhost -o ProxyCommand="nc -x 127.0.0.1:1080 %h %p"

Во втором случае локальный порт 12345 любое подключение отправляет только и исключительно к remote_ip, порт 22. Здесь преимущество в том, что от софта поддержки прокси не требуется — для софта ресурс remote_ip:22 виден как localhost:12345. Так что для ssh подключение такое:

shssh root@localhost -p 12345

Такие пробросы полезны и в случае, когда конечный ресурс не поддерживает шифрование. Например, IPMI до сих пор «голый», поэтому его заворачивают либо в VPN, либо в ssh. В этом случае трафик от тебя до VPN/ssh идёт закрытый, а между VPN/ssh и IPMI — открытый (обычно они в локальной сети, так что это не проблема). Или, например, можно telnet завернуть.

Я iptables тоже долго боялся, вся эта магия с файерволлами для меня была как тёмный лес. Но потом понадобилось всё-таки разобраться в этом раз и навсегда, я прочитал книжку iptables — Pocket Reference (меньше 100 страниц, справочник) и у меня всё в голове выстроилось. Теперь первым делом на новых системах сношу ufw — iptables гораздо прозрачнее, виден путь пакетов (ufw это «надстройка» над iptables).

На самом деле параметров у iptables, по сути, не больше 10 штук, если считать обычные протоколы (TCP и UDP). Остальное это расширения, которых там очень много, я даже трети не использовал. Главное разобраться в том, как пакеты идут от сети/в сеть, то есть разные таблицы (nat, INPUT и пр.) — это в той книге как раз очень здорово описано.

constb +141

Мастер

Сообщений: 624

Re: Куда класть дамп базы?

ИМХО, плохой выбор. Асана это менеджер задач, пароли там наверняка индексируются внутренней базой и, конечно, хранятся в открытом виде.

наверняка. вообще думал перенести их куда-нибудь. KeePass – интересный вариант, хотя синхронизация через дропбокс меня как-то смущает – не получится ли так что несинхронизированные изменения с одной машины перезапишут более новую версию базы, синхронизированную с другой.

У тебя один ключ на проект/сервер? Обычно наоборот, ключи разработчиков прописываются, когда они приходят в проект, и удаляются, когда уходят. Часто ведь ключ разработчика не только для рабочих серверов, но и для личных данных

у меня обычно один-два ключа на рабочую машину. когда я на какой-то сервер хожу с рабочей машины и из дома – там просто прописываются два ключа, ключ рабочей машины и ключ домашней. второй ключ на рабочей машине нужен если я с работы хожу на какие-то сервера не связанные с работой – такой ключ при смене работы просто сносится с машины и до свидания, а рабочий остаётся.

Бекапы тоже поди не делают?

бэкапы – моя боль. я куда не устроюсь работать везде талдычу как попугай – бэкапы, бэкапы, бэкапы, и всё равно такое впечатление что кроме меня это вообще никому не нужно. бывало рабочее время трачу на настройку бэкапа практически вопреки прямому распоряжению начальства – реально у людей нет представления о том, насколько ненадёжными могут быть железо, хостеры, пароли доступа и пр. бывает вообще что о существовании бэкапа не подозревает ни заказчик ни начальство, а он есть только потому что я работал над проектом, и никто мне спасибо не скажет потому что и так всё работает. прям даже хочется в душе иногда чтобы что-то упало, чтобы можно было доказать что я не зря время тратил но с другой стороны, по законам Мерфи, ведь если что-то упадёт, то обязательно именно там где настроить не успел или не захотел

Если нужно постоянно подключаться к ресурсу через туннель (т.е. ты > ssh > конечный хост), то тут полезна функция проброса портов самим ssh

-L использую и довольно часто – специальной софтиной локальные туннели настраиваю, а вот про то что ssh умеет поднимать по туннелю сокс-прокси – это для меня новость! ещё бы больше софта умело через них работать! последнее время разработчики что-то обленились – всем подавай http proxy. с другой стороны можно таким образом секурно прокидывать трафик до «тупой» прокси без авторизации через ssh-туннель – я сейчас в отпуске в Крыму, внезапно это оказалось очень актуально – количество сервисов которые нынче банят крымские айпишники неожиданно велико. когда припёрло настроил microproxy на рабочей машине на работе с фильтром по IP в xinetd, но это быстрое и некрасивое решение (а если админ спалит – ещё и прилететь может) – скорее всего воспользуюсь советом и переделаю на туннель+локалхост

Теперь первым делом на новых системах сношу ufw — iptables гораздо прозрачнее, виден путь пакетов (ufw это «надстройка» над iptables).

между

iptables -A INPUT -p tcp --dport 3309 -s 1.2.3.4 -j ACCEPT

и

ufw allow 3309 from 1.2.3.4

я всё-таки выбираю ufw

Proger_XP +345

Топ 30%

Мастер

Сообщений: 1,312

Статей: 33

Re: Куда класть дамп базы?

У каждой записи есть ID и время модификации, так что базы сливаются вместе без проблем.

В качестве альтернативы бекапам на FTP и т.п. советую tarsnap.com (только для Linux) — дедупликация, локальное шифрование, инкрементные бекапы. Работает сразу и без настроек. Из минусов (относительных) — бекапит только на свои сервера, поэтому надо платить за место. Надо, конечно, начальство уговорить… ну устроить локальный коллапс. Случайно, конечно

Даже больше скажу, есть проект hissh (кажется так) — это набор патчей к OpenSSH, там подкручены некоторые настройки соединения, в итоге авторы утверждают, что по ssh можно пропустить до гигабита в секунду (если железо держит шифрование). То есть по скорости работы ничуть не хуже OpenVPN.

«Поддержку» прокси можно добавить разными инструментами. Для Windows есть Proxifier, для *nix — proxychains и torsocks (этот пускает трафик приложения через Тор). Для торрентов такое решение не подойдёт, но простые приложения типа месенджеров проксируются на ура.

Кроме того, если пошаманить с iptables, то можно завернуть трафик от приложений (всех или выделенных) в SOCKS с помощью redsocks. redsocks открывает локальный порт, iptables делается редирект на этот порт, а дальше полученные соединения redsocks перенаправляет в соответствии со своими настройками. Всё вообще прозрачно.

Трафик от клиента до SOCKS-сервера нешифрованный (не смотря на то, что SOCKS расшифровывается как Socket Secure). Поэтому хотя можно на сервере поднять свой SOCKS-сервер (например, Dante), лучше делать туннель через ssh -D. В качестве бонуса трафик можно будет сжать (ssh -C -D). Скорость работы в обоих случаях одинакова.

constb +141

Мастер

Сообщений: 624

Re: Куда класть дамп базы?

В качестве альтернативы бекапам на FTP и т.п. советую tarsnap.com (только для Linux) — дедупликация, локальное шифрование, инкрементные бекапы. Работает сразу и без настроек. Из минусов (относительных) — бекапит только на свои сервера, поэтому надо платить за место.

за деньги мой вариант – хранение в amazon s3 с заливкой через s3cmd и инкрементальные архивы с помощью tar -G. точнее я бэкаплю snar-файлы с первого числа каждого месяца, так что мои бэкапы корректнее называть наверное дифференциальными – для распаковки за нужное число нужны только два архива – за первое число и за нужное число выбранного месяца

«Поддержку» прокси можно добавить разными инструментами. Для Windows есть Proxifier, для *nix — proxychains и torsocks (этот пускает трафик приложения через Тор).

я скорее что то чтобы заставить ходить через сокс-прокси программы которые умеют только http-прокси. впрочем уже нашёл что на винде это умеют 3proxy и polipo, в *никс – privoxy и polipo. сокс в них настраивается как апстрим. в общем, буду экспериментировать