Linux-kezdő

Mageia9 KDE, hiba előzménye: Szerettem volna bejelentkezés nélkül bebootolni, itt a kdewallet jelezte, hogy a jelszótárolót akarom-e módosítani. Bezártam, hogy nekem ő nem kell. Illetve az sddm-nél állítottam be olyat, hogy nincs sddm, egy üres fehér háttérre klikkelve.

Innentől kezdve hibaüzenetek fogadnak a grafikus felületen ott, ahol már be kellene jelentkezni, az egyik ez: //.config/kreadconfig5rc nem írható. Beléptem recovery módban, majd rákerestem erre a fájlra, de nem a home/user/.config ahol megtaláltam, hanem az usr/bin . Adtam neki ott mindenféle jogot, plusz kínomban futtatható is lett, majd ezt átmásoltam a home/user/.config helyre úgy, hogy ott a jogot átírtam a root helyett userre és itt is kapott mindenféle jogot a file. kreaáltam új usert, de ez sem segített belépnem.

Mit javasoltok, hogyan tovább? Tudom gyorsabb volna reinstall a rendszer, de akkor soha nem fogom megérteni ezt a folyamatot. Itt olvastam erről, bár a megoldás nekem nem jó ebben az esetben:

https://bugs.kde.org/show_bug.cgi?id=492887

Megoldás: reinstall a rendszer, csak a / formázása és telepítése, a Home tartalma változatlan maradt, így a régi rendszerem köszönt vissza.

Szervusztok!

Elnézést kérek, nem vagyk tisztában annyira a szakkifejezésekkel.

Ubuntu 24.04.01 . 22.04-ről frissítettem, azelőtt előtt külön meghajtón, egy ssd-n volt a rendszerem, a /home könyvtárat pedig egy két lemezből álló „LVM”-re raktam. A frisstés során sikerült egy áramszünetet csinálnom, úgyhogy inkább az ssd-re újrahúztam a rendszert. Gondoltam utóag az /etc/fstab fájlba írom, hogy hol legyen a /home könyvtár.

Igen ám, de a két lemezes lvm-et most külön látom a gnome-disks progiban, nem mutat semmi egységet a dolog. Az /etc/fstab-ban csak az ssd szerepel alapból

tartalomra azt írja mindkét lemeznél: LVM2 Physical Volume (LVM2 001)

Partíciótípusra "Linux LVM"-et ír mindkét meghajtóra.

A thunar nem lát más meghajtót.

Hogyan tudnám ezt a két lemezt ismét egységesíteni, hogy a régi adataimat tudjam használni?

Reménykedek a segítségetekben, annak ellenére, hogy valószínűleg elég pongyola voltam.

Sziasztok,

Tegnap kaptam egy levél sorozatot, hogy szokatlan IP tartományból történt sikeres bejelentkezés, először azt hittem hogy szokásos spam e-mail sorozat, de nem. Valószínű hogy az internet szolgáltatónál vacakolt valami, mert az eszközök stimmeltek, de azért lefuttattam az egész rendszeren és a hálózaton egy vírusírtót, hátha. Szerencsére semmi találat.

Ennek ellenére, ugyan mindenhol aktiválva van a kétlépcsős azonosítás, nehéz jelszavak, stb... szeretnék egy vírusírtót üzemeltetni a fájl szerveren legalább, hogy oda nehogy bármi bejusson. 

Célom az lenne, hogy valós idejű szkennelés történjen, nagyjából 5TB adat van ami folyamatosan változik és ez smb szerverrel megosztva Windows klienseknek amiken szintén nagy mennyiségű adat van és folyamatosan változik.

ClamAV erre mennyire alkalmas és milyen megoldás van rá, hogy folyamatosan szkenneljen? Erőforrás van rá.

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.

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?

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

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

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…

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.

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.