Linux-kezdő

Thunderbird "Could not connect..."

Fórumok

Kedves Tanult/Tapasztalt Fórumtársak!

Adott egy Thunderbird, kezel több postafiókot, a postafiókok beállításai stabilan megvannak igen hosszú évek óta, és zavartalanul működött minden hosszú ideje (jelentős levélforgalmat bonyolítva). Tegnap este volt egy pár másodperces áramszünet, ami valamibe nagyon belezavart. Két accountot ugyanazon a kiszolgálón kezel, egyiknél a "Could not connect mail server <távoli kiszolgáló>; the connection was refused" üzenetet adja, a másiknál a "Your message was sent but a copy was not placed in your sent folder (Sent) due to network or file access errors." A távoli kiszolgáló elérése ssh alagutakon keresztül történik, a TB úgy tudja, hogy az imap kiszolgáló a localhost:1143, az smtp pedig a localhost:2525-ön van. Az adott portokra telnettel kapcsolódva elérhető az imap, ill. smtp kiszolgáló, tehát a portforward működik. A helyi gépről ugyanilyen módon másik helyi felhasználó levelezése probléma nélkül működik, igaz, ő az áramkimaradáskor nem csinált semmit.

A helyi gépen (amelyiken a TB fut) nem látok semmi furcsát a logban, viszont a távoli kiszolgálón a syslogban lett egy csomó "May 28 07:17:22 turul sshd[15713]: error: connect_to 127.0.0.1 port 1143: failed." bejegyzés. Ez a távoli sshd újraindítása után is fennál.

Mi az, amire nem jövök rá, merre keressem a megoldást?

Üdvrivalgással:
KEA.

Particionálás (túlbonyolítása)

Fórumok

Sziasztok!

Csak egy alapvető témát szeretnék feldobni, és inkább kezdő linuxos kérdés. A megfelelő particionálással nagyobb biztonságot lehet biztosítani (pl céges környezetben): pl kivédhető, hogy alkalmazások a root partíciót teleírják, vagy mástól vegyék el a helyet stb...

Egy desktop gépre most a Fedora BTRFS-sel alapértelmezetten a következőket hozná létre (vagyis ezt ajánlja fel a kézi particionáláskor):

  • /boot
  • /boot/efi
  • /
  • /home
  • /var
  • swap

Ha jól emlékszem.

Van aki csak egy root-ot hoz létre.

Régebbi rendszereknél úgy emlékszem, több partíciót volt szokás létrehozni. (desktopon lehet, hogy nem). Érdemes lehet ezt tovább bonyolítani desktopon?

Egy példa: 1Tb-os ssd-n titkosított (800 GiB), és nem titkosított (200 GiB) volume létrehozása, és azokon a következő subvolume-ok:

  • / - Nem titkosított
  • /usr - Nem titkosított
  • /usr/local - Nem titkosított
  • /root - Titkosított
  • /home - Titkosított
  • /opt - Titkosított
  • /srv - Titkosított
  • /var - Titkosított
  • /var/cache - Titkosított
  • /var/log - Titkosított
  • /var/spool - Titkosított
  • /var/lib - Titkosított
  • /var/lib/machines - Titkosított
  • /var/lib/docker - Titkosított
  • /var/lib/libvirt - Titkosított
  • /var/lib/containers - Titkosított
  • /tmp - Titkosított
  • swap - Opcionális

Ezeknek a subvolume-oknak a mérete utána finomhangolható, pl: / 40 GiB, /tmp 5 GiB, stb...

Érdekes, hogy a Fedora kérdezés nélkül létrehoz egy /var/lib/machines subvolume-ot, lehet hogy valami technikai oka van, de akkor érdemes lehet a docker-nek, podmannek, és a libvirt-nek is külön partíciót csinálni.

A swap partició: több memóriával rendelkező gépen gondolom nem érdemes külön swap-et csinálni, kivéve ha valaki hibernálni akarja a gépét. A Fedora így is csinál valami zram-os megoldást, ahol a RAM-ban van a swap, tömörítve a benne lévő adat. (ha jól értem).

