Благодаря за темата - и аз вече бях почнал да се притеснявам, че правя някакви странни неща, с които никой не се е сблъсквал (с др. думи - глупости)
Последните 1-2 седмици ми се наложи да се занимавам с OpenBSD и по-конкретно подкарването на IKEV2/IPSEC тунел със StrongSWAN в другия край - повече инфо по темата е от преди годинии съответно не е актуална.
И напълно съм съгласен с това, което сте коментирали по-горе....

Здравейте,

Аз също съм във Варна, така че ако се заформи нещо, ме бройте 

Я раздухай от съвременните принтери, кои най се подават на зареждане? HP?
Brother гледам много ги рекламират.

Аз от 5-6 години ползвам 2 НР-та: M1212nf_MFP § MFP_M127fn и нямам никакви грижи нито със зареждането на касетите, нито с машините като цяло. Преди това брах ядове с едни Xerox-и и повече не бих повторил от тях.

Така и не успях да се преборя със systemd и си реших проблема с два скрипта за network-manager:

Код:

#cat /etc/NetworkManager/dispatcher.d/02vpnup

#!/bin/sh -e

IFACE=$1
ACTION=$2

if [ "$IFACE" = "tun0" ] && [ "$ACTION" = "vpn-up" ]; then
logger "VPNUP: VPN IS GOING UP, MOUNTING STORAGES";
for MOUNT in storage storage2; do
if ! /bin/mountpoint -q /mnt/$MOUNT; then
/bin/mount /mnt/$MOUNT;
else
/bin/mount -o remount /mnt/$MOUNT;
fi
done
fi

exit 0;

Код:

#cat /etc/NetworkManager/dispatcher.d/pre-down.d/01vpndown

#!/bin/sh -e

IFACE=$1
ACTION=$2

#DEFAULT ROUTE INTERFACE
DEFAULT_IFACE=`/bin/ip route ls |grep '^default' |cut -d " " -f 5`;

if ([ "$IFACE" = "tun0" ] && [ "$ACTION" = "vpn-pre-down" ]) || ([ "$IFACE" = "$DEFAULT_IFACE" ] && [ "$ACTION" = "pre-down" ]); then
logger "VPNDOWN: VPN OR DEFAULT ROUTE IFACE IS GOING DOWN, UNMOUNTING STORAGES";
for MOUNT in storage storage2; do
if ! /bin/umount --force --lazy /mnt/$MOUNT >/dev/null 2>&1 1>&0; then
logger "VPNDOWN: FAILED TO UMOUNT $MOUNT";
fi
done
fi

exit 0;

Привет,

Преди време бях питал в друга тема подобен въпрос, но реших, че е минало доста време оттогава и по-добре да създам нова дискусия.
Става дума за редът, по който се викат/изпълняват systemd услугите. Имам монтирани няколко мрежови файлови системи (cifs), които обаче са достъпни само при работещ VPN (openvpn). Целта на моя service, който се опитвам да направя, е той да се изпълнява *преди* спирането на VPN-a (настроен е през network-manager), когато системата се спира, рестартира, приспива  и да размонтира отдалечените файлови системи. Ето как изглежда един вариант на service-a

Код:

[Unit]
Description=Umount network file systems
After=network-online.target openvpn-client.service
Requires=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/default/umounts.conf
ExecStart=-/bin/umount $OPTIONS -t $FILESYSTEMS
ExecStop=-/bin/umount $OPTIONS -t $FILESYSTEMS

[Install]
WantedBy=multi-user.target network-online.target openvpn-client.service

За съжаление, когато приспивам машината (suspend) не всички отдалечени файлови системи се разкачат, а само 1, или 2. Предполагам systemd не изчаква достатъчно и затова се получава така. Проблемът не е в командата, която прави размонтирането:
ExecStop=-/bin/umount $OPTIONS -t $FILESYSTEMS
Когато я изпълня само нея всичко се разкача, както и се очаква.

Проблемът според мен е в реда на спиране на услугите при shutdown, suspend ... etc Засега тествам само със suspend, защото е най-удобно и бързо, но и при рестартиране, или гасене положението е аналогично.

От личен опит бих те посъветвал да се насочиш към редактиране на PDF файловете, вместо конвертирането им към друг формат - доста съм се занимавал, вкл. и с libre/open office, и резултатът никога не си е струвал.
За линукс ти препоръчвам да пробваш с Master PDF Editor https://code-industry.net/. Има и други варианти, но не са много и според мен не са толкова функционални. За уиндоус вариантите са значително повече, но там не мога да ти помогна.

Дай да видим какво си настроил в sip.conf

Работата с шифрите не е действие на openconnect, а на gnutls/openssl. Малко ми е съмнително проблемът ти да е от няколко дни, тъй като не виждам някое от тези обновления да включва промяна по въпроса, но може и да пропускам нещо или пък системата ти да не е била обновявана отдавна. Както и да е.
Единият вариант е да downgrade-неш до версии, при които отново ще ти работи (от /var/log/dpkg.log и наличните пакети във /var/cache/apt/archives можеш да се ориентираш какво кога и с какво се е надградило).
Другият вариант е да прекомпилираш openconnect с флаг да ползва openssl, вместо gnutls (изглежда, че openssl-ът ти се разбира с RC4-MD5).
А най-добрият вариант е да се превключи към друг шифър на въпросното Cisco (предполагам някаква ASA?), но... при тези Cisco и при липсата ти на достъп това може да се окаже непосилна задача.

neter, благодаря за помощта!

Проблемът със сигурност е от 15-20 дни и преди това ВПН-а работеше. Сещам се обаче, че причината за проблема може да не е в ъпгрейд минал при мен, а промяна в конфигурацията, или ъпгрейд на отдалеченото CISCO. Както казах, нямам достъп до него, само мога да пиша на админите, но ми се струва доста "оптимистично" да реагират

За openconnect си прав - компилиран е с gnutls, който явно не поддържа въпросния шифър:

Код:

gnutls-cli --list |grep -i md5

TLS_RSA_NULL_MD5                                  0x00, 0x01 SSL3.0
TLS_RSA_ARCFOUR_128_MD5                            0x00, 0x04 SSL3.0
TLS_DH_ANON_ARCFOUR_128_MD5                        0x00, 0x18 SSL3.0
MACs: SHA1, MD5, SHA256, SHA384, SHA512, SHA224, UMAC-96, UMAC-128, AEAD
Digests: SHA1, MD5, SHA256, SHA384, SHA512, SHA224
PK-signatures: SIGN-RSA-SHA1, SIGN-RSA-SHA1, SIGN-RSA-SHA224, SIGN-RSA-SHA256, SIGN-RSA-SHA384, SIGN-RSA-SHA512, SIGN-RSA-RMD160, SIGN-DSA-SHA1, SIGN-DSA-SHA1, SIGN-DSA-SHA224, SIGN-DSA-SHA256, SIGN-RSA-MD5, SIGN-RSA-MD5, SIGN-RSA-MD2, SIGN-ECDSA-SHA1, SIGN-ECDSA-SHA224, SIGN-ECDSA-SHA256, SIGN-ECDSA-SHA384, SIGN-ECDSA-SHA512

Ще разгледах history.log на apt  да видя какви ъпдейти са минали напоследък (ъпдейтвам се почти ежедневно) и мога ли да се върна към стара версия на openconnect или gnutls, а ако не стане ще компилирам върху openssl явно.

Здравейте,

Имам проблем с openconnect - версия 7.06-2+b2 в текущия Debian sid. Ползвам го чрез плъгина за network-manager в gnome, но това е без значение, защото и при директно извикване резултатът е същия, а  именно:

Код

GeSHi (Bash):
POST https://*.*.*.*/
Attempting to connect to server *.*.*.*:443
SSL negotiation with *.*.*.*
SSL connection failure: A TLS fatal alert has been received.
Failed to open HTTPS connection to *.*.*.*
 

Ползвайки клиентът на openssl, за да тествам отсрещната страна (някакво CISCO, до което нямам достъп) получавам следното:

Код

GeSHi (Bash):
No client certificate CA names sent
---
SSL handshake has read 703 bytes and written 497 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID: 8529A69EC827DD492E4B0036A2FF3FC7F7FE4521867705BBBBAFBEE54D021E3B
    Session-ID-ctx: 
    Master-Key: 9FCE53E33CC4B33D308768E038DFFEE757F1F83B8249B0B1CBFFA3182F75AD525471BD66336366328993C95736C2EA78
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1455557262
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
 

В същото време, при преглеждане на мрежовия трафик (wireshark), когато се опитвам да се закача с openconnect виждам това в SSL Client HELLO (ssl.handshake.ciphersuites):

Код:

Cipher Suites (54 suites):
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
....

Не ги изреждам всичките, но по-важното е, че липсва RC4-MD5.

Ако се ориентирам правилно, CISCO-то отсреща предлага шифър, който openconnect не поддържа и това осира връзката. Въпросният шифър е набеден за несигурен и затова сигурно openconnect не го ползва, но все пак дали няма начин да го накарам да го "хареса" отново, защото нещата си работеха нормално допреди няколко дни. Предполагам е минал ъпдейт, който е променил openconnect.
Не можах и да се ориентирам какво ползва openconnect - openssl, gnutls ...

Така зададено условието не е съвсем коректно според мен - кои права за четене и запис се има впредвид, на собственика на файла, на групата на собственика, или всички останали?

Може да погледнеш как се работи с find: http://man7.org/linux/man-pages/man1/find.1.html

Здравейте,

Нямам достъп до Cisco-то, то е при клиент и ще си говоря с техните админи дали може да се направи нещо.
Това, което BRADATA е дал е най-вероятният проблем, защото след като се закача за Cisco услугата, MTU на интерфейс vpn0 е 1500. След като го сложа на 1400, нещата работят:

Код:

ip link set vpn0 mtu 1400

Здравейте,

Ползвам openconnect в текущия нестабилен Дебиан, за да се закачам за anyConnect услуга на Cisco. Доскоро всичко работеше добре, но от известно време се получава проблем - ВПН–ът се закача и работи нормално, докато не стартирам нещо, което да прекара трафик през него. Тогава връзката дропва и в логовете  имам това:

Код:

Aug 28 12:59:19 localhost openconnect[9820]: DTLS handshake failed: Resource temporarily unavailable, try again.
Aug 28 12:59:20 localhost openconnect[9820]: Unexpected packet length. SSL_read returned 1414 but packet is
Aug 28 12:59:20 localhost openconnect[9820]: 53 54 46 01 05 9e 00 00
Aug 28 12:59:20 localhost openconnect[9820]: Unknown packet ff ff 24 92 92 48 ff ff
Aug 28 12:59:20 localhost openconnect[9820]: Send BYE packet: Unknown packet received
Aug 28 12:59:20 localhost openconnect[9820]: Unknown error; exiting.

Ако пусна само пинг, примерно, до някой от хостовете, получавам отговори и всичко е ОК. Ако монтирам шерната папка от някой хостовете (cifs, всички машини са с windows), също няма проблем. Ако обаче опитам да достъпя точката, където е монтиран шеринга - връзката се разпада с горната грешка.

В нета не намирам нищо, освен сорсове, които не ми помагат особено да разбера къде е проблема.

Под уиндоус всичко работи без проблеми.

Следих трафика с wireshark, но не съм в час с този вид комуникация и не знам какво точно да гледам, честно казано. Ако някой даде насока за това, мога да покажа резултат от wireshark.

Ето версиите на openconnect, които са инсталирани:

Код:

dpkg -l *openconnect*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                  Version                 Architecture            Description
+++-=====================================-=======================-=======================-===============================================================================
rc  libopenconnect3:amd64                 6.00-2                  amd64                   open client for Cisco AnyConnect VPN - shared library
ii  libopenconnect5:amd64                 7.06-2+b1               amd64                   open client for Cisco AnyConnect VPN - shared library
ii  network-manager-openconnect           1.0.2-1+b1              amd64                   network management framework (OpenConnect plugin)
ii  network-manager-openconnect-gnome     1.0.2-1+b1              amd64                   network management framework (OpenConnect plugin GNOME GUI)
ii  openconnect                           7.06-2+b1               amd64                   open client for Cisco AnyConnect VPN

Поздрави!

Видео-урок на руски език, ще ти свърши ли работа?

Не разбирам руски и видео уроци не гледам, но дай все пак, не вярвам да не го разбера

Никой ли няма идея, в темата за обсъждане на systemd останах с впечатление, че има доста разбиращи във форума

Тествах на РНР 5.5.* и там файлът се разпозна правилно. На същата система обаче системната file е по-стара версия (5.18, на моята машина е 5.20), който пък казва, че файлът е "application/octet-stream; charset=binary" 
В същото време модерните браузъри, поддържащи HTML5 File API, се справят доста добре със задачата за познаване на MIME типа (ползват https://mimesniff.spec.whatwg.org/).
В кр. сметка решението, което направих за мен, е комбиниране на трите (различни) резултата, от finfo, file & browser, и така избиране на "подходящ" mime.