Cron.d syslog-ng.d a logrotate.d configy ---- par Maxovejch poznamek a postrehu

[Maxmilian_Picmaus]

Jelikoz tu nedavno probehlo par dotazu ohledne firewallu a distribuovanych pravidel. Tak jsem trosku bloumal po filesystemu a dumal nad zaznamy z logu … prislo mi na mysl par otazek a poznamek a tak nejak jsem se chtel i podelit trosku oz slasti a strasti s cronem a logovani a tak vubec …

V podstate o nic moc nejde, mozna se v tom jen moc stouram …

1. v jiste okamziky se mi stava, ze proste nedojde ke stazeni niceho pri stahovani firewall pravidel .
   Je mi jasne, ze cas od casu se proste nedoboucham (jestli v danou chvili se snazi dobouchat vicero uzivatelu…>pozn1). Ale tak nejak jsem bloumal a po foru a je velmi pravdepodobne, ze cron.d pusti v jisty okamzik vicero procesu a nektere jsou ocividne na sobe zavisle. Napada me nethist, fw-rules, haas, get-api … (registrace pro haas asi nebude problem, ale par uzivatelu melo/ma pridany pravidelny restart, kvuli narustajici zatezi od HaaSu a par uzivatelu zminovalo, ze jim pomohlo posunout to o par minut). A je taky otazkou je-li to restartovani jeste nutnost (prozatim jsem to vypnul a uvidime jestli zatez naroste nebo ne).

pozn1

jen me tak napadlo, kdyz ma vetsina uzivatelu nastavene crony stejne, neni to pak urcity napor na Turris servery v tyto casy? Coz mozna i zpusobuje, ze se nekdo proste v te zapce nedoboucha. Nebylo by dobre to nejak spojit v logicke skupiny. Eventualne da se to nejak randomizovat:

