Сука блядь йбаный в рот во-первых openvpn по умолчанию настроен работать как сервер, а не как клиент. Поэтому после

apt install openvpn

нужно набрать

nano /etc/default/openvpn

и раскомментировать там

AUTOSTART="all"

В /etc/openvpn при этом должен лежать ёбаный config.conf

root@me:/etc/openvpn# ll
total 28
drwxr-xr-x   2 root root  4096 окт 21 20:20 ./
drwxr-xr-x 142 root root 12288 окт 21 20:07 ../
-rw-r--r--   1 root root  8143 окт 21 15:35 config.conf
-rwxr-xr-x   1 root root  1301 июн 22 18:23 update-resolv-conf*

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

systemctl daemon-reload

о которой упоминается в /etc/default/openvpn

# If you're running systemd, changing this variable will
# require running "systemctl daemon-reload" followed by
# a restart of the openvpn service (if you removed entries
# you may have to stop those manually)

Без неё ничего не заработает. Поэтому её надо запустить. Лично у меня сейчас это работает так:

nano /etc/default/openvpn
service openvpn stop
service openvpn start
--> хуй без масла, просто нихуя не работает и всё блядь, хоть ты ебанись

nano /etc/default/openvpn
service openvpn stop
systemctl daemon-reload
service openvpn start
--> заработало сука блядь

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

I've installed xubuntu it worked good. I thought well maybe pulseaudio will work (because Skype requires it)? I've installed pulseaudio, the system got fucked up. I've got two different mixers in the top right corner which acted independently and one of them couldn't reach 100% by stucking on 93%. This made my headphones left and right channel sound on a different volume. Sigh.
I've opened terminal and typed in

sudo apt purge pulseaudio

The operation ended as expected and I have decided to listen to some music. No. No sound. What happened?
I've opened terminal and typed in

alsamixer

What did I see?

Why do you mute the front channel, pulseaudio? Why are you so mean and evil?
I moved the cursor to front channel by a keyboard arrows and pressed M. Front channel has been unmuted and the music started playing. I've closed alsamixer by pressing ESC and became an alcoholic. Fin.

 

Le solution:

DON't use .exec
Use .spawn

The function is bad, it's design is bad, it's behaviour is unpredictable, it can be replaced by .spawn, there is no fucking excuse for anyone to ever use it.

If you do like:

proc = child_process.exec(...genius code...)
proc.stdout.pipe(gloryhole)

It continues to flood its internal buffer even if you do not provide any callback where the buffer is meant to be used.
This function is fucking nuts!

Keep calm and 200KB is enough for everyone.

[ ]
 
Don't forget to use `--level=inf` or `--level=9999999999` because `wget` is likely to sabotage the job due to default maximum recursion depth level of `5`.
[ ]
 

ВЫХОД ИЗ СЕМИ ПОТОМУЧТО BASH НЕ УМЕЕТ В АМПЕРСАНДЫ БЕЗ КАВЫЧЕК

curl -L "http://говно-с-амперсандами.рф/?a=b&ya_isporchu_tvou_zjizn=true&&&&&&&&&&&&&&&"
curl -L http://говно-с-амперсандами.рф/?a=b&ya_isporchu_tvou_zjizn=true&&&&&&&&&&&&&&&

ВЫЙДИ ИЗ СЕМИ
ВЫЙДИ ИЗ СЕМИ БЛЯДЬ СУКА
КАК ВЫВЕСТИ МЕНЯ ИЗ СЕМИ СУКА БЛДь руководство/пособие

Ебанатский дегенератизм - нередкое явление при работе с любыми СУБД, так уж складывается, что их разработкой занимаются довольно странные люди. Режим NO_ZERO_DATE пополняет список ебанизма. По умолчанию он включен с 5.7, и ровно с этого же момента он и начинает портить нам жизнь.

Проблема в том, что несмотря на его наличие, дата '0000-00-00 00:00:00' всё равно КАК-ТО БЛЯДЬ В БАЗУ ПОПАДАЕТ ёб вашу мать, а ошибка

MySQL Incorrect datetime value: '0000-00-00 00:00:00'

