Для того, чтобы на наш компьютер (Linux) подключить папку с удаленного сервера (Linux), можно использовать sshfs.

Для измерения текущей нагрузки на диски (что происходит, кто куда копирует и прочее) в Linux можно использовать iotop (и здесь же lsof) и iostat. А для тестирования возможностей дисковой системы fio. Несмотря на то, что первое, о чем можно подумать в плане попугаев - это IOPS или же Мб/сек за чтение или запись, обратите внимание на время ожидания. Примерно как если бы вы стояли в очереди в кассу: вас обслужили бы за 2 минуты, но очередь может быть минут на 30. И со стороны наблюдателя ваш процесс обслуживания будет "висеть". Именно так могут ощущать себя клиенты сервера, если время ожидания будет намного превышать время выполнения конкретной задачи. Поэтому определение длинной очереди и задержек часто бывает более важным, чем знать, что ваш диск "вау, может писать 400 Мбит/с". Нагрузка на диск может оказаться в 4000 Мбит/с в течение длительных периодов времени и все это время клиенты сервера будут недовольны.

Стоял себе сервер, подключенный к одному провайдеру (ip 1.1.1.1). Все в порядке, все работает. И вот привалило счастье - появился второй провайдер (для большей доступности). Подключили еще одну сетевую карту, назначили ip 2.2.2.2. Проверяем доступность сайта или почты через 2.2.2.2. А в ответ - тишина. На запросы не отвечает, сайт по нему не открывается. Хотя и брандмауэр уже настроили, и вроде бы все должно работать. Все дело в маршруте по-умолчанию. Если default gateway у сервера указан как 1.1.1.1, то даже если вы снаружи пытаетесь пингануть 2.2.2.2, то сервер все равно упорно отправит ответ через 1.1.1.1, соответственно, пакет будет потерян, т.к. выйдет через другой интерфейс. Что делать?

Это на своей рабочей станции вы всегда видите часы перед глазами и расхождение даже на 5 минут будет сразу видно. А на сервер заходят тогда, когда что-то случилось или просто для профилактики, но вряд-ли часто. И в консоли время не показывается. А сбиться оно может. А последствия могут быть разными. Простой вариант: дата создания или редактирования файла будет не верной. А если это почтовый сервер? Вы письмо приняли раньше, чем его отправили? Или запостили новость на сайт завтрашним днем? Дата важна для логов, для множества вещей. Итак, время должно быть точным.

Если письма с вашего почтового сервера вдруг стали отклонять, то может быть полезным проверить корректность обратного разрешения IP в доменное имя (иначе, проверить PTR).

Если запись "А" указывает, что такое-то имя хоста (test1666.org, к примеру) имеет такой-то IP (например, 8.8.8.8), то "PTR" запись, наоборот, может подтвердить, что конкретному IP действительно соответствует это доменное имя. Грубо: спамер отправляет со своего "левого" сервера письмо, подделав его, будто письмо отправлено с домена test1666.org. В любом случае, принимающий почтовик увидит IP-адрес отправителя (ip сервера спамера) во время установления SMTP-сессии и проверит, а соответствует ли такому IP-адресу легитимный MX сервер домена test1666.org. Если нет, письму присвоят больший спам-рейтинг или отклонят его вообще. Ну или совсем по-пацански: Вася всем говорит, что учится в Универе. Но до тех пор, пока сам Универ это не подтвердит, верить Васе можно только частично.

(актуальность статьи: 19.10.2023) Иногда мне кажется, что создатели Mikrotik намеренно лишают себя прибыли, не создавая однозначных пошаговых руководств по настройке своих детищ. Почти 100% потребителей этих роутеров пытаются настроить VPN, использовать два или более WAN одновременно или в качестве резервных. Именно это ищут по всей сети (и часто вне рунета) счастливые владельцы этих замечательных устройств. Представьте, на сколько бы увеличилась армия владельцев, если бы для настройки этих функций было два-три визарда в веб-интерфейсе. А сейчас.. сейчас именно благодаря сложности настройки (и, соотв., меньшему количеству желающих купить) мы имеем недорогое, малокапризное для несложных задач устройство, которое надо заставить работать 24х7х365. Например, в качестве VPN-сервера. Поехали!

При настройке VPN-сервера на Mikrotik, могут быть ошибки. Некоторые из них не связаны с очепятками и недостатком знаний. Могут встречаться нелогичные или специфичные для какой-то ситуации ошибки.

Только за июнь-июль 2015 в Adobe Flash найдены несколько 0-day уязвимостей. Каждая из них может в любой момент, в обход всех антивирусов, доставить вам головную боль.

CVE-2015-5123 - DoS Exec Code Mem. Corr.
CVE-2015-5122 - DoS Exec Code Mem. Corr.
CVE-2015-5119 - DoS Exec Code Overflow Mem. Corr.
CVE-2015-5118 - Exec Code Overflow
CVE-2015-5117 - Exec Code
CVE-2015-5116 - Bypass
CVE-2015-4433 - Exec Code

и др.

Порой я удивляюсь на себя. Вроде бы, айтишник. Вроде бы постоянно имею дело с новыми технологиями. Но когда речь заходит о privacy, я становлюсь весьма консервативным и неповоротливым. Вопрос, где и как хранить пароли от кредитки для оплаты мобильного, пароли от форумов, счетчиков и всего такого, для меня никогда не был сложным: Truecrypt + Dropbox + Notepad. Минимум проблем совместимости с браузерами (нет совместимости - нет и проблем), максимум безопасности, но и удобства тоже минимум. Какие тут "правой мышкой" и в бой... Да, это рабочий вариант, да, нужно не каждый день, но не очень удобно, что уж тут говорить. 

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

Как-то сами собой нарисовались LastPass, KeePass и 1Password.

Кроме картинки с xkcd.ru, больше ничего нет ))