30 8-21/* * * * sleep $[RANDOM\%90]m ; /path/to/script.php

Casy v cron.d jsem soupnul aby nebylo moc procesu co bezi v celou. >pozn2
Uvidime jak se to bude chovat.

pozn2

Podobne jsem kdysi presunul i cas pro nikolu a logrotate. Dle me neni treba 4x za hodinu ale staci 3x nikolu a kazdou pulhodinu orotovat logy. (jelikoz nikola pousti logrotate a logrotate otaci celej syslog-ng, tak me to nejak sem tam haprovalo u ‘iptables’ ze se prestal plnit, nebo se vubec neorotoval.
A i server-uplink mel oba tasky kazdou ctvrthodinu ale bohuzel registrace nekdy mela zpozdeni a validace jeste nemela co validovat.

2. tahle zprava se opakuje uz nejaky patek.
   info turris-firewall-rules[]: (v64) 3524 ipv4 address(es) and 3 ipv6 address(es) were loaded (c83b72d5b03454292e5000b3967bc350), 0 rule(s) overriden, 0 rule(s) skipped
   Tak nejak mi vrta hlavou proc je pocet ipv4 a ipv6 adres stejny. Je to tak okej a nebo pocty nekdy zmeni? Vsimnul jsem si po foru, v ruznych dumpech logu, ze takovou zpravu maji i ostatni.

3. po poslednim updejtu mi pristal novy soubor
   /etc/cron.d/diagnostics-country-check
   Nechapu proc ma nezvykle nastaveny chmod (execute pro vsechny).

Nejak jsem si rikal, ze to je asi jen nejaky pomocnik, tak jsem ho rovnou smazal. Nasledne foris mi zahlasil, ze si mam poresit nastaveni regionu/casu a u wifi zemi. (coz jsem promptne udelal).
Pak jsem resil jak dohledat ten cron.d fajl (nakonec jsem stahnul posledni medikit a vyzobnul si ho z toho).

Je tento checker potrebny a nebo ho muzu deaktivovat ?

4. cron je celkem ukecanej a messages je preplnenej infem od cronu ze neco pustil.
   Neda se nejak nastavit aby to prestal hlasit.
   Mam nastaveno …
   option conloglevel '4' , zkousel jsem i nizsi …
   option cronloglevel '9', pricemz jak chapu 8 je jen info o spusteni nejake ulohy a 9 by mela hlasit jen errory.
   zkusil jsem pridat i klogconloglevel jestli nebude prubojnejsi obecne (nebyl). >pozn3

pozn3

Ono je vubec otazkou esli tohle nastaveni neni aktivni jen kdyz clovek loguje na vzdaleny server. Kdyz jsem kdysi zkusil zadat cestu k lokalnimu fajlu, zadnej se nevytvoril. Coz je asi normalni, kdyz syslog-ng se stara o dmesg a logovani do messages.

A ted resim jestli jde jednoduse nastavit pres uci aby messages lgoval jen warn/err/critical obecne. A cron hlasil jen errory, aniz bych zasahoval do syslogu/ulogd/logrotate

Jsem si vedom, ze muzu udelat filter pro syslog-ng a supresnout prislusny message level.

Ale kdyz jsem to zkousel narazil jsem na problemy s f_turris_iptables , kdy to filtruje ‘ne-iptables’ veci a nikola.conf je zas ‘jen-iptables’ veci. Kdyz jsem do toho sahnul (upravil level v not-match filtru, ci pridal svuj filtr), tak to pak logovalo moc a nebo vubec bud v tom ci onom logu. Kdyz uz jsem to nejak zprovoznil, po prvnim behu nikoly se to sesypalo a ja neprisel na to v cem je zadrhel.Takze jsem pokorne udelal rollback a moc doto nesaham.

Me prijde, ze by mozna bylo lepsi tu logiku filtru pro iptables v syslog-ng.conf otocit a zaroven separovat veci kolem iptables do toho .d configu. Ale na to si jeste netroufam, pri cteni dokumentace pro syslog-ng jsem dospel k nazoru, ze jde udelat nekolika zpusoby a ja si nejsem jistej, kterej je ten spravnej/vhodnej pro TOS implementaci. Zvlast s prihlednutim k pripadnym updejtum ci migraci z 3.x na 5.x

[Maxmilian_Picmaus]

@Maxmilian_Picmaus

A ted resim jestli jde jednoduse nastavit pres uci aby messages lgoval jen warn/err/critical obecne. A cron hlasil jen errory, aniz bych zasahoval do syslogu/ulogd/logrotate

Tak pres uci a ani jinak se mi to nepodarilo … takze nakonec se mi po nekolika pokusech podarilo pridat filter f_cron {not facility("cron");}; a v log casti filter(f_cron); filter(f_turris_iptables); v syslog-ng.conf a zda se, ze to zabralo. Ted jen jeste upravit aby propoustelo errory…

[Maxmilian_Picmaus]

@Maxmilian_Picmaus

po poslednim updejtu mi pristal novy soubor
/etc/cron.d/diagnostics-country-check
Nechapu proc ma nezvykle nastaveny chmod (execute pro vsechny).

myslim si , ze mam country nastavenou od zacatku dobre. Ale script neustale hlasi ze je problem (kdyz provedu kroky v instrukcich co prijdou v notifikaci tak se vlastne nic nezmeni a jen se otoci sluzba pro sit) , a kdyz dojde k takovemu checku, tak me pak wifiny nechtej znovu pripojit po vyprseni lease time (coz me tak trosku s prominutim sere).

Da se tento diag script vypnout ?(kdyz smazu prislusny cron task, tak to stejne hlasi uplne to same — kde muzu nejak v uci nastavit , hotovo neres, nekontroluj…?)

EDIT: cron.d soubor jsem maznul a prislusnej script prejmenoval a sebral mu execute prava, snad to bude stacit

[petrprochy]

Koukal jsem na ten skript a je v něm chyba. Skončí s touto chybou:

root@turris:~# /usr/share/diagnostics/country-check.sh
Usage: uci [<options>] <command> [<arguments>]

Commands:
        batch
        export     [<config>]
        import     [<config>]
        changes    [<config>]
        commit     [<config>]
        add        <config> <section-type>
        add_list   <config>.<section>.<option>=<string>
        del_list   <config>.<section>.<option>=<string>
        show       [<config>[.<section>[.<option>]]]
        get        <config>.<section>[.<option>]
        set        <config>.<section>[.<option>]=<value>
        delete     <config>[.<section>[[.<option>][=<id>]]]
        rename     <config>.<section>[.<option>]=<name>
        revert     <config>[.<section>[.<option>]]
        reorder    <config>.<section>=<position>

Options:
        -c <path>  set the search path for config files (default: /etc/config)
        -d <str>   set the delimiter for list values in uci show
        -f <file>  use <file> as input instead of stdin
        -m         when importing, merge data into an existing package
        -n         name unnamed sections on export (default)
        -N         don't name unnamed sections
        -p <path>  add a search path for config change files
        -P <path>  add a search path for config change files and use as default
        -q         quiet mode (don't print error messages)
        -s         force strict mode (stop on parser errors, default)
        -S         disable strict mode
        -X         do not use extended syntax on 'show'

Kouknul jsem přímo do toho skriptu a na řádku 55 je chyba ve volání uci. Opravil jsem to na uci -q get 'system.@system[0]._country' (prohodil jsem -q a get v parametrech) a pak už funguje správně.

A vypadá to, že pokud v /etc/cron.d/ je soubor jako spustitelný, tak cron tuto konfiguraci přeskočí. Když jsem sundal atribut execute, tak se ten script naplánoval a mail mi taky dorazil.

Bude to chtít nahlásit někomu z Turris týmu, aby ten skript a konfiguraci opravili.

[Maxmilian_Picmaus]

@petrprochy

Bude to chtít nahlásit někomu z Turris týmu, aby ten skript a konfiguraci opravili.

@vojtech.myslivec koukam na gitlab, ze asi budes autorem, sic mi chvilku mi trvalo najit cznic/turris-diagnostics/files/country-check.sh · v3.11.19.1 · Turris / Turris OS / Turris OS packages · GitLab , jelikoz se s gitem jeste seznamuju (predchvilkou jsem se registroval, netroufam si udelat/navrhnout tu zmenu sam.)

[vojtech.myslivec]

Diky za upozorneni. Ano, je tam chyba. Bylo to otestovane pouze na modrem Turris 1.x, kde uci get -q funguje, ale na Omnii ne spravne je to samozrejme uci -q get.

Oprava je pripravena a bude v dalsim vydani turris/turris-os-packages!563.