появляется только тогда, когда у вас горят сроки и надо в продакшене срочно что-то поправить. Ну естественно.

Поэтому мы делаем следующее:

  1. Мысленно посылаем инноваторов, внедривших NO_ZERO_DATE сначала в пизду, затем нахуй, а после - в ёбаный сатанинский ад.
  2. Заходим под root пользователем в базу.
  3. Выполняем запрос
SHOW VARIABLES LIKE 'sql_mode';

читире. Получаем в ответ что-то вроде "ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_..."
5. Ищем полчаса блядскую галочку "Full texts", спрятанную разработчиками phpMyAdmin в мелкошрифтную ссылку + Options.
6. Получаем в ответ что-то вроде

ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

сем. Вычёркивам нахуй этот сучий гонорежим NO_ZERO_DATE.
8. Выполняем что-то вроде

SET GLOBAL sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

девить. Пишем пост в интернете про это блядство.
10. Охуеваем от того, что wordpress превращает вручную набранные цифры в списки и сбрасывает блядскую нумерацию, ведь до этого момента такого никогда еще не происходило. Ни разу.
11. Понимаем, что вести войну с вордпрессом нет уже ни сил, ни времени, ни желания.
12. Идём отвечать на 45 пропущенных звонков и 194 новых письма, накопившихся, пока мы исправляли этот внезапно свалившийся на голову дятлоебизм.

sudo nano /etc/ssh/ssh_config

Comment out the following lines

#GSSAPIAuthentication yes
#GSSAPIDelegateCredentials no

OR

sudo nano /etc/ssh/sshd_config

UseDNS no
UsePAM no # (Pluggable Authentication Modules)
PasswordAuthentication no # Heckers slow down the shits and create huge logs with continous bruteforce.

 
You need to use `-t` option in `ssh` to assign a pseudo-terminal to `ssh` session:

    ssh -q -t root@server 'bash test.sh'
I have a script on my server named `test.sh`:

    #!/bin/bash
    read -p "Select an option [1-4]: " option
    echo "You have selected $option"

When I run it through ssh manually, I see this:

    me@me:~$ ssh root@server
    root@server's password:
    [...]
    root@server:~# bash test.sh
    Select an option [1-4]: 48
    You have selected 48

When I run it as ssh remote command, I see this:

    me@me:~$ ssh root@server 'bash test.sh'
    root@server's password: 
    48
    You have selected 48

I am unsatisfied with this output because it's missing `Select an option [1-4]: ` prompt string and the original script which from has I derived `test.sh` contains a lot of interactive dialogue strings like this and I need them all.

I know that `read` prints it's prompt to `stderr` so I tried to start the script with following commands in case if stderr is omitted, but the output stays still the same:

    ssh root@server 'bash test.sh >&2'
    ssh root@server 'bash test.sh' >&2
    ssh root@server 'bash test.sh 2>&1'
    ssh root@server 'bash test.sh' 2>&1

Why this is happening and how to make ssh remote command work as expected?

https://stackoverflow.com/questions/45838637/ssh-remote-command-not-working-as-expected-problems-with-read
linux - ssh remote command not working as expected (problems with read) - Stack Overflow

 

Также испытывал проблемы из-за локали, не позволявшие запустить i2pd, однако их удалось преодолеть:

root@raspberrypi:~# i2pd
12:28:11@33/info - Log: min messages level set to info
12:28:11@33/info - i2pd v2.14.0 starting
12:28:12@33/info - Daemon: bandwidth set to 'low'
12:28:12@33/info - Daemon: using system limit in 65536 max open files
12:28:12@33/info - Daemon: starting NetDB
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Aborted

root@raspberrypi:~# locale-gen en_US en_US.UTF-8
Generating locales (this might take a while)...
  en_GB.UTF-8... done
Generation complete.

root@raspberrypi:~# locale-gen ru_RU ru_RU.UTF-8
Generating locales (this might take a while)...
  en_GB.UTF-8... done
Generation complete.

