Linux-kezdő

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.

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.

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.

Ü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.

Köszi.

Helló

Futottam már több kört erre keresve és a chagpt 3.5 verzióval is, de nem találtam még megoldást.

Fut egy virtuális gépben Ubuntu 22, xfce4 és  tightvncserver az 5901 porton. Tudok is csatlakozni rá az ip:5901 porton Windows alól vnc viewer alkalmazással, ez jól működik.

A virtuális gépen futtatva tudok képet lementeni a vnc szerverre csatlakozva, például így:  vncdo -v -s localhost::5901 capture kepernyo.png

Szeretném a vnc képernyőn az egeret a képernyő adott x:y pontjára mozgatni és oda kattintani. Itt viszont már nem teljesen értem, hogy mi a módja. Kell hozzá X servernek futnia? Nem kell akkor xfce4? Hogy állítom be, hogy a vnc szerver mit lásson?

A chatgpt 3.5 az xdotool programot mondja kizárólag, de találtam még xte és xdot nevű alkalmazásokat, azonban ilyen hibaüzenetet kapok például xte esetén: Unable to open display 'default'

X server / startx esetén más desktop képet látok a virtuális gépen, mint amit vnc esetén. 

Mi ebben az esetben a megoldás, hogy a vnc viewer képernyőjén láthatóan mozgatni tudjam az egeret és klikkelni, ott, amit vnc viewer esetén látok? Ebből nyilvánvaló, hogy sok minden nem tiszta, mi hogy működik. Ezt szeretném érteni és megoldani. Köszi.

Van egy szerverem, aminek van IPV4 címe. Ehhez szeretném az IPV6 címet beállítani ansible segítségével.

Mivel nem akarom bántani az /etc/network/interfaces fájlt, a legegyszerűbbnek az /etc/network/interfaces.d/eth0 fájl használata tűnt volna, de ezt nem tudom életre lehelni. Bármit írok bele, az nem konfigurálódik le.

Tudom, hogy az ansible blokkokat is be tud szúrni egy fájlba, és tehetném az IPV6 beállítást az interfaces fájlba közvetlenül, de szebb lenne, ha az IPV6-nak saját konfigurációs fájlja lehetne.

Meg lehet ez oldani valahogy?

Röviden, elkadtam... :/ 

Kicsit hosszabban, az van hogy szeretnék ~ 30 konténert futtatni dockerben. Hogy legyen valami formája a gyereknek: proxmox host, ezen egy deban 12-es VM. A VM-en rootless modban fut a docker.

Van nekem egy NFS kiszolgálom, mert gondoltam NFS-el osztanam meg a docker hostnak, a volumeokat. 

User akinek a nevében fut a docker: docker_user

NFS kiszolgálón létrehoztam szintén ezt a docker_user felhasználót, ügyelve arra, hogy az UID-k megegyezzenek. Doksikból kiderül, hogy NFS-nél nem a felhasználónév számít alap esetben, hanem az azonosítók. Ez pipa.

Adott a megosztás, 755-ös beállításokkal. docker_user olvassa/írja, stb... - többi userem 755 alapján tudja tenni a dolgokat. Boldogság.

De... a konténereket compose-al szeretném felügyelni, nekem ez egyszerű 1 file-ban bent van minden.

Gondoltam létre is hozom az elsőt, ez egy mongo adatbázis. 

A compose:

version: '2.24'

services:

# 1. mongo adatbazis graylog-hoz
  mongo_db:
    container_name: mongo_db
    image: mongo:6.0.13-jammy
    restart: unless-stopped
    volumes:
      - type: bind
        source: /home/docker_volumes/mongo_db
        target: /data/db
        bind:
          create_host_path: true
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    networks:
      docker_intra_net:
        ipv4_address: 172.28.0.5

networks:
  docker_intra_net:
    ipam:
      driver: default
      config:
        - subnet: 172.28.0.0/24
          gateway: 172.28.0.254

