Linux-haladó

Sziasztok!

Adott egy Zentyal 3.4.8 rendszeren alapuló levelező szerver / tűzfal, amit pár éve vettem át üzemeltetésre.

A szerverben márciusban cseréltem merevlemezeket, mert a raid tömb raid 10-ben volt 2 hdd-vel, illetve egyéb problémák is voltak, de annak érdekében, hogy minden ugyanúgy üzemeljen , a beállításokat kiexportáltam, és ugyanazt a 3.4.8-at tettem fel, hogy a beállításokat vissza tudjam importálni.

Ez így rendben is volt, megtörtént a telepítés, ezt követően spamassasint behangoltam és elfogadhatóan üzemelt, egészen július elejéig, amikor rögzítettem a rendszerben további 2 e-mail fiókot, így összesen már 60 fiók van a rendszerben.

A 2 fiók üzemelt különösebb gondok nélkül, aztán a dovecot pár naponta eldobta a bejövő imap-loginokat az alábbi üzenetre hivatkozva:

dovecot: master: Warning: service(imap-login): process_limit (100) reached, client connections are being dropped.

Próbáltam már többféle, más fórumokon talált / ajánlott megoldásokkal átírni a default process limitet, de végeredményben mindig maradt a 100-as érték.

A frissítés sajnos nem opció, mert tesztkörnyezetben összeomlott a zenytyal update közben / után, mint a kártyavár.

Gondoltam megkérdezem, hátha itt futott már bele hasonló problémába, zentyallal kapcsolatosan, mert végső soron arra jutottunk, hogy a zentyal felülírja az egyéni dovecot configokat, vagy legalábbis a fő beállításokat.

A válaszokat és a segítséget előre is köszönöm!

Udv,

A linuxos ipsec-tools aka. RACOON ugye mar unmaintained lett, nem fejlesztik evek ota, es mar a patchelese is abbamaradt. Kb annyit irnak mindenhol, hogy hasznaljak mast helyette.

De mit? :)   Mi szamit manapsag standard ipsec implementacionak linuxon?

Vannak a SWAN forkok, libreswan, openswan, strongswan, freeswan meg mittomenmilyenswanok. Eleg zavaros mi a kulonbseg koztuk, a licenszelesen kivul. Melyiket mennyire fejlesztik, supportaljak meg?

A'rpi

ps: nem, openvpn nem jo. meg mas vpn megoldas sem erdekel, mert mas cegek enterprise tuzfalaival kell ipsec-et beszelni, ebbe nincs beleszolasom.

Sziasztok!

Biztosan figyelmetlen vagyok, de lelkem rajta sok időmet felemésztette, mielőtt kérdezek:
Nem tudom beállítani, hogy egy frissítés után felülírt Dockerben futó Nextcloudban feltöltendő fájl méretét. Igen, elvileg egyszerű lenne. A docker image-ek:
- nextcloud app
- nextcloud proxy
- let's encrpyt
- mariadb
Sok doksin, tanácson átfutottam, ezért most nem is zavarnék vele. Nagyjából új telepítésnek nevezhető, így nincs benne mókolás.

Miket nézzek meg, hogy, hol, milyen fájlt javítsak, hozzak létre, előre is köszönöm a válaszokat.

Próbálok egy OpenVPN kliens/szerver kapcsolatot összehozni:

• Egész jól leteszteltem már a dolgot virtuális gépekben.
• Szeretném kihagyni az összes sebezhető algoritmust, így TLS1.3 irányba indultam.
• Szerver oldalon szerintem teljesen jól állok.
• Aztán jött az Android kliens.

1. Mindenhol azt írják, hogy a compress-t el kell felejteni, mert van ezzel kapcsolatos sebezhetőség is, szóval a szerver oldalon be van ez állítva:
        option compress '' //ha nem kap paramétert, akkor nincs tömörítés
        option comp-lzo 'no' //nincs lzo tömörítés

Van viszont ez a remek Openvpn Connect nevű android kliens, na ennek a Settings menüben is No-ra van rakva a compress (írja ott is, hogy ez sebezhetőség és nem ajánlja a bekapcsolását). Ráadásul a client.ovpn fájlban is használom ezeket a kapcsolókat:

    compress
    comp-lzo no

Az összes kombinációját is próbáltam, hátha nem mindegy melyik van elől stb., de ennek az egésznek pedig az az eredménye, hogy a kliens mindig comp-lzo-val kezd, ilyenek vannak a logokban:

Tunnel Options: blabla,comp-lzo,stb.

Ezt pedig a szerver is észreveszi és el is bukik a kapcsolat, először csak egy warning, majd nem ismeri fel a csomagokat:

WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'

...

IP packet with unknown IP version=15 seen

