How to build code remotely in Visual Studio Code

    In Sublime Text you could archieve remote code execution using following code:

        "cmd": ["rsync -az '$file' && ssh 'chmod +x ./$file_name; ./$file_name'"],

    In VSC same could be achieved using Tasks functionality. Difference is you couldn’t create global settings, whatever you do will be saved in project you’re working in. Another difference is you could write something in console and it will be sent over to script’s STDIN, which is unachiavable in Sublime Text.

    To start, open your project task configuration file via Ctrl+P, >Configure Task Runner, Others. Then paste following json text and customize it for yourself:

        // See
        // for the documentation about the tasks.json format
        "version": "2.0.0",
        "tasks": [
                "taskName": "",
                "command": "rsync -az '${file}' && ssh 'chmod +x ./${fileBasename}; ./${fileBasename}'",
                "type": "shell",
                "group": {
                    "kind": "build",
                    "isDefault": true

    What will it do? Copy current open file to server’s home (~) folder using rsync (non-verbose mode, add -v in case of trouble), then make it executable and run it via ssh.

    Monitoring system comparison: Shinken vs Sensu vs Icinga 2 vs Zabbix


    In their own words, Shinken is a monitoring framework, a Python Nagios Core total rewrite, enhancing flexibility and large environment management.


    According to the documentation, every type of process can be run even on different hosts. That’s interesting, because you might want DB in the cheapest place, data receivers in every datacenter, and alerter processes closer to your physical location. Shinken user on the scheme is happy; that’s a positive sign:

    Shinken simple distributed architecture

    For multi-regional monitoring, there is also an answer, Realms.

    Here, you notice something awesome: Data is collected into regional DB, not into a global one. There are also sub-realms setup for smaller big setups, which requires fewer machines to setup and just one DB:

    Shinken simple multi-regional distributed architecture

    Another point to consider when you’re talking about scalability is fault tolerance. I’ll quote documentation here:

    Nobody is perfect. A server can crash, an application too. That is why administrators have spares: they can take configurations of failing elements and reassign them. For the moment, the only daemon that does not have a spare is the Arbiter, but this will be added in the future. The Arbiter regularly checks if everyone is available. If a scheduler or another satellite is dead, it sends its conf to a spare node, defined by the administrator. All satellites are informed by this change, so they can get their jobs from the new element and not try to reach the dead one. If a node was lost due to a network interruption and it comes back up, the Arbiter will notice and ask the old system to drop its configuration.

    Configuration systems integration

    Automatic hosts and services discovery seems well-covered, and because configuration is kept in files, you could easily generate them yourself with Chef\Puppet, based on information on hosts you have.

    Audit log

    Because configuration is stored in files, you could use generic things, like version control system (Git, Mercurial), to track changes and their ownership. From documentation, I found no evidence of Shinken tracking web-interface actions.


    Shinken UI

    Shinken WebUI is proven itself to work well with thousands of hosts and tens of groups.


    I found no visible drawbacks, based on the documentation. The only thing that concerns me is its rapid development in the past and very slow pace of commits in the present: around 40 commits this year; most are pull requests merged, so no new development is going on, and only community-written bugfixes are being included. It’s either too good to move on (which is never the case; even old-timers like vim and emacs get their code updated) or it’s another opensource project that not enough people care about — you should know such things before using such a complex thing as a monitoring system.

    Frédéric Mohier was very kind to give me an insight on reasons of current situation: more than one year ago, some of the main developers of Shinken left the project and made a fork named Alignak, which is being activly developed and plan to deliver 1.0 release in December, 2016.


    Sensu is a monitoring framework (platform, as they call themselves) rather than complete monitoring system. Its key features include:

    • Puppet \ Chef integration — define what to check and where to send messages in your configuration system
    • Reusing existing technical solutions where possible, instead of inventing their own (Redis, RabbitMQ)

    Sensu pulls events from queue and executes handlers on them; that’s it. Handlers can send messages, execute something on the server, or do something else you want.


    Sensu architecture is flexible, because every component can be replicated and replaced in a few ways. A sample fault-tolerant setup is described in the following presentation; here is a generalized view:

    Sensu architectural diagram

    With HAProxy and Redis-sentinel, you can build a setup in which, if one node of a type is alive (Sensu API, Sensu Dashboard, RabbitMQ, Redis), your monitoring will continue to work without manual intervention.

    Configuration systems integration

    Built-in (Puppet, Chef, EC2!) but only in paid version, which sucks for sure, if you have thousands of servers and don’t want to pay for something with free analogues.

    Audit log

    Built-in, however, only in Enterprise edition.


    Uchiwa screenshot

    Sensu default UI called Uchiwa, seems to have many limitations. It seems too simple for a diversified environment with thousands of servers. The enterprise edition comes with its own dashboard; however, it doesn’t seem to be doing much, except adding a few disabled out-of-the-box features over the opensource part (like audit).


    • Lack of historical data and very limited ability to check on it;
    • Create your own monitoring system; there are no working presets waiting for you;
    • Aggregation of events is tricky;
    • Message sending is very tricky, which is scary (because this part must be the simplest and most reliable part of monitoring) — not true, I had wrong impression by documentation, thanks x70b1 for explanation;
    • The “We don’t want to reinvent the wheel” way has its own limitations of which you could be aware of if you have used any such software before (in my case, it was Prometheus monitoring system, which left whole sets of features up to the user to implement, like authentication).

    Icinga 2

    Icinga is the fork of Nagios, rewritten from scratch in version 2. Opposite to Shinken, it is a good fork with constant updates being made.


    General architecture:

    Icinga 2 architecture

    Icinga 2 has a well-designed distributed monitoring scheme. Only pitfall I found while setting up the test cluster is the amount of settings related to distribution: It could be overwhelming initially.

    Configuration systems integration

    Pretty good, here are two presentations: The Road to Lazy Monitoring with Icinga 2 and Puppet by Tom de Vylder and Icinga 2 and Puppet: Automated Monitoring by Walter Heck. The key Icinga feature is storing configuration in files, which makes them easy-to-generate on the Puppet side, which I achieved using PuppetDB as a data source about all hosts and services.

    Audit log

    As I found, audit log is present with director module. There is no build-in audit in IcingaWeb2 at the moment.


    Icinga 2 web interface

    IcingaWeb2 seems like a decent UI with a lot of extension modules for a lot of purposes. From what I’ve seen, it looks most extendable and flexible, yet has all the features you could expect from a monitoring system UI out of the box.


    The only drawback I’ve found so far is a complexity of initial setup. It’s not that easy to understand the Icinga point of view on monitoring if you’re used to having something different like Zabbix.


    Zabbix is a stable and reliable monitoring system with a steady development pace. It has a huge community and most questions you might think of already have an answer somewhere, so you don’t have to worry if something is possible with Zabbix.


    Zabbix has a server that communicates with a single DB, and no matter what you do, with every other resource on hand (memory, network, CPU), you will hit DB disk IO limits. With 6000 IOPS on Amazon, we could maintain around 2k new values per second, which is a lot, but still leaves much to be desired. Proxies and partitioning could improve the situation with performance, but in terms of reliability, you always have a main DB, which is a single point of failure for everything.

    Configuration systems integration

    Zabbix is poorly prepared for a diversified environment, managed by a configuration management system. It has some low-level discovery capabilities for hosts and services, but they have their limits and are not tied to a configuration system. The only option for those who seek such integration is to make something themselves using API.

    Audit log

    Zabbix logs everything well, except one huge blind spot: Changes via API are not logged mostly, which could be or could not be the problem for your case. The other thing I want to mention is that all problems Zabbix has are logged somewhere in its bug tracker, and if they have enough attention, they are getting fixed sooner or later.


    Dashboard is a main screen of Zabbix

    Zabbix has UI with all possible features built-in. The only bad thing you could say about it is it’s not extendable at all — you have either to stick with what UI gives you or do something on your own. You have no option to improve UI because of its general complexity.


    • Very basic analytic on what is going on, not right now, but in general (only tool here is “top 100 fired triggers”, which improved greatly in 3.0);
    • Maintenance setting, as opposed to the Nagios-based system, couldn’t be set on trigger level, only on the host, and the whole system is very complex before the 3.2 release redesign;
    • Alerts generation out-of-the-box leaves much to be desired. In my case, we had to implement external alerts aggregation system (to be released in opensource someday);
    • Investigating Zabbix performance issues without experience turns into a mess, because you have one big server that you should diagnose.


    That’s a long post with many images and even more text. There is no answer for simple questions like “which is best”, but a collection of information for decisions on these questions, based on your requirements. I’m looking for a system that works on Linux and monitors Linux well, so platform support is not considered. Also, I’m looking for a system that will help me monitor thousands of servers with tens of thousands of services.

    In my own opinion, only Zabbix and Icinga 2 are mature enough to be used in enterprise, and the main question one should ask himself is which monitoring philosophy he could relate to, because both do the same thing with very different approaches.

    Язык и прочие части тела

    Привет, я давно не писал сюда, а мыслей накопилось, и вот.

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

    К теме языка: есть один бывший программист, сейчас бизнес-ангел, Paul Graham, известный своими эссе, большая часть которых в последнее время посвящена стартапам (скукотища), однако бывают и интересные темы, в их числе последняя — письмо.

    Here’s a simple trick for getting more people to read what you write: write in spoken language.

    Something comes over most people when they start writing. They write in a different language than they’d use if they were talking to a friend. The sentence structure and even the words are different. No one uses “pen” as a verb in spoken English. You’d feel like an idiot using “pen” instead of “write” in a conversation with a friend.


    You don’t need complex sentences to express complex ideas. When specialists in some abstruse topic talk to one another about ideas in their field, they don’t use sentences any more complex than they do when talking about what to have for lunch. They use different words, certainly. But even those they use no more than necessary. And in my experience, the harder the subject, the more informally experts speak. Partly, I think, because they have less to prove, and partly because the harder the ideas you’re talking about, the less you can afford to let language get in the way.


    People often tell me how much my essays sound like me talking. The fact that this seems worthy of comment shows how rarely people manage to write in spoken language. Otherwise everyone’s writing would sound like them talking.

    If you simply manage to write in spoken language, you’ll be ahead of 95% of writers. And it’s so easy to do: just don’t let a sentence through unless it’s the way you’d say it to a friend.

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

    Итоги первого парашютного сезона

    В субботу 11 октября я приехал на аэродром (Киржач) только после заката. Прыжков с парашютом в тёмноте обычно не проводится (исключение — спортивная категория D включает в себя два ночных прыжка или приводнения), и я направился к домику за старым аэродромом, в котором базируется сэнсэй с семьёй. Часть распорядка дня — грандиозная попойка каждую ночь с субботы на воскресенье, у жены сэнсея в этот вторник был день рождения, и эта суббота традиций не нарушила: по приходу я первым делом увидел красивейший торт с карамельной копией именинницы на верхушке и десятка полтора людей, которые обсуждают откусанную виновницей торжества у своей карамельной копии руку.

    Половина присутствующих были изрядно пьяны, а остальные стремительно приближались к этому состоянию, мне стало скучно, и я отправился спать в машину. Я бы и не рассказывал о субботе, если бы не один случай: когда я поздоровался с компанией, и прибился к разговору (с одним из приуствующих мы вместе проходили AFF), рядом стоящий человечек протянул мне руку, представился Андреем, и назвал моё имя. Я удивился, услышав фамилию (никто из знакомых не запоминает полузнакомых людей по фамилии, ещё и на аэродроме, где все знают друг друга по именам \ прозвищам), и оказалось, что когда-то я наткнулся на его фотографии из Киржача и прокомментировал его фото 2013 года, о чём он мне и рассказал. После расспросов выяснилось, что у него в два раза больше моего прыжков, и он приезжает на аэродром почти каждые выходные, каждый раз увозя с собой новый набор фотографий.

    Строки выше этой я написал, пока грел машину в три ночи воскресенья — за бортом 8°C, температура снаружи и внутри сровнялась, я замёрз и проснулся. Вторым впечатлением поездки было повторное пробуждение от холода, к счастью, через несколько минут прерванное будильником — больше всего я боялся проснуться в пять утра, когда придётся снова пытаться согреться и заснуть. Я разминулся со спортсменами, просыпающимися тут и там, забрал сертификат об окончании AFF (экзаменационный прыжок AFF у меня был в конце июля), и поехал на новый аэродром (Слободка), находящийся в стороне от старого.

    На аэродроме последовательность действий каждый раз одинаковая: пройти врача, записаться в листы аэродрома о прохождении инструктажа и о намерении совершить сколько-то прыжков. В конце дня необходимо проставить в “лист намерений” реальное количество прыжков, чтобы было известно, что ты вернулся и поставил это число своей рукой: тебя не нужно искать в окрестном лесу, зацепившимся за сук. На аэродроме Слободка (Киржач) один самолёт АН-28, который несколько раз за день поднимается в воздух и выбрасывает парашютистов — каждый раз называется “подъёмом”, и доступные для записи подъёмы нумеруются в пределах дня, тринадцатый же подъём никогда не объявляется — после двенадцатого идёт “двенадцать А”, а затем четырнадцатый. Существуют также недоступные для записи “тандемные” подъёмы и подъёмы для прыгающих с круглым парашютом Д-6 с высоты 800 метров. Люди, которым понравилось небо, как правило, копят деньги, и обучаются прыжкам со спортивным парашютом, поэтому большинство прыгаюших с Д-6 делают это в первый раз, за что их называют “перворазниками”. Летом подъёмов бывает до двадцати пяти, в эти выходные — было 13 в субботу и 15 в воскресенье.

    Воскресным утром описанная утренняя рутина заняла больше обычного времени, и, простояв час в очереди на запись, я записался на два подъёма, в середине и ближе к концу дня. В этот день я единожды прыгнул с инструктором и дважды самостоятельно.

    Программа поездки на Yet another Conference 2014

    30 октября пройдёт очередная Yet another Conference, мне выслали приглашение, и я жду-жду-жду. Ниже предполагаемая моя карта перемещения; безумно круто будет увидеть Игоря Сысоева, да и много других интересных докладчиков и тем.

    Там точно будет Искуариэ́ль, спешите познакомиться:)


    Секретный доклад General

    10:00, Зал 1

    Секретный доклад General

    11:25, Подиум

    Использование Python для интерактивного анализа данных Backend

    11:30…12:20, Зона Workshops

    Мастер-класс посвящён работе с современными средствами интерактивного анализа данных, в частности IPython Notebook и Pandas. Мы будем анализировать логи Apache и научимся загружать информацию из логов в Pandas Dataframe, а также выполнять с ней простейшие действия — сортировку, осреднение по времени, группировку. Параллельно с анализом будем визуализировать результаты с помощью IPython Notebook и посмотрим, как строить карту с отображением городов, из которых приходят запросы на сервер.

    Николай Колдунов, Climate Service Center

    Выпускник СПбГУ и Университета Бремена по специальности «Полярные морские исследования». Получил PhD Университета Гамбурга в области океанологии. Работал докторантом в Институте метеорологии общества Марка Планка и постдоком — в Институте океанологии Университета Гамбурга. Научные интересы связаны с математическим моделированием Северного Ледовитого океана и морского льда.

    State of the Standardized Web Frontend

    11:55…12:10, Зал 4

    В 2014 году принципы Extensible Web начали воплощаться в новых стандартах. Поговорим о Web Crypto, Web Animations, Service Worker и других вещах, которые должны принципиально изменить веб-платформу в ближайшем будущем.

    Сергей Константинов, Яндекс

    Руководитель группы разработки API Яндекс.Карт. Окончил Южно-Уральский государственный университет. Разработкой API Яндекс.Карт занимается с 2008 года. С 2013 — участник Технической архитектурной группы Консорциума [W3C](

    Проектировка IPv6-оnly датацентра в Яндексе Administration

    12:10…12:50, Зал 3

    Я расскажу о том, с какими проблемами мы столкнулись при проектировке IPv6-only датацентра в Яндексе, как мы их решили и какой опыт получили. А также о том, на что стоит обратить внимание в первую очередь при проектировке таких инсталляций.

    Никита Широков, Яндекс

    Более шести лет работает с компьютерными сетями — от систем в маленьких офисах до опорных сетей операторов связи. Последние три года — сетевой инженер в NOC Яндекса. Занимается как развитием опорной сети и датацентров, так и каждодневной эксплуатацией.

    Масштабируемая конфигурация nginx Backend Administration

    12:50…13:40, Зал 3

    Как создать конфигурацию, которую будет легко сопровождать в течение многих лет. Правильные и неправильные способы конфигурации, типичные ошибки. Где следует использовать регулярные выражения. Почему подход copy-paste лучше, чем DRY (Don't Repeat Yourself).

    Netflix CDN и открытый код Administration

    13:40…14:20, Зал 3

    Netflix — сервис video on demand, который уже составляет серьёзную конкуренцию классическому телевидению. Более 50 млн его клиентов смотрят видео через интернет в качестве HD и выше. В докладе речь пойдёт о том, почему Netflix не пользуется готовыми CDN, а строит свою, и почему для этого были выбраны open source технологии: FreeBSD и nginx.

    Глеб Смирнов, Nginx Inc.

    Разработчик операционной системы FreeBSD с 2004 года, в настоящее время работает в Nginx Inc. Основная область интересов — сетевой стек.

    Как мы делали TLS в Яндексе Information Security

    14:30…15:10, Зал 4

    Шифрование коммуникаций — необходимый атрибут любого безопасного сервиса. В докладе мы рассмотрим основные сложности, которые возникают при внедрении полноценной поддержки TLS в системах масштаба Яндекса. Разберём особенности поведения браузеров и пути оптимизации скорости при использовании HTTPS. Обсудим, какие технологии помогут усилить безопасность и производительность на стороне сервера.

    Эльдар Заитов, Яндекс

    Начал интересоваться информационной безопасностью ещё в школе. Долгое время занимался разработкой, затем проводил анализ защищённости в крупнейших российских компаниях. В Яндексе занимается безопасностью продуктов и сервисов.

    Building a Modern Security Engineering Organization Information Security

    15:10…15:50, Зал 4

    Continuous deployment and the DevOps philosophy have forever changed the ways in which businesses operate. This talk will discuss how security adapts effectively to these changes, specifically covering: * practical advice for building and scaling modern AppSec and NetSec programs; * lessons learned for organizations seeking to launch a bug bounty program; * how to run realistic attack simulations and learn the signals of compromise in your environment.
    Zane Lackey, Signal Sciences

    Zane Lackey is the Founder/CSO at Signal Sciences and serves on the advisory boards of the Internet Bug Bounty Program and the US State Department-backed Open Technology Fund. Prior to Signal Sciences, Zane was the Director of Security Engineering at Etsy and a Senior Security Consultant at iSEC Partners.

    Развёртывание отказоустойчивой инфраструктуры OpenStack Administration

    15:20…16:20, Зона Workshops

    Мастер-класс для тех, кто уже попробовал OpenStack и хочет использовать его в продакшене. А также для тех, кто только собирается его попробовать и хочет научиться правильно его устанавливать. Я расскажу о ключевых моментах устройства OpenStack и покажу, как использовать эти особенности для построения отказоустойчивого кластера. Кроме того, расскажу, как правильно развернуть ключевые инфраструктурные компоненты OpenStack: MySQL Galera и RabbitMQ. А в конце продемонстрирую, как OpenStack работает в условиях отказа части подсистем, как это обнаруживать и как устранять возникшие проблемы.

    Владимир Ерёмин, Яндекс

    Администрировал высоконагруженные проекты и автоматизацию в Баннерной системе Яндекса, сейчас занимается внедрением IaaS-решений и виртуализации.

    Logbroker: сбор и поставка больших объёмов данных Backend

    15:50…16:30, Зал 1

    Современные высоконагруженные сервисы генерируют огромное количество данных. Статистические расчёты на их основе помогают в аналитике и принятии продуктовых решений. Задача сбора этих данных существенно усложняется, если их генерируют десятки тысяч серверов сотнями терабайт в день. Logbroker позволяет решать задачу сбора распределённо. В докладе мы рассмотрим ключевые особенности системы — возможность переживать отключение датацентра, поддержку семантики exactly once и потоков реального времени.

    Алексей Озерицкий, Яндекс

    Закончил МГУ, кандидат физико-математических наук. В Яндексе разрабатывает платформу публикации статистических данных, программирует для Unix на С++, С, Perl, Python и других языках.

    Crash Test Your Application… And Your Team Backend Administration

    16:30…17:10, Зал 1

    While the theoretical concepts of building resilient architectures are well established, the practices of maintaining such systems are less understood. To address this issue, many Amazon Web Services customers adopted Game Days – simulating unexpected failures to test resilience, detect and fix flaws, and train operation teams on emergency situations. This session covers the best practices learned from Game Days practice and the different failure simulation techniques that can be used on AWS.

    Carlos Conde, Amazon

    Carlos Conde is Chief Technology Evangelist at Amazon Web Services in Europe, the Middle East and Africa, and works with businesses of all sizes to help them understand the technical aspects of AWS and move their IT into the cloud. He is a frequent speaker at public events and technical workshops.

    Секретный доклад по безопасности Information Security

    17:10, Зал 4

    UPDATE: Добавил ссылки на видео докладов и страницы докладчиков. Самые крутые доклады по моему мнению: Как мы делали TLS в Яндексе и Building a Modern Security Engineering Organization.

    Парашютный спорт, первый шаг: программа обучения AFF

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

    Фотографии в альбоме «Парашюты», автора Верхотуров Дмитрий на Яндекс.Фотках

    AFF 5 уровень


    • обучение, позволяющее вам прыгать со спортивными парашютами, стоит 54450₽

    • аэротруба 11000₽/14000₽ на полчаса (малый и большой тоннель, цены на сайте иные, с инструктором AFF в будни получается указанная сумма)

    • страховка на день со страховой суммой 300 т.р. стоит 300₽, на год с суммой 500 т.р. — 7800₽ (покупается у Сумарукова Сергея, +79166598778, страховым случаем считается любое происшествие на территории РФ: от сломанной ноги при прыжке с парашютом или катания на лыжах до упавшей на голову сосульки)

    • после обучения стоимость самостоятельного прыжка составляет порядка 1700₽ и складывается из:

      • подъёма на 4000 метров — 1000₽ (или 910₽, если оплатить 11 прыжков)
      • аренды парашюта — 400₽
      • укладки парашюта — 150-200₽
      • аренды костюма, высотометра, шлема и очков — 200₽

    Как подготовиться к армии

    Подготовка, три месяца до армии:

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

    • Купите классические жёсткие берцы (порядка полутора-двух тысяч рублей), фланели (ткань) на портянки, и хотя бы месяц походите только в берцах; когда это удобно (т.е. когда вам не предстоит снимать обувь вне дома) — в портянках. Лучше натереть ноги и вылечить мозоли дома, чем мучаться стёртыми ногами в армии, где нет даже зелёнки.

    Установка SoftEther VPN в Ubuntu


    Что такое SoftEther VPN подробно описано в посте на habr’е, советую ознакомится с ней, если вы её ещё не читали:

    в этой статье речь пойдет о VPN-сервере, который может поднимать L2TP/IPsec, OpenVPN, MS-SSTP, L2TPv3, EtherIP-серверы, а также имеет свой собственный протокол «SSL-VPN», который неотличим от обычного HTTPS-трафика (чего не скажешь про OpenVPN handshake, например), может работать не только через TCP/UDP, но и через ICMP (подобно pingtunnel, hanstunnel) и DNS (подобно iodine), работает быстрее (по заверению разработчиков) текущих имплементаций, строит L2 и L3 туннели, имеет встроенный DHCP-сервер, поддерживает как kernel-mode, так и user-mode NAT, IPv6, шейпинг, QoS, кластеризацию, load balancing и fault tolerance, может быть запущен под Windows, Linux, Mac OS, FreeBSD и Solaris и является Open-Source проектом под GPLv2

    Документация SoftEther VPN

    Официальный сайт


    Документация (англ.)


    Подойдёт любая Ubuntu Server последнего LTS релиза или новее, обыкновенная Ubuntu, или другой современный .deb based дистрибутив типа Debian. Установка будет производиться в соответствии с соответствующим разделом мануала в Service Mode.


        sudo apt-add-repository ppa:paskal-07/softethervpn && sudo apt-get update sudo apt-get install softether-vpnserver

    Армейский уклад

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

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

    Итак, 65 межрегиональный учебный центр подготовки младших специалистов связи, “65 МРУЦ”, в/ч 41516 (воинская часть).