Desktop-on nem valószínű, hogy az ember belefut olyan problémákba, ami miatt ezt ennyire el kellene bonyolítani, lehet hogy ez így túl overkill. Vagy manapság már ez nem szokás, pl külön rakni a /usr-t? A otthoni gépeteken ez hogy van?

[Megoldva!] SELinux + root password visszaállítása

Fórumok

Sziasztok!

Én Az egyik ismerősőm :) egy desktop gépen, amin van egy root user, és egy regular user véletlen egy rosszul kiadott usermod paranccsal kivette magát a wheel groupból. Ez egy Fedora 40 egyébként, és a root bejelentkezés pedig le van tiltva. Tehát sikeresen kitiltotta magát, mint adminisztrátor, ezt ugye jól gondolom?

Már túl vagyok a dolgokon, de három lehetőséget találtam, itt van leírva kettő:

https://docs.fedoraproject.org/en-US/quick-docs/reset-root-password/

A harmadik, hogy felmountolom a home-ot, gyorsan csinálok még egy mentést, és 15-30 perc alatt újrahúzom a rendszert (ami kb meg is lehet az összes beállítással).

Az első két megoldással elszórakoztam kb 2 órát,

1. Rescue módban ha megváltoztatom a jelszót, hiába hozok létre egy /.autorelabel fájlt, utána nem lehet belépni egy jelszóval sem.

Kicsit kutakodva, korábban a /etc/init.d/fuctions fájlban volt egy ilyen:
https://github.com/aababilov/systemd/blob/master/fedora-autorelabel
Most ez sehol nincs (vagyis én nem találtam), és a .autorelabel is ott marad a root könyvtárban reboot után, tehát nem is futott ilyesmi.
Ha kézzel akarom futtatni az itt leírt parancsokat, persze az nem működik, nem írtam fel a hibaüzeneteket, de selinux-os problémákra hivatkozott. (szerinten nem megfelelő context volt beállítva, vagy hasonló).

2. Live CD:

Miután felmountoltam mindent, és chroot-al root könyvtárat váltottam, kiadnám a passwd-t, de a következő hibát adja:

authentication token manipulation error

Tehát a Fedora-s leírások (2022-ben update-elték utoljára) igazából Fedora 40-el nem működnek/én a selinux-hoz se értek, meg kellene tanulni..

3. Újra telepítés: Ez itthon megtehető (máshol már nem), ez persze működik, gyorsan meg is van, csak nem ez lenne a módja.

Az is simán lehetséges, hogy valami pofon egyszerű egyéb módszerrel meg lehet ezt oldani, és feleslegesen bonyolítottam.

Most már nem kisérletezek vele, minden működik, de foglalkoztat, hogy mi a rendes megoldás, esetleg valaki járt már így?
Best practice, hasonló esetek kivédésére: Van a gépeden plusz user, vagy engeded a root-nak a belépést?

Megoldás:

Lásd: https://hup.hu/comment/3055661#comment-3055661

/MEGOLDVA/ KDE tálcán lévő naptárba nem kerül bele a Korganizerbe beírt esemény

Fórumok

Ahogyan a címben is megfogalmaztam, a tálcán lévő naptárra klikkelve van egy olyan lehetőség, hogy események hozzáadása. Erre klikkelve bejön a Korganizer, ahova ha beírom az új eseményt, akkor a Korganizer eltárolja, viszont a tálcán lévő naptárban nem jelenik meg, mint új esemény. Akár egy használható kulcsszónak is örülnék, megoldásnak meg még jobban :)

Gyk: hogyan oldhatom meg azt, hogy ne csak a Korganizerben jelenjenek meg az események, hanem a tálcén lévő naptárban is?

Szerencsém volt: https://www.youtube.com/watch?v=sTDdXjHIXBA

