Linux-haladó

Egy HP HQ TRE71004 laptopra (atom N3520) kellett volna linuxot telepítenem. Mivel a multi-touch funkció cél lett volna, Ubuntuval kezdtünk. Emlékeim szerint viszonylag jó a hardver támogatása és a dokumentáltsága.

A live verzió rendben futott, de nem volt multi-touch, csak egyszerű érintést érzékelt. Nosza, telepítsük, és hangoljuk finomra ... Ám itt jött a meglepetés.

Telepítés után, a grafikus felületen, már nem volt elérhető a beépített billentyűzet. Input esetén feljött a virtuális billentyűzet. (Live verzióban nem volt virtuális billentyűzet.) Ezt le lehetett zárni, de a fizikai billentyűzet, és a beépített touch pad nem működött. Ám egy külső USB-s billentyűzet gond nélkül ment.

Terminálra váltva ment a beépített billentyűzet is.

Ezek után jött egy xubuntu, majd egy debián telepítés. A jelenség ugyanez.

xinput-tal próbáltam csatolni, de semmi eredmény. Billenytűzet be-/kikapcsoló scriptek: ... semmi.

Tehát az egész kuka. Most windows 10 ment rá, persze a touch azon sem megy. Windows 8 még vitte.

A cél azonban mégis az lenne, hogy linux alatt legyen billentyűzet, s majd utána multi touch is, bár az gondolom, már egyszerűbb lesz.

Nem is értem, hogyan lehet, hogy egy működő, a linux által használatban lévő billentyűzet X alatt elérhetetlen (még a login screen-en is)? Érdekesség még, hogy a fényerőszabályozás billentyűje működik X alatt is.

Valaki találkozott már ezzel a jelenséggel? Netán van rá megoldás is? Minden ötletnek örülnék, bár új telepítést már csak akkor fogok megpróbálni, ha érdemi esély van arra, hogy működőképessé lehet tenni.

Sziasztok!

Kis ~10 user által, ssh -n keresztüli shell hozzáférésre és távoli program futtatásra használt, Linux alapú szerver állapotáról jelentést készítő programot keresek. Ingyenes és egyszerű megoldás kellene. Ha fájlba ment, vagy emailt küld az elég.

Kérdéseim:

• Logcheck projekt él még?
• Mit ajánlanátok logcheck helyett?
• Esetleg van valakinek olyan házi megoldása/szkriptje amit meg tudna osztani?

Háttér sztori:

Adott a cégnél egy fejlesztők által használt Linux szerver (Linux Mit megy rajta). Elsősorban ssh -n keresztül használjuk C/C++ programok buildelésére (cmake, make, docker, yocto, etc..). Kb. 10 felhasználó nyúzza változó intenzitással.

Kellene nekem valamilyen ingyenes, minél egyszerűbb megoldás, ami a szerver állapotáról készítene jelentést. Szabad hely a háttér tárolón, CPU használat, gyanús log bejegyzések, bennragadt konténerek, bejelentkezések, statisztikák, stb...
Régebben (~10-15 évvel ezelőtt) logcheck -et használtam ilyesmire, de ez a tool azóta eléggé bonyolult lett, illetve az sem tiszta karban tartják e még.

Próbáltam guglizni, de elég nehezen kereshető a téma, mert mindenütt komoly infrastruktúrák monitorozására való bonyolult megoldások jönnek elő, és nincs idő egy hetet tanulásba fektetni. Abban reménykedem, hogy valaki már elvégezte a "házi feladatom", és ki tud segíteni.

Előre is köszönöm!

Tud valaki tanácsot  adni net-snmp (5.7,5.8) kapcsolatban, hogyan lehetne rábírni, hogy ne egye  100% on a cpu-t ezáltal a lekérés kb 80% timeoutra fut.

Vannak linuxos koncentrátorok, ahol az ügyfelek pppoe-val vannak végződtetve + ospf routing. Ahol sok a session az snmpd 100% hajtja azt az 1 nyomorult szálat, és elhasal. Ahol kevesebben vannak ott elmegy 50-90% on és ugye szolgáltat infót is.

Próbáltam már mindenféle modult kikapcsolni de semmi se segített eddig, fórumokon szintén küzdenek páran hasonló gonddal. Eredmény semmi. 

Jelenleg ennyi modul van kikapcsolva.

-I -smux -tcptable -udptable -var_route -mteTriggerTable -mteTrigger -mteTriggerConf -ifTable -ifXTable -interface -ipCidrRouteTable -inetCidrRouteTable -ipv6 -tcp -udp -tcpConnectionTable -udpEndpointTable -ipIfStatsTable -ipAddressTable -ipDefaultRouterTable

Viszont a CPU továbbra is 100%

Ahogy olvasgattam régen mintha tobb szálú lett volna a snmpd de ez megszünt.

A lényeg, ha sok interface van akkor az leöli ahogy látom.

Valaki jár/járt hasonló cipőben? Van esetleg 5lete mit lehetne tenni ?

Egyik hozzászólásban említve lett ez a patch: https://github.com/bvanassche/net-snmp/commit/76ad711

Az 5.9 es net-snmp-be már benne van. Forgattam egyet, egyelőre jónak tűnik a helyzet. Minden modul bekapcsolva se ugrik meg nagyon az snmpd cpu használata. 

Sziasztok

Valakinek van tapasztalata a real time  kernelekkel?

Mivel jobb mint egy hagyományos kernel?

Virtualizált környezetben is használhatóak?(Azure, Vmware,Xen) A node Overalloc-áció esetében is?

Streaming software-ek esetében hasznos?

Sziasztok!

Tudtok Linux ala olyan Andorid emulatort, ami jol hasznalhato jatekra? Probaltam a Genymotion-t, de nem ment amit akartam, illetve az Anbox lenne szimpatikus, de csak az miatt nem rakok Snapot Fedora-ra... (bar allitolag azon sem megy...)

Probaltam KVM illetve Vmware-el virtualizalt x86-os androidokat (ARM kompatibilitas bekapcsolva) de ezzekkel sem megy.

Az EVE Echoes jatekrol lenne amugy szo.

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?