Próbáltam a OpenVPN for Android-ot is, na az meg a tls-crypt-et nem ismeri :(, pedig az is egy jó feature.

2. TLS1.3: Szerver oldal azt mondja ezeket az algoritmusokat támogatja:

    # openvpn --show-tls
    Available TLS Ciphers, listed in order of preference:

    For TLS 1.3 and newer (--tls-ciphersuites):

    TLS_CHACHA20_POLY1305_SHA256
    TLS_AES_256_GCM_SHA384
    TLS_AES_128_GCM_SHA256

Az ubuntu klienssel nincs is gond, de az Openvpn Connect megint csak ignorálja, hogy szerver és kliens oldalon milyen tls cipher-t adok meg:

tls-cipher TLS_AES_256_GCM_SHA384

csak a  TLS_CHACHA20_POLY1305_SHA256-t hajlandó használni, gondolom azért mert az van előbb a listában.

Valakinek van valami ötlete ezekkel kapcsolatban?

Sziasztok!

Raspberry Pi Zero-n szeretnék betölteni egy patch-cselt kernel modult, de sajnos eddig minden próbálkozásom kudarcot vallott.

Az USB gadget mód egyik moduljához van egy régebbi patch amit teszteni szeretnék. A patch kódját már portoltam az aktuális kernel verzióra, és szerencsére egyszerű dolgom is volt mert nem konfliktolt semmi más változással, és maga a patcs-cselt kód is tisztán fordult.

Ami a Zero-t illeti, használtam rajta az rpi-update scriptet és így most "5.4.44+"-es kernelt futtat.

Fogtam a https://github.com/raspberrypi/linux.git tárolót, leklónoztam, átváltottam az rpi-5.4.y branch-re, fogtam a Pi Zero-s default configot mivel sajnos az rpi-update-es kernelben nincs /proc/config.gz), alkalmaztam a patch-cset és leforgattam a kernelt és a modulokat.

Tesztelésképpe megpróbáltam egy modult betölteni, ami viszont már sajnos nem sikerült:

root@zero:/data/git-clean-rpi-linux# insmod ./drivers/net/usb/cdc_mbim.ko
insmod: ERROR: could not insert module ./drivers/net/usb/cdc_mbim.ko: Invalid module format
root@zero:/data/git-clean-rpi-linux# dmesg -T | tail -n 1
[Fri Jul  3 10:23:59 2020] cdc_mbim: disagrees about version of symbol module_layout

Annak ellenére, hogy a hivatalos és az általam fordított modul szinte teljesen megegyezik:

root@zero:/data/git-clean-rpi-linux# uname -a
Linux zero 5.4.44+ #1320 Wed Jun 3 16:01:17 BST 2020 armv6l GNU/Linux
root@zero:/data/git-clean-rpi-linux# modinfo ./drivers/net/usb/cdc_mbim.ko
filename:       /data/git-clean-rpi-linux/./drivers/net/usb/cdc_mbim.ko
license:        GPL
description:    USB CDC MBIM host driver
author:         Bjørn Mork <bjorn@mork.no>
author:         Greg Suarez <gsuarez@smithmicro.com>
srcversion:     E78127BCABE41799AC5303D
alias:          usb:v*p*d*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v1BC7p1041d*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v03F0pA31Dd*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v12D1p*d*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v0BDBp*d*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v*p*d*dc*dsc*dp*ic02isc0Dip00in*
depends:        cdc_ncm,cdc-wdm
intree:         Y
name:           cdc_mbim
vermagic:       5.4.44+ mod_unload modversions ARMv6 p2v8 
root@zero:/data/git-clean-rpi-linux# modinfo /lib/modules/5.4.44+/kernel/drivers/net/usb/cdc_mbim.ko
filename:       /lib/modules/5.4.44+/kernel/drivers/net/usb/cdc_mbim.ko
license:        GPL
description:    USB CDC MBIM host driver
author:         Bjørn Mork <bjorn@mork.no>
author:         Greg Suarez <gsuarez@smithmicro.com>
srcversion:     E78127BCABE41799AC5303D
alias:          usb:v*p*d*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v1BC7p1041d*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v03F0pA31Dd*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v12D1p*d*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v0BDBp*d*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v*p*d*dc*dsc*dp*ic02isc0Dip00in*
depends:        cdc_ncm,cdc-wdm
intree:         Y
name:           cdc_mbim
vermagic:       5.4.44+ mod_unload modversions ARMv6 p2v8 
root@zero:/data/git-clean-rpi-linux#

Több problémamegoldási módszert is próbáltam a helyzet feloldására, mivel pár hibát én is elkövettem a munkám során:

• egy Raspberry Pi 2-n forgattam le a kernelt és a modulokat először. Most már magán a Zero-n forgatom
• a kernel header-ökből először a korábbi (rendszer által szállított) verzió headerjei voltak fent, de ezt lecseréltem azokra amik a git-es kernelforráshoz tartoztak, és rebuildeltem a kernelt és a modulokat

A fentiek ellenére továbbra sem tudom betölteni a frissen forgatott modulokat a futó rpi-update-es kernel mellé.

Van esetlek valamelyőtöknek ötlete, hogy mit felejthettem el, illetve mit próbálhatnék még meg?

Sziasztok!

A múlt héten volt egy olyan problémám, hogy a systemd-login.d betöltése nem sikerült egy levelező szerver újraindítás után. Ez miatt nem indult el a postfix. Próbáltam megjavítani, de elég kilátástalannak tűnt a helyzet ezért egy új merevlemezre újra telepítettem egy virtual domain-es levelező rendszert. Az eredeti szerverből kivettem a /var kötetet. Mielőtt felmountoltam volna ellenőríztem az uid-kat, és a gideket. Ahol eltérés volt a régi szerver és az új között, ott minden uid-t és gid-et beállítottam úgy, ahogy a régi szerveren volt. Beigazítottam a file-ok és a könyvtárak jogosultságait. Ezután felmountoltam a régi /var kötet az új szerverben. Pár dolgon apróbb változtatások kellettek, de nagyjábol minden megy. 

Egy valamivel viszont gondom van, a sendmail-el. Az akarmi@akarmi.hu usernek sieve-vel be van állítva, hogy automatikusan válaszoljon az e-mailre, ami neki jön. A mail.logban ezt látom:

Jun 22 14:44:12 host dovecot: lda(akarmi@akarmi.hu): Fatal: execv(/usr/sbin/sendmail) failed: Permission denied
Jun 22 14:44:12 ujmx4 host: lda(akarmi@akarmi.hu): Error: Sendmail process terminated abnormally, exit status 75
Jun 22 14:44:12 ujmx4 host: lda(akarmi@akarmi.hu): Error: sieve: msgid=<30dfd1a2-343e-bdd8-6f5a-f71b87d393e4@akarmi.hu>: failed to send vacation response to <valaki@valami.hu> (refer to server log for more information)

A sendmail jogosultságai a következők:

root@host:/var/spool/postfix# ls -l /usr/sbin/sendmail
-rwxr-xr-x 1 root root 26680 ápr   29  2017 /usr/sbin/sendmail

Ezek szerint mindenkinek van jog futtatni a sendmail-t. Parancssorból root-tal tudok e-mail-t küldeni sendmail segítségével, de sima mezei userként nem.

A /usr/sbin/postfix set-permissions-t már lefuttatam. Van valakinek még ötlete?

Köszi!

Hello,

adott egy user, aki rendelkezik UID, GID = 1234-el && EUID & EGID = 0.

Nem tudom, hogy tortent ez, de ha atvaltok az adott userre minden program root-kent fut (es nem tudom hogy lett EUID/EGID 0).

OEL 7.7-rol van szo.

Google semmit nem mondott, apropos is csak 2-es (system calls) es 3-as (c library functions) man page-t tolt seteuid-re.

Elore is koszonom a hozzaszolasokat.

Sziasztok!

Adott egy Debian 8.11-es szerver. Ma újra lett indítva azóta nem indul el a Login szolgáltatás. Azt írja Failed to start Login Services. Ha jobban megvizsgálom ezt a hibaüzenetet kapom:

 systemctl status systemd-logind.service
â systemd-logind.service - Login Service
   Loaded: loaded (/lib/systemd/system/systemd-logind.service; static)
   Active: activating (auto-restart) (Result: exit-code) since sze 2020-06-17 21:24:24 CEST; 11min ago
     Docs: man:systemd-logind.service(8)
           man:logind.conf(5)
           http://www.freedesktop.org/wiki/Software/systemd/logind
           http://www.freedesktop.org/wiki/Software/systemd/multiseat
  Process: 534 ExecStart=/lib/systemd/systemd-logind (code=exited, status=1/FAILURE)
 Main PID: 534 (code=exited, status=1/FAILURE)
   Status: "Shutting down..."

jĂşn 17 21:24:24 xxxx systemd[1]: Failed to start Login Service.
jĂşn 17 21:24:24 xxxx systemd[1]: Unit systemd-logind.service entered failed state.
jĂşn 17 21:24:24 xx systemd[1]: systemd-logind.service has no holdoff time, scheduling restart.

Valakinek van esetleg ötlete? Csökkentett módban az apt upgrade-et már próbáltam.

Köszi!

Robi
 

Security Warning: these home directory should not be owned by someone else or writable :
user=davfs2(982) : home directory is group writable.

No de: 

A .davfs mappa 700-as a fájlok 600-as engedélyűek. 

$ ll .da*
összesen 56
drwx------ 3 nextra nextra  4096 dec    3  2017 cache/
drwxr-xr-x 3 nextra nextra  4096 aug    8  2016 certs/
-rw------- 1 nextra nextra  2167 ápr   14  2014 davfs2.conf
-rw------- 1 nextra nextra  2705 aug    8  2016 secrets