Fórumok
Sziasztok,
Eleg faramuci a topic cime de a kovetkezrol van szo:
Adott egy VM (Alpine Linux) amin a fajlokat gond nelkul tudom olvasni halozatrol (SMB, SCP, etc..) de irni nem tudok semmit... ma vettem eszre, de sztm par napja kezdodott... nem tudom mi lehet az oka, voltak frissitesek de nem tudom konkrethoz kotni.
Tuzfal nincs az Alpine-on.
Hozzászólások
Annyi meg, hogy az Alpine egy Proxmoxon fut, mas VM-ekkel. Azokra gond nelkul megy a masolas, igy sztm a halozatot kizarhatjuk. VLAN nincs egy alhalozatban van a celgep es az alpine.
Letrehozni amugy tudok fajlt, pl smb-n keresztul, de ha egy nagyobb falt (akar egy 5 megasat) akarok akkor megall egybol. Nem csak nem engedi atmasolni, de az SMB megsztas is lefagy ujra kell inditani a samba-t...
kiegeszites, kozben megprobaltam masik eszkozrol, nem a Win PC-rol h kizarjam, nem-e ott van gond, de telorol is ugyanaz... fajlt enged olvasni,de irni mar nem...
Nem lehet, hogy megtelt a háttértár? Mármint a virtuális gépé. A df -h mit mond róla?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
nekem is eszembe jutott, de nem...
Probaltam amugy irni a gyokerre (sda3) es az adat diskemre (sdb1) de ugyanaz az eredmeny... tehat meg nem is eszkozhoz kotott...
Termeszetesen ha belepek az alpine ra es ott copyzok ide/oda az megy... tehat nem valami eszkoz hiba, h mondjuk valamiert read only lett vagy ilyesmi... Csak halozati protokollokon nem tok masolni. Eddig ott cifs/scp/sftp volt probalva, egyik sem megy.
Ha pl smb-n kersztul letre hozok egy txt fajlt uresen, majd beleirok, az is megy. De egy 5 megas fajlt mar nem tok atmasolni...
Nem vagyok egy Samba mágus, de ez valamilyen smb jogosultságnak tűnik. Hovatovább SELinux, ha használsz olyat, vagy akármi. Meg az is izgalmas lehet, van-e bármiféle quota valahol. Érzésből vagdalkozok, ha tudnám a megoldást, mondanám. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ja, amúgy érdekesség. Egyszer csak elmúlt a gépemről a céges hálózat vpn elérése. Felhívtam a rendszergazdánkat, változott-e valami, mondja, nem. Elkezdtem intuitív módon vadászni a hibára, olvastam logot is. Ezt amúgy neked is ajánlom, hátha mesél valamit, miben akad meg!
Láttam, authentikációs hiba. Downgrade-eltem a NetworkManager-openvpn csomagot, mire megjavult. Aztán tiltólistára tettem a csomag frissítését, nehogy visszafrissítse a rosszra, majd írtam bugreportot a fejlesztőknek.
Igaz, workaround, de tudok itthonról dolgozni továbbra is. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
nezem en is a logokat folyamtosan, de semmi konkret... az a bajom h ha csak a samba lenne, akkor is egyszerubb , de mas sem jo, pl scp vagy sftp... ez inkabb halozati gondra utal, de nem tudom, hol... tuzfal nincs koztuk, mas VM re jo.. nem ertem.
> ha egy nagyobb falt (akar egy 5 megasat) akarok akkor megall egybol.
ez inkabb MTU gond lesz
VM ek halokartya configja ugyanaz. Masik VM-nel nem jelentkezik a problema.
Attól, hogy egyforma még nem biztos, hogy jó. A path mtu discovery ügyesen el tudja rejteni. Aztán ha egy VM-en a tüzfal nem engedi át a megfelelő icmp üzenetfajtákat, akkor a pmtu discovery nem fog menni és hirtelen kibukik a probléma.
Mielőtt kizárnád, mindenképpen csekkold le ping -d -s <méret> az egyes gépek között, hogy mekkora a legnagyobb csomagméret, ami még ténylegesen átmegy.
Régóta vágyok én, az androidok mezonkincsére már!
1472-es MTU val tudok meg pingelni, magasabbal nem. De ez egy mukodo VM-nel is ugyanez.
Pedig akkor ez a további nyomozási irány. Egyrészt kisérletképpen kézzel le kéne venni az MTU-t a nem működő vm-ben és megnézni eltűnik‐e hibajelenség. Másrészt megnézni, hogy problémás vm-ben mi van máshogy beállítva a path mtu discovery kapcsán. A tűzfalon icmp fragmentetion needed csomag át nem eresztése az első gyanúsított. Aztán jöhetnek a kapcsolódó sysctl paraméterek, amiknek a nevében van 'pmtu'.
Régóta vágyok én, az androidok mezonkincsére már!
Ha egy subnetrol beszelunk, akkor lehet tuzfal gond? (magan a szerveren nincs tuzfal)
A tobbit megnezem.
A tűzfal megléte vagy nemléte független a subnetektől. Nem csak routeren lehet.
Régóta vágyok én, az androidok mezonkincsére már!
tudom, de erre irtam h nincs tuzfal az Alpine linuxon.
Probakepp csokkentettem az MTU-t de nem segitett sajna.
Hát akkor sajnos jön a tcpdump egyidejűleg mindkét oldalon egy problémás session közben, és megpróbálni megfejteni hátulról előre az elakadás előtti utolsó csomagokat, hogy mi nem megy át.
Régóta vágyok én, az androidok mezonkincsére már!
Ennyi latszik, amikor elkezdenek masolni (ez a server oldali tcpdump)
Ez pedig a masik oldal, itt epp scp-n keresztul akarok folmasolni valamit.
Na, ebből nem fogjuk megfejteni. Próbállak megtanítani halászni.
Pár jótanács a hálózat-debuggoláshoz:
Régóta vágyok én, az androidok mezonkincsére már!
Koszonom! megnezem ezeket. (hal istennek eddig nem kellett halozattal foglalkoznom, a munkam mas. de ez most otthoni cucc szoval muszaj vagyok...)
Lehet, hogy valami thin provisionból van a VM diszkje és a hoston fogyott el a szabad blokk?
$ grep -c egy$ word.list
100
az is ok:
illetve localban megy a copy es wget el letolteni is tudok az alpine ra.
hmm a proxmoxrol tudok masolni scp-vel a VM-re... egyre furcsabb ez...
Meg az iperf3 sem megy, csak egy iranyba... nem tudom mi lehet ez. Elsore fullra valami tuzfalas dolognak tunik, de az nem lehetseges...
Egy mount kimenetet az Alpine-ban esetleg nézz, nem lett véletlen valami RO?
Nem , mert direktben tehat nem halozaton keresztul enged masolni, sot mint kiderult, ha VPN-en vagyok akkor is...
Kezdek arra gondolni h a helyi halozatban van a gond... Ubiquiti switcheim vannak, lehet azok csinaljak? (neztem a beallitasokat, de nem latok valtozast, meg mar restartoltam is oket)
.
Meg egy erdekesseg... Most nem vagyok otthon es a notimrol, VPN en keresztul (tailscale) probalok ra masolni fajlt, ugy mukodik...
Hát, én ez alapján (meg a fenti ping eredmény alapján) szintén az MTU-ra mutogatnék.
Alpine oldalon hogyan tudom ezt tesztelni?
tegnap mar vissza allitottam egy 3 napos mentest kinomban a VM-en, de az sem segitett...
Megprobaltam megvaltoztatni a linux IP-jet, hatha IP alapon fogja valami, de ez sem nyert...
Valami üzenet akármilyen (samba,os) logokban hogy permission denied mikor másolni/írni akarsz? Ami megtiltja csak odaböffent valahova valamit hogy miért teszi amit tesz.
samba log biztos nem normalis amit mutat....
testparm -v ?
Samba log van egy két error:
2024-08-12T11:31:54.015449042Z idmap range not specified for domain '*'
2024-08-12T11:31:54.015613470Z Failed to fetch domain sid for WORKGROUP
2024-08-12T11:30:51.719690674Z smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[5] status[STATUS_NO_MORE_FILES] || at ../../source3/smbd/
Valami karakterkészlet, widelinks, verzió akármi nem tetszik neki lehet és amiatt döcög csak.
En nem latok gondot:
- alapbeállításokkal lett létrehozva a VM?
- VirtIO driver-k vannak használva, vagy más kompatibilitás üzemmód van beállítva?
- alapbeallitas igen
- virtioval mennek
Eddig amugy (tobb eve) gond nelkul ment a szerver, 2-3 napja tortent valami.
proxmoxon a vm alatt külön is van firewall. azt kikapcsoltad?
Gábriel Ákos
igen, kikapcsoltam (be sem volt :) )
Egy dolog amit nem irtam meg. Az Alpine Linux lenyegeben egy docker node-nak van hasznalva, szinte nincs is local app telepitve, minden kontenerbol fut. (a samba is)
A docker esetleg bekavarhat a halozatba?
végülis csak a lényeget sikerült kifelejteni :)
Gábriel Ákos
Oszinten nem akartam senki belevinni az erdobe a kontenerekkel :)
Iletve, mivel a problema jelentezik egy sima scp copyval is (ami nyilvan nem kontener :) ) Igy gondoltam nincs osszefugges...
Akkor most már csak azt kéne eldöntened hogy a docker releváns információ vagy sem.
Sajnos nagyon rossz a hibaleírásod.
Szét kéne szálaznod a történetet hogy végre kiderüljön:
- mi is akar a végkifejlet lenni
- melyik layer-ig "jó" a kommunikáció és honnantól "rossz"
Ugyanis ha ezt a határt tudjuk akkor sokkal könnyebb célzottan kérdezni/segíteni
Gábriel Ákos
Ahogy lentebb irtam, volt egy mukodo Alpine telepitesem (virtual kernel, lenyegeben a tiszta telepitesen kivul volt egy zabbix agentem amit folraktam es ennyi plusz ugye a Docker engine)
Minden cuccom (samba, radarr, sonarr, qbittorrent, meg "100 mas") kontenerben fut, az egeszet portainer-el managelem.
Par napja a kezdo posztban irt hibajeleneseget produkalja. Erre van szo zanzasitva.
Ha van meg reszlet, ami fontos lehet, szivesen leirom!
"A docker esetleg bekavarhat a halozatba?"
Az iptables/nft alapján be is kavar :)
btw a vegyes docker, nemdocker setup a létező legszarabb kombó, a legtöbb szopással és a legtöbb potenciális eltörési lehetőséggel.
vm-en belül én biztos hogy tisztán akarnám tartani, vagy full dockeres minden, vagy full csomagból jön minden.
csinálj két vm-et ha mindenképp vegyes akar lenni a felvágott.
Gábriel Ákos
Pont arra torekedtem, hogy ne legyen vegyesvagott csak Docker.
A telepites:
- Alpine OS, virtual kernel
- Zabbix agent a monitoring miatt
- ssh a belepes miatt
- Docker engine (nyilvan)
es ennyi. Minden egyeb kontener. (meg a top helyett is glances-t hasznalok)
most egy 4 megas (!!) fajlt sikerult atnyomni cifs-en, de marha lassu volt, kb 150kbps sebessegel ment, vagy 5 percig... kozben egy csomoszor megallt a masolas...
Windows naplo amugy valoszinusitheto halozati hibat ir az smb client log ban... (mondjuk ezt eddig is sejtettem)
Az lesz még szép, ha a végén kiderül, hogy el van törve egy UTP kábel, vagy rosszul van krimpelve egy RJ45. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Mar en is gondoltam erre komolyan :D
nyilvan nem lehet, ugyanazon a hoston mas VM-re gigabit el masolok :)
Viszont - ha jól értem - ugyanez olvasásra ~ tökéletesen megy, ugye?
olvasasra tokeletes igen.
Ujabb teszt, vm snapshot, letoroltem a dockert minden halozati inerfeszet (brige-eket) restart es teszt scp-vel. Igy sem megy a feltotes...
Viszont... megint uj fejlemeny... ugy nez ki, megis beneztem, marmint hogy mindenhonnan rossz... Tegnap a telorol (iphone) problaltam masolni cifsel es az nem ment, de ma ujra probaltam sftp-vel es ugy fullos a sebesseg! (ezek szerint a cifsel mas gond volt a telon, azt most mind1 is) tehat akkor megis a kliens lehet a gond.. (egy win10) sajnos a haztartasban nincs masik Win PC amivel meg tudnam tesztelni...
szerintem a lotto 5-ost hamarabb eltalaljuk mint hogy mi van nalad elbaxva :)
Erdekes viszont, most h kicsit konkretizaltam a dolgot, a net tonnanyi talalatot ad "one way slow speed windows" keresésre :D
sokan irjak h a "355 kb/s" a varazsszam, sokaknak annyira lassul be az egyik irany.
pl: https://superuser.com/questions/855798/slow-network-copy-in-only-one-di…
halfduplex vs fullduplex? bar ezzel gigabiten mar nem talalkoztam, de regen 100mbitnel gyakori volt hogy nem ugyanugy allt be a 2 halokartya es emiatt egyik iranyba behalt a sok collision miatt
full duplex. De az meg mindig fennall h masik VM-re nincs gond.
Kinomban csinaltam ezt a videot h aterezzetek :D
https://streamable.com/r0i0xj
Tehat a ket IP (192.168.31.105/106) ugyanazon proxmoxon fut, egyik egy alpine linux a masik home assistant OS. a ket share cifs, nyilvan. A kliens gep egy win10, csak innen xar, de csak az egyikre (a 105-re nyilvan). Mindharom gep egy subnetben, tuzfal sehol sincs.
Ami meg ma eszembe jutott:
Toroltem a problemas VM halokartyajat es letrehoztam egy ujat (mas MAC lett ) de ez sem segitett...
Ma hazaviszek cegtol egy USB-s halokartyat... :)
Illetve csinalok egy live ubuntut, meglatjuk azzal mi lesz (ugyanazon a gepen)
Ok a masik háló kártya nem segített viszont live ununtu ról tökéletes ….
tehat úgy néz ki, a win lesz a ludas….
Lecserélted a servert és most jó.
De a kliens a ludas.
Mit nem értek?
Gábriel Ákos
Csinaltam egy live ubuntut, bebootoltam a kliensen (windows) felmountoltam a samba share-t es tudtam feltolteni a serverre.
Bocs, lehet rosszul fogalmaztam. (neha beveszem a fogalmazasgatlot, meg csapongok egy mondat kozott is, masok is panaszkodnak ra :D )
Ja, a klienst cserélted le. Így már világos. Tényleg bevetted a fogalmazásgátlót.
A kliens a "hibás", illetve inkább úgy fogalmaznék: a serveren kéne valamit állítani hogy tolerálja a kliens hülyeségét.
De akkor már tiszta a kép: infra oldalon minden jó, sambát/windowst kell konfigurálni.
Gábriel Ákos
Igen kb errol van szo.
Annyi, h nem csak samba, de minden TCP kommunikacio. (SCP, cifs, iperf minden xar...) UDP az jo. (iperf megy UDP vel)
Uj fejlemeny, jatszottam meg az iperf3 al es rajottem egy erdekessegre!!
Tehat a gond csak TCP eseten jelentkezik!
Ellenkező irányban ok a TCP is.
Most mar egy masik VM-nel is csinalja....
Egyre jobb... Igy mar gyanakszom a Proxmoxra is... a 8.2-es kiadas pont hozzanyult a halozatokhoz...
vegen kiderul h olyan mint a mikrotik os, a licensz nelkuli verzio korlatozza a savszelt :)
Lehet nincs osszefugges, de a masik vm akkor allt meg, amikor az OS (Home Assistant) kapott frissitest, veletlenul pont azt a kernel verziot, amit az alpine is... 6.6.44 nem mondom h nem veletlen , de gyanus...
Nem hiszem el..... MEGVAN!!!!!!!!
A kernel volt a ludas... a 6.6.44 nem jo, a 6.6.45 (most johetett meg nemreg, ma dobta fol nekem frissitesnek) szinten nem jo.. Mondom akkor megprobalok "elore menekulni" es feldobok egy edge repository-t az alpinehoz hatha... ez a 6.6.46 os kernelt hozta (meg meg jopar csomag frissitest, koztuk pl a dockert is amugy...) ezzel megy a masolas, mit a parancsolat!!
A mai Home Assistant update marha nagy segitseg volt, ez terelte a figyelmem a kernel fele...
Nyilvan lehet nem a kernel a ludas, hiszen a docker is frissult (meg meg par dolog) de valahol ott lehet a kutya elasva... megprobalom ossze hasonlinani a HA OS-el a package-eket, hol a kozos pont.. (mondjuk ott a changelog nem ir docker frissitesrol) .Szolnom kell a HA fejleszoinek is h valamit kezdjenek azzal is...
Ezek frissultek:
(1/1) Upgrading apk-tools (2.14.4-r0 -> 2.14.4-r2)
Executing busybox-1.36.1-r29.trigger
Continuing the upgrade transaction with new apk-tools:
(1/57) Upgrading musl (1.2.5-r0 -> 1.2.5-r2)
(2/57) Upgrading alpine-baselayout-data (3.6.5-r0 -> 3.6.6-r0)
(3/57) Upgrading busybox (1.36.1-r29 -> 1.36.1-r31)
Executing busybox-1.36.1-r31.post-upgrade
(4/57) Upgrading busybox-binsh (1.36.1-r29 -> 1.36.1-r31)
(5/57) Upgrading alpine-baselayout (3.6.5-r0 -> 3.6.6-r0)
Executing alpine-baselayout-3.6.6-r0.pre-upgrade
Executing alpine-baselayout-3.6.6-r0.post-upgrade
(6/57) Upgrading ifupdown-ng (0.12.1-r5 -> 0.12.1-r6)
(7/57) Upgrading openrc (0.54-r1 -> 0.54.2-r1)
Executing openrc-0.54.2-r1.post-upgrade
(8/57) Upgrading busybox-mdev-openrc (1.36.1-r29 -> 1.36.1-r31)
(9/57) Upgrading alpine-keys (2.4-r1 -> 2.5-r0)
(10/57) Upgrading alpine-release (3.20.2-r0 -> 3.21.0_alpha20240807-r0)
(11/57) Upgrading ssl_client (1.36.1-r29 -> 1.36.1-r31)
(12/57) Upgrading busybox-openrc (1.36.1-r29 -> 1.36.1-r31)
(13/57) Upgrading busybox-suid (1.36.1-r29 -> 1.36.1-r31)
(14/57) Upgrading musl-utils (1.2.5-r0 -> 1.2.5-r2)
(15/57) Upgrading alpine-base (3.20.2-r0 -> 3.21.0_alpha20240807-r0)
(16/57) Upgrading runc (1.1.12-r5 -> 1.1.13-r1)
(17/57) Upgrading containerd (1.7.17-r2 -> 1.7.20-r0)
(18/57) Upgrading libblkid (2.40.1-r1 -> 2.40.2-r0)
(19/57) Upgrading libmount (2.40.1-r1 -> 2.40.2-r0)
(20/57) Upgrading glib (2.80.2-r0 -> 2.80.4-r0)
(21/57) Upgrading containerd-openrc (1.7.17-r2 -> 1.7.20-r0)
(22/57) Upgrading libnftnl (1.2.6-r0 -> 1.2.7-r0)
(23/57) Upgrading docker-engine (26.1.5-r0 -> 27.1.2-r0)
(24/57) Upgrading docker-openrc (26.1.5-r0 -> 27.1.2-r0)
(25/57) Upgrading docker-cli (26.1.5-r0 -> 27.1.2-r0)
(26/57) Upgrading docker-cli-buildx (0.14.0-r3 -> 0.16.2-r0)
(27/57) Upgrading docker (26.1.5-r0 -> 27.1.2-r0)
(28/57) Upgrading libcom_err (1.47.0-r5 -> 1.47.1-r0)
(29/57) Upgrading e2fsprogs-libs (1.47.0-r5 -> 1.47.1-r0)
(30/57) Upgrading libuuid (2.40.1-r1 -> 2.40.2-r0)
(31/57) Upgrading e2fsprogs (1.47.0-r5 -> 1.47.1-r0)
(32/57) Upgrading zstd-libs (1.5.6-r0 -> 1.5.6-r1)
(33/57) Upgrading iproute2-minimal (6.9.0-r0 -> 6.10.0-r1)
(34/57) Upgrading ifupdown-ng-iproute2 (0.12.1-r5 -> 0.12.1-r6)
(35/57) Upgrading iproute2-tc (6.9.0-r0 -> 6.10.0-r1)
(36/57) Upgrading iproute2-ss (6.9.0-r0 -> 6.10.0-r1)
(37/57) Upgrading iproute2 (6.9.0-r0 -> 6.10.0-r1)
(38/57) Upgrading linux-firmware-none (20240513-r0 -> 20240709-r1)
(39/57) Upgrading device-mapper-libs (2.03.23-r3 -> 2.03.23-r4)
(40/57) Upgrading cryptsetup-libs (2.7.2-r0 -> 2.7.4-r0)
(41/57) Upgrading mkinitfs (3.10.1-r0 -> 3.10.2-r0)
Executing mkinitfs-3.10.2-r0.pre-upgrade
Executing mkinitfs-3.10.2-r0.post-upgrade
(42/57) Upgrading linux-virt (6.6.45-r0 -> 6.6.46-r0)
(43/57) Upgrading openssh-keygen (9.7_p1-r4 -> 9.8_p1-r1)
(44/57) Upgrading ncurses-terminfo-base (6.4_p20240420-r0 -> 6.5_p20240601-r0)
(45/57) Upgrading libncursesw (6.4_p20240420-r0 -> 6.5_p20240601-r0)
(46/57) Upgrading openssh-client-common (9.7_p1-r4 -> 9.8_p1-r1)
(47/57) Upgrading openssh-client-default (9.7_p1-r4 -> 9.8_p1-r1)
(48/57) Upgrading openssh-sftp-server (9.7_p1-r4 -> 9.8_p1-r1)
(49/57) Upgrading openssh-server-common (9.7_p1-r4 -> 9.8_p1-r1)
(50/57) Upgrading openssh-server-common-openrc (9.7_p1-r4 -> 9.8_p1-r1)
(51/57) Upgrading openssh-server (9.7_p1-r4 -> 9.8_p1-r1)
(52/57) Upgrading openssh (9.7_p1-r4 -> 9.8_p1-r1)
(53/57) Upgrading mtools (4.0.43-r1 -> 4.0.44-r0)
(54/57) Upgrading blkid (2.40.1-r1 -> 2.40.2-r0)
(55/57) Upgrading sqlite-libs (3.45.3-r1 -> 3.46.1-r0)
(56/57) Upgrading zabbix-agent2 (6.4.15-r2 -> 7.0.2-r0)
(57/57) Upgrading zabbix-agent2-openrc (6.4.15-r2 -> 7.0.2-r0)
Wow, jumbo frame elbaszás. Valamikor ezer éve, amikor csináltam a legutóbbi network upgrade-t otthon akkor olvastam hogy a jumbo frame-et el kell felejteni, több kárt csinál mint hasznot. Ki is kapcsoltam. Sose tudtam volna reprodukálni a hibádat... :)
Gábriel Ákos
ha valakit erdekel, a hiba reszletes leirasa:
https://bugzilla.kernel.org/show_bug.cgi?id=219129
Home Assistant alatt is eszleltek, 13.1 ben lesz javitva:
https://github.com/home-assistant/operating-system/issues/3532
https://github.com/home-assistant/operating-system/pull/3529
Ahogy nézem a kommentek végét, a 6.10.5-ös kernelt használó gépemnek nem lesz efféle gondja. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nem, bekerult a patch mindket stabil agba (6.10 és 6.6)
Illetve foleg ott tunt fel, ahol linux - windows kapcsolat van.