/MEGOLDVA/ Akonadi server elindul, hibával leáll

Fórumok

A Korganizert szeretném használni, de az Akonadi server a következőt mutatja Konzolban:

$ akonadictl start
org.kde.pim.akonadictl: Starting Akonadi Server...
org.kde.pim.akonadictl:    done.
[xy@localhost ~]$ Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadiserver: Starting up the Akonadi Server...
org.kde.pim.akonadiserver: database server stopped unexpectedly
org.kde.pim.akonadiserver: Database process exited unexpectedly during initial connection!
org.kde.pim.akonadiserver: executable: "/usr/sbin/mysqld"
org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/xy/.local/share/akonadi/mysql.conf", "--datadir=/home/xy/.local/share/akonadi/db_data/",
"--socket=/run/user/1000/akonadi/mysql.socket", "--pid-file=/run/user/1000/akonadi/mysql.pid")
org.kde.pim.akonadiserver: stdout: ""
org.kde.pim.akonadiserver: stderr: ""
org.kde.pim.akonadiserver: exit code: 1
org.kde.pim.akonadiserver: process error: "Unknown error"
org.kde.pim.akonadiserver: Shutting down AkonadiServer...
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally...

Itt várakozik. 

6.6.22-desktop-1.mga9 #1 SMP PREEMPT_DYNAMIC Sun Mar 17 18:04:51 UTC 2024 x86_64 GNU/Linux

KDE plasma 5.27.10

Mit tehetek, hogy induljon rendben?

MEGOLDÁS: https://askubuntu.com/questions/1330264/korganizer-cant-create-any-item…
Ez elindítja az Akonadi servert: https://forum.manjaro.org/t/org-kde-pim-akonadiserver-process-error-unk…

[Megoldva] Fedora problémák kernel (6.7.11-200.fc39.x86_64) frissítés után

Fórumok

Fedora 39: Mostanság nálam valahogy felszaporodtak a problémák, a legújabb frissítés után (6.7.11-200.fc39.x86_64) a bluetooth eltűnt.

dmesg:

[   83.789716] usbcore: deregistering interface driver btusb
[   87.107457] usbcore: registered new interface driver btusb
[   89.147439] Bluetooth: hci0: Reading Intel version command failed (-110)
[   89.147440] Bluetooth: hci0: command 0xfc05 tx timeout
[   91.579450] Bluetooth: hci0: command tx timeout
[   91.579461] Bluetooth: hci0: Reading Intel version command failed (-110)
[   95.867498] Bluetooth: hci0: command tx timeout
[   95.867503] Bluetooth: hci0: Reading Intel version command failed (-110)
[   99.707525] Bluetooth: hci0: command tx timeout
[   99.707531] Bluetooth: hci0: Reading Intel version command failed (-110)
[  118.213525] usbcore: deregistering interface driver btusb

Egyszer sikerült életre kelteni így:

hciconfig hci0 down
rmmod btusb
modprobe btusb
hciconfig hci0 up

De azóta sem.

 

Még egy furcsaság: Ha nem úgy indul a gép, hogy egy usb-s egér be van dugva, nem is sikerül életre kelteni később. (korábban ez automatikus volt)

 

Esetleg itt valaki más is belefutott ebbe, aki Fedora-t használ?

Megoldva: kiadták a kernel verziót, amiben javítva van.

[Megoldva] ENOTTY hiba Python-ból indított bashnél

Fórumok

Sziasztok, szeretnék egy kis pythnon scriptet csinálni, ami indít egy basht, monitoroz egy processzt, ami ha leáll, kilövi a bash-t. Sajnos elég furán viselkedik nekem, ami valószínű pont az elvárt viselkedés olyannak, aki ért a témához.

from subprocess import *
import signal
import time

def main():
    while True:
        time.sleep(1)
        ret = run("/usr/bin/bash --norc -i", shell=True)
        if ret.returncode == 0 or ret.returncode == signal.SIGINT:
            break
        else:
            print("Restart")
main()
 

Normál kilépésnél végezne a script, de ha kívülről adok neki egy SIGTERM-et, akkor nagyon fura dolgok történnek.

így néz ki a processz tree:

xx    58365  0.0  0.0   8548  4992 pts/3    Ss   18:27   0:00 /bin/bash
xx    59044  0.1  0.0  18148 10112 pts/3    S    18:33   0:00  \_ python3 pyterm.py
xx    59045  0.0  0.0   2580  1536 pts/3    S    18:33   0:00      \_ /bin/sh -c /usr/bin/bash --norc -i
xx    59046  0.0  0.0   7228  3840 pts/3    S+   18:33   0:00          \_ /usr/bin/bash --norc -i

Itt ha másik terminálból kiadok egy kill -SIGTERM 59045 parancsot, a processz leáll, viszont az újonnan elinduló bash stdin/stdout-ja már nem megy, mintha teljesen a háttérben futna.

 

Bár érdekelne hogy lehet szépen visszavenni az stdin és stdout felett az irányítást, bármi ötletnek örülnék arra vonatkozóan, hogy lehetne ezt szépen kezelni. Fontos lenne hogy scriptből indítom az új bash-t mert a paraméterezése az minden esetben más, a monitorozott processz függvénye.

[Megoldva] NVIDIA driver értelmes telepítése Fedora alatt

Fórumok

Sziasztok!

Kb harmadjára futok bele pofonba az nvidia driver installal, és szeretném megkérdezni, hogy ha esetleg valaki tud jól bevált lépéseket, ami után minden megy a maga útján egy update után is, és működőképes marad, akkor azt esetleg meg tudná osztani?

Én a következőket csináltam:

1. első probálkozás:

- a nonfree repository-ból feltettem az 550.54.14, erre azt gondoltam, hogy elég lesz. Belefutottam, hogy a secure boot miatt nem indul el a kernel modul, és egy alap driver indult: nouveau

Itt addig "kavartam", hogy legyen egy aláírt secure boot által elfogadott kernel modulom, hogy a végén el sem indult a gépem.

2. második próbálkozás:

Ez alapján a leírás alapján szépen feltettem a drivert: https://github.com/roworu/nvidia-fedora-secureboot, és minden működött is. rájöttem, hogy nekem a cuda driver kell, úgyhogy elkezdtem ezt feltenni:

https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch…

Ennek az lett az eredménye, hogy először a nonfree repóból felment a driver (a github-os leírás alapján), aztán a második install (az nvidia-s cudas leírás alapján) letiltotta azt a dnf modult amiben az volt, és ebből a második repóból rátelepült ez a cuda-s verzió.

De ezek után minden működött hetekig.

3. kör, és most ezt gyűröm:

Update jött a developer.nvidia.com-ról, és most felemás driverem van: a dmesg-gel 550.54.14-et látok, amik települtek csomagok, azok verziója már 550.54.15. (törölni nem sikerül a régit)

Ennek eredménye, hogy az nvidia-smi pl azt írja, hogy verzió ütközés van, és vannak funkciók amik nem működnek. pl a kártya állapotának a lekérdezése, stb...

most töröltem a cuda-s verziót, de dnf-el nem tudom visszatenni/update-elni azt ami a nonfree repóból jött a github-os leírás alapján (tehát ami nem a developer.nvidia.com-ról jön), mert a dnf ezt mondja: Az összes találat ki lett szűrve moduláris szűréssel

Gondoltam update-elem azt, ami bent ragadt, és közben ki lett kapcsolva a modul, és visszarakom rá a cuda-s verziót, de így belegondolva, ezt biztos, hogy nem így kell. Szerintem kiszúrja a szemem, hogy hogy kellene, de ezt a modult meg nem sikerült visszakapcsolni. :) De ezt 100% hogy nem is így kellene csinálni (ez egy összevisszaság).

 

Valaki esetleg futott bele hasonlókba, vagy tudja, hogy mi a helyes menete ennek?

Köszönöm előre is

Megoldva, nekem ez vált be: https://hup.hu/comment/3040472#comment-3040472

annyi megjegyzéssel, hogy az nvidia driver telepítése után érdemes a gnome szoftverközpont helyett a frissítéseket a dnf update-tel feltenni. A szoftverközpont újraindítgatja a gépet, és az első újraindításkor fordítja le az akmods az nvidia drivert. Utána viszont valamiért kifagy a gép, nem tud elindulni (csak egyszer fagy ki, kézzel újra kell indítani). (lehet, hogy már van betöltve valami, vagy valami timeoutra megy, stb..., de nem kerestem az okát).

A dnf update tökéletesen működik, után pedig várni kell a gép újraindítással, amíg az akmods fordít a háttérben, de ez egyértelműen látszik mikor ér véget.

Lychee telepítés

Fórumok

Hello,

Az történt, hogy az online képgalériámat frissíteni akartam és katasztrófába torkollott az egész. Szerencsére a főbb dolgokat újra tudtam értelmesen húzni, mint pl apache, php8.3, mysql (ez az én tudásommal sajnos nem volt egyszerű, úgy hogy minden klappoljon mert utoljára rájöttem hogy valamiért 3 verzó php is volt feltelepítve :D

Mindegy, ebbe ne menjünk bele, elkezdtem telepíteni a Lychee-t,

git segítségével:

composer install --no-dev
npm install
npm run build

majd az utolsó parancsnál:

> dev
> vite

file:///var/www/html/node_modules/vite/bin/vite.js:7
    await import('source-map-support').then((r) => r.default.install())
    ^^^^^

SyntaxError: Unexpected reserved word
    at Loader.moduleStrategy (internal/modules/esm/translators.js:133:18)
    at async link (internal/modules/esm/module_job.js:42:21)
 

Sajnos a google jó barátom volt, de érdemben nem találtam róla infót miként tudnám orvosolni.

Ha tudsz érdemben segíteni jár a csoki.

Szerver bejutas - banyaszas?

Fórumok

Üdv!

 

Van egy debian szerver, ami a jelek szerint nem volt eléggé védett, és most vettem észre, hogy az egyik felhasználó névterében furcsa dolgok futnak. 2 rsync process, illetve találtam egy néhány napja létrehozott könyvtárat, aminek ez a tartalma:

 

ls -l
total 3088
-rw-r--r-- 1 spam spam    5382 Feb 28 14:01 config_background.json
-rw-r--r-- 1 spam spam    2579 Feb 28 13:57 config.json
-rwxr-xr-x 1 spam spam     450 Feb 28 13:57 miner.sh
-rwxr-xr-x 1 spam spam 2756500 Feb 26 16:44 xmrig
-rw-r--r-- 1 spam spam  380590 Mar  2 21:07 xmrig.log

 

Jól sejtem, hogy valaki bányászni kezdett el az adott gépen?

 

A felhasználó tulajdonképpen üres, valós tevékenységet nem futtatott, de mégis mit érdemes ilyenkor megnézni? auth.log-ból úgy látom, hogy 3 napja léptek be először.

 

A 2 rsyncet kilőttem, még ezek a processzek futnak néhány másodpercig az adott felhasználó névterében:

 

spam      241958  0.0  0.0  15364  8700 ?        Ss   Feb28   0:00 /lib/systemd/systemd --user
spam      241959  0.0  0.0 168168  2812 ?        S    Feb28   0:00 (sd-pam)
spam     1361449 1051  3.6 2463860 2424160 ?     Ssl  14:37 4151:28 ./kswapd0
spam     1460180  0.0  0.0  74368  7876 ?        SNsl 21:06   0:00 /home/spam/c3pool/xmrig --config=/home/spam/c3pool/config_background.json

 

Néhány fontosabb munin grafikon, amik picit változtak.

Munin graphs

Köszi.