root@raspberrypi:~# dpkg-reconfigure locales
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
  LANGUAGE = (unset),
  LC_ALL = (unset),
  LC_PAPER = "ru_RU.UTF-8",
  LC_ADDRESS = "ru_RU.UTF-8",
  LC_MONETARY = "ru_RU.UTF-8",
  LC_NUMERIC = "ru_RU.UTF-8",
  LC_TELEPHONE = "ru_RU.UTF-8",
  LC_IDENTIFICATION = "ru_RU.UTF-8",
  LC_MEASUREMENT = "ru_RU.UTF-8",
  LC_TIME = "ru_RU.UTF-8",
  LC_NAME = "ru_RU.UTF-8",
  LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory
Generating locales (this might take a while)...
  en_GB.UTF-8... done
  ru_RU.UTF-8... done
Generation complete.

root@raspberrypi:~# i2pd
12:38:13@456/info - Log: min messages level set to info
12:38:13@456/info - i2pd v2.14.0 starting
12:38:13@456/error - router.info is malformed. Creating new
12:38:14@456/info - Daemon: bandwidth set to 'low'
12:38:14@456/info - Daemon: using system limit in 65536 max open files
12:38:14@456/info - Daemon: starting NetDB
12:38:14@456/warn - Family: Can't load family certificates from /root/.i2pd/certificates/family
12:38:14@456/error - Family: 347f69139bc02660c00fb9694c7561a382d6a637708638f3480306482d233ba0 is too long
12:38:14@456/warn - RouterInfo: family signature verification failed
12:38:14@456/info - NetDb: 174 routers loaded (129 floodfils)
12:38:14@456/info - Daemon: starting Transports
...

Несмотря на преодолимость, было бы весьма хорошо, если бы успешный запуск программы не зависел от этого фактора.
https://github.com/PurpleI2P/i2pd/issues/498

 

I've got new web server with proftpd onboard. The problem is I can't connect to it through filezilla FTP client because it gives me an error

Status: Connection established, waiting for welcome message...
Response: 220 FTP Server ready.
Command:  AUTH TLS
Response: 234 AUTH TLS successful
Status: Initializing TLS...
Error:  Received TLS alert from the server: Handshake failed (40)
Error:  Could not connect to server

I found that the error corresponds to the proftpd log /var/log/proftpd/tls.log/var/log/proftpd/tls.log record:

Jul 24 13:50:47 mod_tls/2.4.2[1572]: unable to accept TLS connection: protocol error: 
  (1) error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

Which means that the ftp client supports none of the encryption algorythms proposed by the server. As a result, the connection fails.

I have also found a TLSCipherSuite directive in /etc/proftpd.conf that disables ADH, DES, SSLv2 and SSLv3 ciphers.

TLSCipherSuite                 ALL:!ADH:!DES:!SSLv2:!SSLv3

When I remove :!SSLv3 from the directive and restart the server, filezilla connects without any problems. But enabling SSLv3 seems to be a bad idea because it is vulnerable and insecure, according to the http://disablessl3.com/

Question

So my question is what can I do to make proftpd provide at least one secure cipher to successfully negotiate with filezilla FTP client?

Additional note

There is a similar question https://superuser.com/questions/874981/recieved-tls-alert-from-the-server-handshake-failed-40 that tells

Use only plain FTP (insecure)

but I want connection to be secure thus the answer for me is unsuitable.

Additional note #2

List of available ciphers:

[root@server ~]# openssl ciphers -v 'ALL:!ADH:!DES:!SSLv2:!SSLv3'
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA256
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA256
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256

The root of problem was an absence of TLSProtocol directive in /etc/proftpd.conf. Default value is TLSv1 and it prevents usage of TLSv1.2.

I have added

  TLSProtocol                   TLSv1.2

to /etc/proftpd.conf, restarted the server and the problem was solved.

https://forum.filezilla-project.org/viewtopic.php?f=2&t=45829&p=157134#p157134
http://www.proftpd.org/docs/contrib/mod_tls.html#TLSProtocol

Although it solved my case, it is also recommended to use

  TLSProtocol                   ALL -SSLv3

instead.

https://forum.filezilla-project.org/viewtopic.php?p=157135#p157135

Received TLS alert from the server: Handshake failed (40) - FileZilla Forums-2

ProFTPD module mod_tls

Disable SSLv3

ftp - Received TLS alert from the server: Handshake failed (40) - Super User