-
Fototrend
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
vzozo
senior tag
Sziasztok, egy odroid n2-essel szenvedek (Ubuntu), csontra fagy a konzol és megszakad az SSH / SFTP kapcsolat ha böngészni akarom a felcsatolt külső merevlemez tartalmát. Sőt, már sikerült úgy is kiakasztanom, hogy cd /mnt/... autocomplete-tel szerettem volna belépni a mount könyvtárba. Sok-sok perc elteltével persze az autocomplete működik, de idő közben az SFTP már régen timeoutol (éppen másoltam valamit.)
Ami releváns a logokban, az kb. ennyi:
Mar 6 15:23:25 odroid ntfs-3g[4851]: Version 2017.3.23 integrated FUSE 28
Mar 6 15:23:25 odroid ntfs-3g[4851]: Mounted /dev/sda1 (Read-Write, label "8TB_EZAZ", NTFS 3.1)
Mar 6 15:23:25 odroid systemd[2416]: Failed to canonicalize path /home/vzn2/.config/systemd/user/mnt-8tb.mount.wants: Permission denied
Mar 6 15:23:25 odroid ntfs-3g[4851]: Cmdline options: rw
Mar 6 15:23:25 odroid systemd[2416]: Failed to canonicalize path /home/vzn2/.local/share/systemd/user/mnt-8tb.mount.wants: Permission denied
Mar 6 15:23:25 odroid ntfs-3g[4851]: Mount options: rw,allow_other,nonempty,relatime,fsname=/dev/sda1,blkdev,blksize=4096
Mar 6 15:23:25 odroid systemd[2416]: Failed to canonicalize path /home/vzn2/.config/systemd/user/mnt-8tb.mount.requires: Permission denied
Mar 6 15:23:25 odroid ntfs-3g[4851]: Ownership and permissions disabled, configuration type 7
Mar 6 15:23:25 odroid systemd[2416]: Failed to canonicalize path /home/vzn2/.local/share/systemd/user/mnt-8tb.mount.requires: Permission denied
Mar 6 15:23:25 odroid systemd[2416]: Failed to canonicalize path /home/vzn2/.config/systemd/user/mnt-8tb.mount.d: Permission denied
Mar 6 15:23:25 odroid systemd[2416]: Failed to canonicalize path /home/vzn2/.local/share/systemd/user/mnt-8tb.mount.d: Permission deniedUbuntuból, legalábbis az odroidra hackelt verzióból a legfrissebben vagyok:
root@odroid:/var/log# uname -a
Linux odroid 4.9.213-67 #1 SMP PREEMPT Thu Feb 13 14:59:00 -03 2020 aarch64 aarch64 aarch64 GNU/LinuxVan bármi ötletetek hogy mi a baja a systemd-nek, illetve mi ez a konzol "fagyás"?
-
vzozo
senior tag
Sziasztok, a Samba NMBD modulját hogyan lehet rávenni, hogy hagyja abba a logszemetelést (mégiscsak SD kártyára megy, és az meg "kopik" a folyamatos írástól):
[2020/03/30 16:19:14.892514, 0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)
query_name_response: Multiple (6) responses received for a query on subnet 192.168.1.y for name WORKGROUP<1d>.
This response was from IP 192.168.1.x, reporting an IP address of 192.168.1.z.
Kutakodtam a neten, arra jutottam, hogy ha ezeket beírom, akkor elmúlik:
local master = no
domain master = no
preferred master = no
Nem nyert.
A másik IP, amire hivatkozik, az egyébként egy raspberry a helyi hálón, de igazából nekem abszolút nem kell ez a marhaság, csak egy sima SMB fájlmegosztást akarok használni...
-
vzozo
senior tag
Van DNS szerverem, mire kellene NetBIOS névfeloldás?
Egyébként:
root@odroidn2:/var/log/jellyfin# smbd -V
Version 4.7.6-Ubuntu
Mondjuk ehhez is lenne egy kérdésem akkor már. Miért 4.7.6, még apt-get update / upgrade után is?
https://www.samba.org/ szerint a 4.12.0 a legfrissebb. Azért ez a 4.7.6 NAGYON nem egy mai darab:
=============================
Release Notes for Samba 4.7.6
March 13, 2018
=============================
-
vzozo
senior tag
Sziasztok,
PARTUUID-et hogyan lehet megváltoztatni? Armbian fórumban azt írják, valszeg azért nem bootol be a rendszer "nand-sata-install" után, mert az SD kártya klónozva lett a külső diszkre, és hiába más az UUID-jük, a PARTUUID ugyanaz maradt:
root@odroidn2:/boot# lsblk -o NAME,MOUNTPOINT,UUID,PARTUUID
NAME MOUNTPOINT UUID PARTUUID
sdb
└─sdb1 afe760a1-xxx 70bd7af3-01
mmcblk1
└─mmcblk1p1 / 2b2fb355-yyy 70bd7af3-01
Egyébként "papírforma" szerint mennie kéne:
root@odroidn2:/boot# head boot.ini
ODROIDN2-UBOOT-CONFIG
setenv rootdev "UUID=afe760a1-xxx"
setenv rootfstype "ext4"
De csak egy nagy büdös fekete képernyő fogadott a restart után, szóval most itt vagyok meglőve.
Ami toolokat, fórumokat, stb. találtam mindenki mindenhol csak az UUID-et változtatja, az nem egy nagy művészet tune2fs-szel, csakhogy itt nem erre lenne szükség...
-
vzozo
senior tag
válasz Jester01 #30018 üzenetére
Köszi, de nem nyert, azt mondta "the partition table has been altered" meg "syncing disks", de semmi se történt. Újabb pár órányi szopás után rájöttem, hogy a sima fdisk (x -> i) is pont alkalmas erre, csak azt a kibebaszott UUID-ot 0x-szel kezdve kell megadni neki.
Siker.
Persze az odroid továbbra se bootol be, hogy olvadna szét a procija...
-
vzozo
senior tag
válasz #68216320 #30034 üzenetére
RAID5-nél azt vedd figyelembe, hogy ha az egyik diszked meghibásodik, akkor van kb. 10-15 órád arra, hogy kicseréld, és imádkozz közben, hogy egy második lemez ne adja meg magát, mert egyébként még nem épült újra a tömb, és mindent elvesztesz. Nem hiába nem menő a RAID5 már jó ideje...
-
vzozo
senior tag
Adott egy Odroid N2, és USB-SATA adapteren keresztül egy SSD-ről fut a rendszer. Szeretnék biztosra menni, hogy a TRIM használva van, mivel a SMART adatok szerint a wear level elkezdett durván növekedni szinte nulla használat mellett
Titt nem látok discard opciót az fstab-ban:
/dev/sda1 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,data=writeback)
/dev/sda1 on /var/log.hdd type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,data=writeback)
Legalább van noatime.
Ugyanakkor maga a diszk elvileg támogatja:
root@odroidn2:/home/vz# lsblk --discard
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 4K 4G 0
└─sda1 0 4K 4G 0
sdb 0 0B 0B 0
└─sdb1 0 0B 0B 0
mmcblk1 0 4M 3.5G 1
└─mmcblk1p1 0 4M 3.5G 1
zram0 0 4K 2T 1
zram1 0 4K 2T 1
root@odroidn2:/home/vz# hdparm -I /dev/sda | grep TRIM
* Data Set Management TRIM supported (limit 8 blocks)
Innen ti merre indulnátok tovább? Simán tegyem be a "discard" opciót az fstab-ba? Illetve olvastam az "fstrim" toolról, de őszintén szólva nem tiszta, hogy mi volt a gond a "discard" mountolással, miért kellett új valamit kitalálni?
[ Szerkesztve ]
-
vzozo
senior tag
válasz Frawly #30337 üzenetére
Köszi mindkettőtöknek. Qrva sok szívás van az USB-SATA miatt, de az SBC-knek ez a borzasztó hátrányuk, már ezerszer megbántam, hogy ebbe vágtam a fejszémet. Ugyanakkor a lakásban jelenleg nincs olyan zug, ahová elrakhatnék egy "rendes" x86 alapú vasat, asszony meg nyilván nem szeretné se a nappaliban, se a háló- vagy gyerekszobában látni. Paff.
Itt (https://forum.manjaro.org/t/solved-trim-not-working-on-a-usb-3-0-drive/45585/33) azt állítják hogy a JMS 578 támogatja a trimet.
Ami érdekes az fstrim-mel, hogy amikor először futtattam 19-én a posztolás után, akkor trimmelt kb. 220 gigát. Majd pár órára rá néhány megát.
Most délelőtt újra futtattam, és:
root@odroidn2:/home/vz# fstrim -a -v
/var/log: 39.3 MiB (41156608 bytes) trimmed on /dev/zram0
/media/mmcboot: 56.7 GiB (60854341632 bytes) trimmed on /dev/mmcblk1p1
/: 226.8 GiB (243520970752 bytes) trimmed on /dev/sda1
kb. fél órával később:
/: 69.3 MiB (72646656 bytes) trimmed on /dev/sda1
Volt a hétvégén néhány restart, lehet amiatt trimmelte újra az egész SD-t és az SSD-t is? Fura...
-
vzozo
senior tag
válasz lionhearted #30340 üzenetére
Nekem még mindig nem tiszta, hogy pontosan mit csinál az fstrim. Ilyen rövid idő alatt nem tud ~200 gigát kiírni, tehát pontosan hova, hogyan mondja el az SSD-nek, hogy akkor azok üres blokkok?
-
vzozo
senior tag
válasz lionhearted #30342 üzenetére
Köszönöm a válaszod - igazából ez a nagyvonalakbeli működés úgy-ahogy tiszta volt számomra is. Amit nem értek, hogy pontosan mi is történik, mivel itt pár másodperc alatt lezajlik az akció akár a 64 gigás SD kártyára, akár a 200 gigás SSD-re.
A teljes fájlrendszer összes blokkja a memóriában van mountolás után, és ezért fut ez le ilyen gyorsan?
[ Szerkesztve ]
-
vzozo
senior tag
válasz Dißnäëß #30349 üzenetére
Nem fogok farokméregetési versenybe kezdeni, hogy ki mennyi LB-vel dolgozott már az év(tized)ek alatt, de azért vegyük már észre, hogy egy Layer4 LB-vel túl sokat itt nem tudsz tenni source IP affinity beállításán kívül vagy SSL termináláson (de az meg L7, és általában nem load balancernek, hanem proxy-nak nevezzük.)
Persze ha megosztod a megoldásod, azzal mindenki előrébb lesz.
-
vzozo
senior tag
Sziasztok, a nagy kérdésem az lenne, hogy mi alapján tartja "használatban" egy Linux OS a külső (USB-s) HDD-t? Konkrétan az a célom, hogy ha nincs használatban a diszk (kb. az esetek 95%-ában), akkor álljon le magától. Az enclosure van annyira okos, hogy ezt meg is teszi, pl. Raspberry-vel, Odroid N2-vel. Mindkét rendszeren valamilyen Debian klón van (raspbian, illetve armbian buster.)
Totál ugyanaz a HDD, totál ugyanazon samba beállítások mellett leáll ha nincs használva. És ez így van jól. Nincs szükség semmi hdparm varázslatra.
Ellenben most próbálkozom egy x64 alapú gépen Proxmox-szal, és habár az is debian alapú, az istenért nem állítja le a vinyót. Tudom, hogy rendszeresen pollolná a diszkeket SMART ügyileg, exceptiont beállítottam a külső lemezre. Semmi.
Egyedül ami használ, hogy ha tolok egy hdparm -B 1 / -S 36 parancsot, és akkor 3 perc után tényleg leáll a lemez, de nem maga az enclosure. A diszk nem pörög tovább, nem melegszik, halleluja - habár a SMART power on számláló továbbra is növekszik. Less than ideal.
Erre gondoltam egy olyat, hogy totál alap Linux VM-be USB passthru-n bekötöm a HDD-t, és láss csodát, bármiféle hdparm ügyködés nélkül ugyanúgy leáll a lemez, mint a fentebb említett ARM boardokkal.
Mi az amit nem veszek itt észre?
- A külső vinyó ugyanaz, ugyanazzal a fájlrendszerrel, ugyanúgy felmountolva
- smbd.conf dettó ugyanaz
- Egyedül az smbd verziók mások:Pi: Version 4.5.16-Debian
Odroid: Version 4.9.5-Debian
Proxmox hoszt: Version 4.13.13-Debian
VM: Version 4.13.14-Ubuntu -
vzozo
senior tag
Sokat agyaltam, hogy ez most kezdő vagy haladó téma, biztos-ami-biztos alapon megkérdem tőletek is:
Tervezési / elméleti kérdésem lenne jogosultságkezelés kapcsán.
Adottak:
- NTFS külső merevlemez NTFS3 driverrel mountolva (ez fontos, mert a -3G-vel szemben ez betartatja a linux jogosultságokat, és ha nem specifikálok usert vagy groupot a mountolás során, akkor csak a rootnak lesz írásjoga a fájlokhoz)
- Az egész meghajtó SAMBA share-en megosztva read/write, full jogosultságokkal egy külön erre a célra létrehozott nologin "samba" accounttal
- SSH-n / SCP-n távolról másolnék fájlokat a meghajtóra egy harmadik user accounttal (se nem root, se nem a samba júzer, hiszen annak le van tiltva a bejelentkezése)Itt mi lenne a best practice? Mivel vagy az SMB megosztáson, vagy SCP-n kaptam access denied hibákat, egyelőre erre jutottam:
- sambagroup group létrehozása, ebbe belepakolva a samba júzert illetve az SSH-s másolós júzert
- sambagroup GID-jével mountolom a merevlemezt, és a csoportra adok rwx jogot
- profit?Nyilván a következő probléma az lesz, hogy ha akarok read-only samba júzert hozzáadni, akkor azt pontosan hogyan tegyem meg. Vagy mivel az "other" kategória amúgy is r-x jogosultságokkal rendelkezik, olvasni kb. bármi fogja tudni, és így jó is vagyok?
drwxrwxr-x 1 root sambashare 0 Mar 22 10:02 Fotok
-
vzozo
senior tag
válasz fatpingvin #32193 üzenetére
Ezt értem, köszönöm. Akkor próbáljuk csak a linuxos "owner:group:all other" jogosultságkezelési oldalról kezelni a kérdést, ebben az esetben mit javasoltok?
Új hozzászólás Aktív témák
- PC JÁTÉKOK (OLCSÓ STEAM, EA , UPLAY KULCSOK ÉS SOKMINDEN MÁS IS 100% GARANCIA )
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Adobe Creative Cloud - 2024. 04. 05 - 2025. 04. 05-ig
- Megmaradt - Eredeti Humble, Choice - Steam kulcsok
- 10 Darab PC Játék (Bontatlanul!) Egyben 6990Ft.-ért Foxal!!!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen