Forum Turris
Fórum Turris Nápověda

Milí majitelé routerů Turris,

toto fórum bylo 9. 12. 2016 zmrazeno a nahrazeno naším novým Turris fórem. Ještě chvíli bude dostupné k prohlížení, ale již zde není možné přispívat. Více informací naleznete v oznámení o uzavření fóra.

Dear Turris routers users,

this forum has been frozen on Dec 9th, 2016 and replaced by our new Turris forum. It will be read-only accessible for some time after. For more information, read the announcement about closing the forum.

Nahoru Téma Majitelé routerů / Technická podpora / Opakované aktualizace/oznámení o aktulizacích
- - Od Eskymák (>) Dne 2015-10-12 08:45
Zdravím,

Snad každý den mi chodí od Turrisu následující oznámení o aktualizacích. Router jsem pochopitelně několikrát restartoval, je asi dva týdny po obnovení do továrního nastavení společně s přeflashováním na nejnovější OS z image. Co s tím?

##### Oznámení o aktualizacích #####
• Nainstalovaná verze 0.1-3 balíku libnl-tiny
• Nainstalovaná verze 2.0.1-1 balíku libexpat
• Nainstalovaná verze 3.8.1-7 balíku logrotate
• Nainstalovaná verze 5.1.5-1 balíku liblua
• Nainstalovaná verze 7.6-1 balíku libwrap
• Nainstalovaná verze 1.0.6-1 balíku bzip2
• Nainstalovaná verze 0.9.33.2-1 balíku librt
• Nainstalovaná verze 0.9.33.2-1 balíku libpthread
• Nainstalovaná verze 5.1.5-1 balíku lua
• Nainstalovaná verze 6 balíku vixie-cron
• Nainstalovaná verze 8.11-2 balíku libpcre
• Nainstalovaná verze 1.4.27-1 balíku msmtp
• Nainstalovaná verze 1.7-5 balíku libpopt
• Nainstalovaná verze 0.9.33.2-1 balíku libc
• Nainstalovaná verze 0.2.9-2 balíku libeventlog
• Nainstalovaná verze 0.11-2 balíku libjson-c
• Nainstalovaná verze 1.0.6-1 balíku libbz2
• Nainstalovaná verze 10 balíku swconfig
• Nainstalovaná verze 17 balíku libatsha204
• Nainstalovaná verze 0.8.3-3 balíku libdbi
• Nainstalovaná verze 8.16-1 balíku coreutils-base64
• Nainstalovaná verze 1.2.8-1 balíku zlib
• Nainstalovaná verze 20 balíku mtd


Předchozí email pro porovnání, nevidím však žádný rozdíl.

##### Oznámení o aktualizacích #####
• Nainstalovaná verze 0.1-3 balíku libnl-tiny
• Nainstalovaná verze 2.0.1-1 balíku libexpat
• Nainstalovaná verze 3.8.1-7 balíku logrotate
• Nainstalovaná verze 5.1.5-1 balíku liblua
• Nainstalovaná verze 7.6-1 balíku libwrap
• Nainstalovaná verze 1.0.6-1 balíku bzip2
• Nainstalovaná verze 0.9.33.2-1 balíku librt
• Nainstalovaná verze 0.9.33.2-1 balíku libpthread
• Nainstalovaná verze 5.1.5-1 balíku lua
• Nainstalovaná verze 6 balíku vixie-cron
• Nainstalovaná verze 8.11-2 balíku libpcre
• Nainstalovaná verze 1.4.27-1 balíku msmtp
• Nainstalovaná verze 1.7-5 balíku libpopt
• Nainstalovaná verze 0.9.33.2-1 balíku libc
• Nainstalovaná verze 0.2.9-2 balíku libeventlog
• Nainstalovaná verze 0.11-2 balíku libjson-c
• Nainstalovaná verze 1.0.6-1 balíku libbz2
• Nainstalovaná verze 10 balíku swconfig
• Nainstalovaná verze 17 balíku libatsha204
• Nainstalovaná verze 0.8.3-3 balíku libdbi
• Nainstalovaná verze 8.16-1 balíku coreutils-base64
• Nainstalovaná verze 1.2.8-1 balíku zlib
• Nainstalovaná verze 20 balíku mtd
Nadřazený - - Od Michal Vaner (>>) Dne 2015-10-12 09:05
Dobrý den

Restartovat není potřeba a ani to s tímto nepomáhá. A ano, jsou stejné. Může za to chyba v hash-checkeru, který kontroluje, jestli se balíček nepoškodil. Přibyla do něj podpora pro více možných verzí hashů balíčku (což nastávalo jednorázově po reinstalaci), bohužel jsem to udělal špatně a vždycky si vybere tu špatnou místo té dobré. Ve vývojové verzi už to je opravené.

Nyní, co s tím. Měl bych následující možnosti:
* Ignorovat do dalšího update. Není to elegantní, ale rozhodně nejjednodušší.
* Vypněte celý hash checker ‒ nastavte updater.override.hash_url na hodnotu „-“ (pomlčka). Nebude prudit, ale ani opravovat poškozené balíčky.
* Nahraďte soubor /usr/bin/check-hashes.py verzí z https://gitlab.labs.nic.cz/turris/updater/blob/master/nand_check/check-hashes.py. Příští noc se sice vrátí stará verze toho skriptu, ale lokálně by si měla uložit tu správnou verzi hashů a přestat obtěžovat.
Nadřazený - Od Eskymák (>) Dne 2015-10-12 09:21
Díky za rychlou odpověď, využil jsem třetí možnosti nápravy. :-)
Nadřazený - - Od mkyral Dne 2015-10-16 06:33
A já si říkal, že mi na turris chodí mnohem více aktualizací než na gentoo. Akorát jsem si nevšiml, že jsou všechny emaily stejné ;-)

K tomu třetímu bodu - odkaz se mi nepodařilo stáhnout přímo na turrisu - wget i curl mají problém s https. Stáhl jsem to na svém počítači a na turris překopíroval.


turris /tmp # wget "http://gitlab.labs.nic.cz/turris/updater/blob/master/nand_check/check-hashes.py"
Connecting to gitlab.labs.nic.cz (217.31.192.88:80)
wget: not an http or ftp url: https://gitlab.labs.nic.cz/turris/updater/blob/master/nand_check/check-hashes.py

turris /tmp # curl "https://gitlab.labs.nic.cz/turris/updater/raw/master/nand_check/check-hashes.py"
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
turris /tmp # curl "http://gitlab.labs.nic.cz/turris/updater/raw/master/nand_check/check-hashes.py"


Když jsem to pak následně zkoumal, tak jsem zjistil, že /usr/bin/wget vede na busybox i když je dle databáze nainstalovaný plnokrevný wget. Pomohla až reinstalace wgetu.
Vypadá to, že aktualizace busyboxu si to přepsala podle sebe.


turris /tmp # ls -la /usr/bin/wget
lrwxrwxrwx    1 root     root            17 Oct  2 18:17 /usr/bin/wget -> ../../bin/busybox

turris /tmp # opkg --force-reinstall install wget
Removing package wget from root...
Installing wget (1.15-1) to root...
Downloading https://api.turris.cz/openwrt-repo/turris/packages//wget_1.15-1_mpc85xx.ipk.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  203k  100  203k    0     0  1120k      0 --:--:-- --:--:-- --:--:-- 1129k
Configuring wget.

turris /tmp # ls -la /usr/bin/wget
lrwxrwxrwx    1 root     root            10 Oct 16 07:25 /usr/bin/wget -> ./wget-ssl

turris /tmp # wget "https://gitlab.labs.nic.cz/turris/updater/raw/master/nand_check/check-hashes.py"
--2015-10-16 07:26:42--  https://gitlab.labs.nic.cz/turris/updater/raw/master/nand_check/check-hashes.py
Resolving gitlab.labs.nic.cz... 2001:1488:ac15:ff70::88, 217.31.192.88
Connecting to gitlab.labs.nic.cz|2001:1488:ac15:ff70::88|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: 'check-hashes.py'

    [ <=>                                                                                                                                                                                                                            ] 4,675       --.-K/s   in 0s

2015-10-16 07:26:42 (12.1 MB/s) - 'check-hashes.py' saved [4675]

turris /tmp #
Nadřazený - - Od Elty (>) Dne 2015-11-15 15:46
Stejný problém, vyřešeno podle vašeho návodu. Děkuji :wink:
Nadřazený - - Od JFila (>>) Dne 2015-12-15 16:48
Mám podobný problém, certifikáty mám, pokud ho ručně wgetu předhodím, tak se ověření zdaří. Pokud však předhodím cestu /etc/ssl/certs, tak u se to nepovede. Máte někdo tušení, kde může být problém?

root@Turris:/tmp# wget https://gitlab.labs.nic.cz
--2015-12-15 16:36:24-- https://gitlab.labs.nic.cz/
Resolving gitlab.labs.nic.cz... 2001:1488:ac16:ff70::88, 217.31.192.88
Connecting to gitlab.labs.nic.cz|2001:1488:ac16:ff70::88|:443... connected.
ERROR: cannot verify gitlab.labs.nic.cz's certificate, issued by '/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA':
Unable to locally verify the issuer's authority.
To connect to gitlab.labs.nic.cz insecurely, use '--no-check-certificate'.
root@Turris:/tmp# wget https://gitlab.labs.nic.cz --ca-directory=/etc/ssl/certs/
--2015-12-15 16:36:24-- https://gitlab.labs.nic.cz/
Resolving gitlab.labs.nic.cz... 2001:1488:ac16:ff70::88, 217.31.192.88
Connecting to gitlab.labs.nic.cz|2001:1488:ac16:ff70::88|:443... connected.
ERROR: cannot verify gitlab.labs.nic.cz's certificate, issued by '/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA':
Unable to locally verify the issuer's authority.
To connect to gitlab.labs.nic.cz insecurely, use '--no-check-certificate'.
root@Turris:/tmp# wget https://gitlab.labs.nic.cz --ca-certificate=/etc/ssl/certs/StartCom_Certification_Authority.crt
--2015-12-15 16:36:25-- https://gitlab.labs.nic.cz/
Resolving gitlab.labs.nic.cz... 2001:1488:ac16:ff70::88, 217.31.192.88
Connecting to gitlab.labs.nic.cz|2001:1488:ac16:ff70::88|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://gitlab.labs.nic.cz/users/sign_in [following]
--2015-12-15 16:36:26-- https://gitlab.labs.nic.cz/users/sign_in
Reusing existing connection to [gitlab.labs.nic.cz]:443.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 'index.html'

[] 9,992 --.-K/s in 0s

2015-12-15 16:36:26 (69.7 MB/s) - 'index.html' saved [9992]

root@Turris:/tmp# ls -la /usr/bin/wget
lrwxrwxrwx 1 root root 10 Dec 15 16:03 /usr/bin/wget -> ./wget-ssl

openssl s_client -connect seznam.cz:443 -debug -CAfile /etc/ssl/certs/thawte_Primary_Root_CA.crt
Verify return code: 0 (ok)

openssl s_client -connect seznam.cz:443 -debug -CApath /etc/ssl/certs/
Verify return code: 20 (unable to get local issuer certificate)
Nadřazený - - Od Ondřej Caletka (>>>) Dne 2015-12-15 17:34
Zkus zavolat # c_rehash /etc/ssl/certs/ pro znovuvytvoření symlinků na všechny certifikáty v daném adresáři – OpenSSL je hledá podle osmiznakového otisku, bez těchto symlinků je nenajde.
Nadřazený - - Od JFila (>>) Dne 2015-12-15 18:05
Děkuji za radu, bohužel stále stejný výsledek. Kde přesně mám hledat zmínění symlinky?

root@Turris:~# c_rehash /etc/ssl/certs/
Doing /etc/ssl/certs/
root@JFila:~# cd /tmp/
root@JFila:/tmp# wget https://www.seznam.cz
--2015-12-15 18:02:18--  https://www.seznam.cz/
Resolving www.seznam.cz... 2a02:598:2::1053, 77.75.79.39
Connecting to www.seznam.cz|2a02:598:2::1053|:443... connected.
ERROR: cannot verify www.seznam.cz's certificate, issued by '/C=US/O=thawte, Inc./CN=thawte EV SSL CA - G3':
  Unable to locally verify the issuer's authority.
To connect to www.seznam.cz insecurely, use `--no-check-certificate'.
Nadřazený - - Od Ondřej Caletka (>>>) Dne 2015-12-16 10:53
Problém se mi podařilo reprodukovat a workaroundovat.  Nejdřív trochu teorie: OpenSSL obecně dokáže hledat pevné body důvěry buď v souboru (kde jsou za sebou všechny PEM certifikáty, kterým má důvěrovat), nebo v adresáři (což je základní nastavení a tím adresářem je /etc/ssl/certs). Při hledání v adresáři neprochází všechny soubory, ale hledá certifikát podle jeho otisku. Proto musí být v adresáři takovéto symlinky:

# ls -l /etc/ssl/certs/
lrwxrwxrwx    1 root     root            29 Dec 16 10:22 024dc131.0 -> Microsec_e-Szigno_Root_CA.crt
lrwxrwxrwx    1 root     root            25 Dec 16 10:22 034868d6.0 -> Swisscom_Root_EV_CA_2.crt
lrwxrwxrwx    1 root     root            50 Dec 16 10:22 039c618a.0 -> TURKTRUST_Certificate_Services_Provider_Root_2.crt
…


K jejich vygenerování slouží utilita c_rehash, což je shell skript, kterému předáte cestu k adresáři a on projde všechny certifikáty, a vytvoří symlinky podle jejich hashů. Problém je v tom, že utilita c_rehash načítá pouze soubory s příponou pem, zatímco certifikáty z Debianu používají příponu crt. Jako jednoduchý workaround je možné v souboru /usr/bin/c_rehash na řádku 143 přidat za *.pem ještě *.crt. Pak by se po spuštění měly všechny certifikáty zahashovat:

_rehash /etc/ssl/certs/
Doing /etc/ssl/certs/
A-Trust-nQual-03.crt => 9c472bf7.0
ACCVRAIZ1.crt => a94d09e5.0
ACEDICOM_Root.crt => 381ce4dd.0
AC_Raíz_Certicámara_S.A..crt => 6f2c1157.0
Actalis_Authentication_Root_CA.crt => 930ac5d2.0
AddTrust_External_Root.crt => 157753a5.0
AddTrust_Low-Value_Services_Root.crt => 861a399d.0
AddTrust_Public_Services_Root.crt => 8b59b1ad.0
AddTrust_Qualified_Certificates_Root.crt => e536d871.0
AffirmTrust_Commercial.crt => 2b349938.0
AffirmTrust_Networking.crt => 93bc0acc.0
AffirmTrust_Premium.crt => b727005e.0
…

# wget https://www.seznam.cz
--2015-12-16 10:51:50--  https://www.seznam.cz/
Resolving www.seznam.cz... 2a02:598:a::79:53, 77.75.77.39
Connecting to www.seznam.cz|2a02:598:a::79:53|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 172571 (169K) [text/html]
Saving to: 'index.html'

100%[==============================================================>] 172,571     --.-K/s   in 0.02s  

2015-12-16 10:51:51 (9.85 MB/s) - 'index.html' saved [172571/172571]


Opravu skriptu c_rehash posílám jako pull request.
Nadřazený - - Od Michal Vaner (>>) Dne 2015-12-16 11:11
Dobrý den

Ono je to ještě maličko složitější. Utilita c_rehash, která jde společně s OpenSSL je totiž napsaná v perlu. Na desktopu to není problém, na routeru ale není vhodné přitáhnout celý perl kvůli takto malému skriptu. Původní řešení bylo nagenerovat symlinky při kompilaci. Ale to selhávalo kvůli kolizím mezi balíčky.

Shellový skript se mi povedlo objevit v gentoo a převzít ho. A při upgradu certifikačních autorit z debianu se z .pem staly .crt a nikoho nenapadlo zkontrolovat i ten skript z gentoo.

Každopádně, za objevení problému i řešení děkujeme, bude k dispozici snad už tento pátek.
Nadřazený - Od JFila (>>) Dne 2015-12-16 17:02
Děkuji všem zúčastněným, po přidání přípony už generování funguje správně.
Nahoru Téma Majitelé routerů / Technická podpora / Opakované aktualizace/oznámení o aktulizacích

Powered by mwForum 2.29.3 © 1999-2013 Markus Wichitill