Ahogy compose up-al létrehoznám a konténert, az alábbi hibaüzenet jön: mongo_db  | chown: changing ownership of '/data/db': Operation not permitted

És én most nem tudom, hogy mi a csöcs van. Ha local-ban hozom létre, akkor rendben van természetesen. Ebben az esetben a mongo 999-es UID-ra állítja a könyvtárat.

Feltételezésem, hogy ugyan ezt szeretné elkövetni az NFS megosztáson is, de ott ugye ne tudja. 

Kérdésem, hogy hogyan lehetne megugrani ezt a problémát?

Most nekem 999-es UID-al létre kellene hoznom, az NFS szerveren is "valakit", sőt minden konténernél ahol chown "change" lenne, ott ugyan ezt meg kellene csinálni.

Az NFS beállításai(tudom, hogy nem elegáns a gyökérből megosztani, de ez most egyelőre ilyen): 

/data/docker_volumes 192.168.54.0/24(rw,sync,no_subtree_check)

Dockerben jártas személyeket kérdeznék:

Ott ahol még nem kubernetes van, de szintén NFS-el van megoldva a storage a volume-ok alá, ott hogyan működik?  Feltétetelezem, hogy nem a rootless mode a gond, hiszen az NFS kiszolgáló "rootja" és a cliens "rootja" nem egyezik meg.

Vaagy, fordítva kellene indulni, és létre kell hozni az NFS szerveren a mappa struktúrát, majd NFS volume-ként becsatolni compose-al a konténerhez?

Ebben az esetben az a gond, hogy local volume-ként szeretném kezelni az NFS-t, ami eleve nem tud ebben a formában működni, és csak úgy fog menni, ha NFS-ként van mountolva a konténer alá?

Köszi a segítséget előre is!

Sziasztok !

A következő problémára szeretnék megoldást :

Van egy PC, benne egy wifi modul és egy ethernet port. A netet DHCP kliensként a wifi modulról kapja a gép.

Szeretném a ethernet portot DHCP szerverként használni, úgy hogy net is legyen a ethernetre csatlakozó kliensen.

Fedora 38 desktop (NetworkManager -rel) fut a gépen.

Jelenleg a wifi :

ipv4 : 192.168.8.130

DNS : 192.168.8.1

Amit eddig próbáltam :

/etc/systemconfig/dhcpd :

...

(default)

DHCPDARGS="enspls0";

/etc/dhcp/dhcpd.conf :

subnet 192.168.9.0 netmask 255.255.255.0 {
   range 192.168.9.10 192.168.9.50;
   option subnet-mask 255.255.255.0;
   option routers 192.168.9.1;
   option domain-name-servers 8.8.8.8;
}
host interface1 {
    hardware ethernet d0:50:99:a8:9d:21;
    fixed-address 192.168.9.60;
}

A dhcpd hibával leáll. Előre is köszönöm a segítséget.

Suse linux-szal indítottam, használtam RedHat-et és Ubuntut, de végül a Debiánig jutottam, s a kompromisszumok ellenére mind a mai napig azt használtam. Ám a tegnapi frissítés óta már lekapcsolni is alig lehet a laptopomat, és azt hiszem, ez volt az utolsó csepp.

Már az is nagyon elbizonytalanított, hogy a Systemd-t bevezették, de hogy egy gép leállítása 5 percbe kerüljön, mert a hálózatkezelésben valaki bugos, és hogy ne tudjam lekapcsolni a wifit, mert minden befagy, ilyen élményem már rég volt.

Tehát új distrot kellene keresnem. Nincsenek nagy igényeim, leginkább annyi, hogy menjen. Stabilan. Ha megszoktam ne kelljen 5 év múlva váltanom egy újabbra. Ja, és ha lehet, ne legyen benne systemd, mert szerintem az már egy másik elvi megközelítés.

Tudom, hogy nehéz a kérdés, mert akinek épp nincs baja a saját distrojával, annak az is biztos jó, tehát inkább olyanok válaszait várnám, akiknek rálátása van nagyobb idő és hardver téren egy-egy disztribúcióra.