UPC vs. Dist-upgrade

Nos ezúton szeretném megköszönni a UPC közreműködését, hogy kaptam egy nem bootoló rendszert, mert frissítés közben kell összerohadnia a netnek. Szépmunka! Net nélkül megakadt, minden próbálkozásra timeout és így csak állt a gép fél napig. Mikor újra lett net, folytatta szépen a frissítést. Csak az addig nem frissített csomagok miatt borult a bili...

Gőzömsincs mi lett a probléma, még nem néztem rá jobban. A lényeg, hogy boot során elakad. Gondolom nem tetszik neki, hogy fél rendszer ki van cserélve.

# update:
Recovery lemezzel le tudtam frissíteni és mostmár bootol.

( traktor | 2017. 02. 22., sze – 12:40 )

Szerintem itt kar a UPC-t okolni... eleg alap funcionalitasnak hangzik, hogy egy csomagkezelo ne boruljon meg azert mert lehal a halo. Nem is ertem egyebkent apt-vel (ha jol ertem az) hogy tortenhet ilyen. Az apt eloszor letolti az osszes csomagot es csak azutan kezdi a valodi frissitest.

Az volt a baja, hogy töltötte volna le a csomagot, de nem tudta, ezért timeout után folytatta a következő csomaggal, így pár száz csomag kimaradt a letöltésből, majd elkezdte felpakolászni, mikor odaért. Mivel úgy állítottam be és hagytam a gépet a egyedül, ezért végrehajtott kérdezés nélkül. Nyilván ez az én hibám, de azért hadd köpködjek már valamit, ami sokba kerül és még szar is...

A UPC-vel konkrétan az a bajom, hogy egy instabil foskupac, még ha arról lenne szó, hogy előre bejelentett karbantartás, még le is nyelném. De az, hogy 10 napból lagalább 6 úgy telik el, hogy kisebb-nagyobb leállások vannak, már eléggé vérlázító. Mondhatnám, hogy "De a csekket azt küldik". De még az is általában befizetési határidő lejárta után érkezik meg.

--
openSUSE 42.1 x86_64

Az UPC nem egy instabil foskupac.
Eddig a jó hír.
Sajnos létezik hibás hálózat is. Ha az instabilitás tartós, akkor utána kell járnod! Újabban nagyobb felkészültségű hibaelhárítókat alkalmaznak. A kábelmodemet, a kapcsolatot, a zajt is folyamatosan mérik. Kell hozzá némi türelem, és szerencse, hogy a hiba bejelentésénél a megfelelő embert csípjed el. De megoldható, csak a cél érdekében le kell vetkőzni ezt a tudatos, de sültgalamb leső fogyasztói magatartást.

+1

Ugyan nem UPC, egy kis szolgáltatónál vagyok, de a szerződés megkötésekor hoztak egy használt modemet, az első kb. 6 hét simán ment. Utána iszonyú belassulások, akadozások, használhatatlan hálózat. Nem is gondoltam modem hibára, mert elértem a webes felületét, nem indult újra. Jeleztem a szolgáltatónak, próbáltam összeszedni releváns logokat. Megköszönték, hoztak vadonat új, dobozból frissen kicsomagolt modemet, azóta egyetlen bit hiba nem volt a hálózaton. :) Stabil, a sebesség rendben, működik.

Szerk.: meg aztán egy cégről, különösen egy nagy cégről, amelynek elég sok jogásza van, nem biztos, hogy szerencsés széles nyilvánosság előtt megalapozatlanul érzelemtől vezérelve olyasmit állítani, amely nem tünteti fel túl jó színben a céget, s nem is igazán bizonyítható az állítás. ;)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Az UPC nem egy instabil foskupac"

Sajnos de. Épp azzal szívok, hogy néhány napja a kedvenc online multiplayer mobilos játékom nem hajlandó kapcsolódni, ha az upc-s netet használom. Mindenhonnan máshonnan megy tökéletesen. Korábban hónapokat szívtam azzal, hogy az androidos kütyüim nem tudtak frissíteni se appokat, se a rendszert magát amíg az upc-s neten lógtak. A kávézóba járkáltam le appokat telepíteni, mert az ottani wifin ment, mobilnetet meg nem akartam rá pazarolni.

Persze hívtam őket, a hülye én voltam, mert szerintük olyan hiba nem létezik amitől csak pár dolog nem érhető el a neten, biztos a third party hibája, stb.

A különböző szolgáltatók hálózatából egyes dolgok nem érhetők el. Remélem ez nem újdonság!
Először próbáld meg a dns-t beállítani, mert abban az UPC tényleg nem nagy vitéz.
Én ezeket használom, amiből az első kettő a szolgáltatóé, azaz dhcp-vel kiosztott:
213.46.246.53
213.46.246.54
195.184.181.4
195.184.180.4
129.250.35.250
8.8.8.8

"A különböző szolgáltatók hálózatából egyes dolgok nem érhetők el. Remélem ez nem újdonság!"

Igazából de. Nem akarok naívnak tűnni, de ne már hogy ez legyen az elfogadható. Internet elérésért fizetek, nem részleges hozzáférésért. A DNS be van lőve, a Google DNS-ét használom. Telefonon csak kettőt lehet felvenni. MTU állítgatás segített gépen hasonló problémán, telefonon nincs opció állítani. A szolgáltatónak kellene alapbeállításokkal adni a teljes internetet, nem nekem konfigurálgatni hálózati beállításokat, olyanokat, amikre nincs is opcióm.

Mire akarsz célozni? (Komolyan kérdem, kevesebbet értek ezekhez a témákhoz, mint amennyit célszerű volna).

De tegyük fel level 1 felhasználó vagyok: Van egy telefonom nulla beállítási lehetőséggel, van egy routerem amiről level 1 felhasználóként nem is tudom micsoda, és van egy előfizetésem, amitől azt várom, hogy működjön, és ne kelljen ilyen random négybetűs rövidítésekkel foglalkozni.

Nem én mondom, ők írták le! Ennek az elsődleges oka az, hogy csak internetet szolgáltatnak és nem android tanácsadást, ezért nincs is kapacitásuk rá.
Amit az "alapbeállitásnak" gondolsz, abban nem is tévedtél nagyot. Egy egyszerű router gyári beállításaihoz tényleg csak a dhcp-t és a wifi jelszót kell beállítani és meg az UPC. Ugyanez vonatkozik tabletre és telefonra is.
Ugyan nem megfelelő helyre írok, de végignéztem a problémáidat. Az a play store elérhetetlenséget tesztelhetnéd más gépen is, nem csak telefonon. Ha onnan elérhető, akkor a telefon beállításaival lesz a baj. De ez sem biztos.
Félve kérdezem: Nincs véletlenül 2 router "sorba kötve"?
Működnek-e a következő funkciók:
UPC -> DHCP -> router és router -> DHCP -> telefon
Azaz a telefon honnan kap dns-t, és a router megfelelően továbbítja-e a dns szervert?

Ilyen felállással nálam soha nem volt probléma. Igaz profi tűzfalat használok pontosan beállítva és bridge módú modemet. Ha a nálad levő konfigot ismertetnéd, már beljebb lennénk!

Bocsi, de nem megoldást keresek egy problémára, hanem egy régebbi, már megoldott esetről meséltem csak, jelezve hogy igen is bajok vannak az upc háza táján néha.

Egyébként a szolgáltató routerét használtam alapbeállításokkal, és a házban lévő több androidos eszköz mindegyikével problémák voltak.

Ahogy írtam feljebb is, teszteltem router gyári beállításokkal, úgy, hogy csak az egy telefon lógott a hálózaton, amin nulla beállítási lehetőség van. Szerény véleményem az, hogy egy átlagfelhasználónak nem kell tudnia mi az a PMTU, nem kell tudnia állítani semmit (még akkor se, ha volna opció), és kellene mennie.

"A szolgáltatónak kellene alapbeállításokkal adni a teljes internetet"
Olyan nincs, hogy a Teljes Internet.
Az Internet sok-sok-sok szolgáltatói meg egyéb hálózat összekötése (internetwork, inter mint közötti, network mint hálózat), a megfelelő összekötési pontokon. Te a UPC/Telekom/Digi/whatever ISP hálózatának a része vagy. Ő adatot tud cserélni a vele szerződésben lévő ISP-k hálózatával a megfelelő adatcsere pontokon (ilyen például a BIX).
Ezek az ún. IP peering megállapodások.

Ezen kívül előírás, hogy minden hálózatüzemeltető felel a saját hálózatáért, azért, hogy a hálózatán belüli hosztok nem forgalmaznak olyan adatokat, amelyek a hálózat működésére veszélyesek lennének. Például nem üzemeltetsz olyan routert, ami a fél világ routing tábláját elrontja (jó példa, amikor a Pakistan Telecom az egész világ számára elérhetetlenné tette a YouTube-ot: https://stat.ripe.net/events/youtube-pakistan-incident).
Ugyanígy nem üzemeltethetsz csak úgy root DNS szervert sem, hogy a világ felé mutasd, hogy létezik egy .manfreed top-level domain.

Az Internet egy kényes jószág, rengeteg ember dolgozik azon, hogy az IP hálózat működjön.

Nem tudom, te mit értsz "alapbeállítás" és "teljes internet" alatt, de szerintem nem ismered az internet működését, azért vagy felháborodva ennyire.

"szerintem nem ismered az internet működését, azért vagy felháborodva ennyire."

Á, nem vagyok én felháborodva, egy kicsit mérgelődtem csupán. Leírom miért, de valójában fent már megtettem:

Képzeld el a szitut, hogy előfizetsz internetre, de egypár látszólag összefüggéstelen hosthoz nem enged kapcsolódni. Ez felhasználói szemmel úgy néz ki, hogy van egykét oldal, ami sose jön be, de minden más amit szoktál nézni igen. Emellett ott a telefonodon a play store, ami egy alkalmazást se tud telepíteni. csak teker, és timoeut. Mindez nem a szolgáltatás hibája (szerintem) mert más hálózatokon megy. Mindez nem ideiglenes hiba, mert hónapokig atomstabilan nem megy. A szolgáltató elmagyarázza, hogy ilyen hiba nem létezik, téged hibáztat, és azokat a szolgáltatásokat, amiket nem tudsz elérni.

Ha szerinted ez normális, és nem ad okot morgolódásra, akkor oké :)
Ha szerinted a tudatlanságom az oka a fenti hibának, akkor kérlek részletezd :)

Egyébként úgy oldódott meg, hogy kértem az ipv6 kikapcsolását, itt a hupon volt téma, és ez vezetett rá. Előtte kipóbáltam mindent, alapbeállításokkal toltam (erről később), mtu állítgatás segített volna, de telefonon nem volt rá opció.

"Nem tudom, te mit értsz "alapbeállítás" és "teljes internet" alatt"

Alapbeállítás egyszerű, csak képzelj el egy átlagfelhasználót. Ő nem állítgatja a routert, nem turkál a hálózati beállításokban, beírja a wifi jelszót, és használja a netet.

Teljes internet alatt meg nyilván azt, amit ők ígérnek internetelérés alatt. Ha blokkolnak valamit biztonsági okokból, az oké. Nem hinném, hogy a fenti play store-os esetem ide tartozna.

Az MTU-t nem tekergeted, ha nem tudod, hogy pontosan mit csinálsz (a routeren a user/jelszó beállításon kívül szintén nem piszkál nagyon, ha nem tudod, mire való). Ez nagyjából olyan alapvetés, mint az eszkimóknál a "nem csinálunk teát az iglu mögötti sárga hóból".

Azért kellett az MTU-t csökkenteni, mert valahol telibe lett kakkantva a PMTU - ez úgy az esetek kilencvensok %-ában az üf.-oldali routerben szokott törtnénni. Úgyhogy valahol csak el lett tekergetve valami - mondom, egy sz@rul belőtt icmp-filter már agyon is vágja a dolgaid - az ipv6 esetén meg pláne - az Android meg ha kap ipv6-ot, akkor naná, hogy azt próbálja használni.

Ha az mtu nem jó, akkor ott vagy az OS-ben van valami el...va (nem tudja a pmtu-t rendesen kezelni), vagy a routerben (icmp-szűrés, pmtu-hoz alapból hülye, bár ekkor asztaldísz, illetve e-szemét a helyes elnevezése), de kézzel mtu-t állítani nagyon régóta nem kell, normális és normálisan beállított eszközök esetén.

Sajnos azt nem tudom megmondani, hogy volt-e szarul belőtt filter, vagy sem. Ha volt, akkor a szolgáltató routerében volt, amit gyári beállításokkal használtam. (se gépen, se telefonon nem volt semmi filter/tűzfal/semmi)

De nem is akarom megmondani, ez is csak azt bizonyítja amit mondani akartam: Az UPC messze nem stabil, és elég gányul kezelik az ügyfélpanaszokat, amik túlmutatnak a modem újraindításon.

Látom közben szerkesztettél: Nézd, nekem melóhoz kell hogy tudjak ssh-n kapcsolódni szerverekre. HA nem lövöm lejjebb a gépemen az MTU-t, akkor nem tudom elvégezni a feladatom. Mert a szolgátlató nulla megoldást adott. A tanácsot itt kaptam HUP-on, megoldotta a problémám. Tessék az illetőt megkérdőjelezni :)

Szerinted, ha a szolgáltatói oldalon lett volna pmtu elkuffva, akkor hány homárposzt és hasonló, habzószájú bejegyzés született volna erről netszerte...?
Ha Linuxot használsz, akkor azon van-e csomagszűrés beállítva? Netán ip_no_pmtu_disc sysctl paraméter állítva? Mert ahogy írtam, _vagy_ a routeren, _vagy_ a gépen volt valami elkeffintve... Az Android meg lehet, hogy ipv6-on akart pofázni, ami nem jött össze neki. Láttam már pár "érdekes" hibát, amiért mindenkit hibáztatott a delikvens, aztán kiderült, hogy a probléma a szék meg a billentyűzet között volt...

Eh... mindegy. Leírtam fent, hogy telefonon jelentkezett a probléma úgy is, hogy NEM volt linuxos gép, sőt semmilyen gép a hálózaton. Meséld már el, hogy ebben az esetben mit számít a linux, és mindenféle kernel paraméter? Meséld már el, hogy más hálózaton miért ment minden jól akkor is, amikor ott volt _ugyanaz_ a linuxos gép?

Meg akarod magyarázni, hogy én vagyok a hülye, de az jön le abból amit mondasz, hogy mindenkinek ismernie kellene az általad említett paramétereket és magának finomhangolni.

Tegyük fel átlagfelhasználó vagyok, akinek van egy szerencsétlen androidos telefonja, meg linuxos gépe: Átlagfelhasználóként miért is kell nekem az oprendszerem kernel paramétereivel foglalkozni, miért kell tudnom ezekről a dolgokról, amiket írtál, és miért én vagyok a hülye, ha használom a gyári beállításokkal az eszközeimet?

Ebben egyrészt igazad van, másrészt a hiba valamitől mégis csak létezik. Akkor is, ha a kedves felhasználó nem akar ezzel foglalkozni, csak cirkuszol, hogy „sz.r az egész”. Attól, hogy van egy boltban megvásárolt router default beállításokkal, az még lehet rosszul konfigurálva, ha úgy tetszik, nem kompatibilisen a szolgáltató hálózatával.

Szerintem, ha valaki problémát szeretne megoldani, jobb a kooperatív hozzáállás. Derítsük ki - a szolgáltató és a felhasználó közösen -, hogy mi okozhatja, s ténylegesen mi okozza a hibát, a lehető legtöbb releváns információt osszunk meg egymással, s találjuk ki a megoldást.

Persze az is egy megoldás, hogy harsogjuk a telefonba, hogy működjön ez a sz.r, ezért fizetek, nem érdekel hogyan, de jó legyen iziben. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"csak cirkuszol, hogy „sz.r az egész”."
"harsogjuk a telefonba, hogy működjön ez a sz.r"

Biztos nekem akartad ezt írni? Mert nagyon úgy tűnik, mint ha azt mondanád, hogy én tettem így, holott...

Csak hogy tisztázzam: Egy tavalyi esetről van szó, ami már rég lezárult. A hibajelenséget legjobb tudásom szerint próbáltam kinyomozni/utánajárni, volt is eredménye, hiszen ez vezetett a megoldásra végül. Eközben többször beszéltem az ügyfélszolgálattal, akik nem tudtak segíteni. A kiakadásom oka az volt, hogy hülyének néztek, és egy nyilvánvaló hazugsággal hárítottak. Ennyit a kooperációról, egyébként tök egyetértek ezzel a kijelentéseddel:

"Szerintem, ha valaki problémát szeretne megoldani, jobb a kooperatív hozzáállás. Derítsük ki - a szolgáltató és a felhasználó közösen -, hogy mi okozhatja"

Ennyi a sztori :)

Ilyen esetem nekem is volt. A UPC hibája egyértelmű volt. Ennek ellenére hiába bújtam az ÁSZF-et, ebben a kérdésben (email) nem lehetett fogást sem találni rajtuk. A megoldás az lett, hogy attól kezdve az UPC-s címről kimenő leveleimet egy ismerős cég szerverén keresztül küldtem.

Az internet szolgáltatás az más. Pontosabban van leírva, viszont egyáltalán nem mindegy ki van a telefon másik végén. Erre sajnos csak olyan megoldás van, hogy még egyszer próbálkozol, hátha sikerül megfelelően kooperálni. Ez szomorú, időt és türelmet nem kímélő. Ennek ellenére optimista vagyok, mert az utóbbi időben szaporodtak az értelmesebb ügyfélszolgálatosok.

A routeren az IPv6 rendben volt? Igen? Biztos vagy benne? Az alap az, hogy a pmtu-t valami telibef0sta. Hogy mi, azt most így nem fogjuk kideríteni, de esélyes, hogy nem a szolgáltatói oldal, mert ott template alapon n+1 üf. kapja ugyanazt a konfigot, egyedi üf.-re vonatkozó beállítások testreszabása után.

Te egy olyan paramétert kezdtél el tekergetni "hogy működjöbn a pécén", amit per definitem _nem_ kell kézzel módosítani. Ha ez tünetileg segít, akkor a pmtu hiányának az okát kell megkeresni. Akár úgy is, hogy a szolgáltatónál jelzed a problémát. Ha kell többször, egészen addig, amíg meg nem oldódik a probléma.
Gondolom, van n+1 hibajegyed a szolgáltatónál ezzel a problémával kapcsolatban - ha nem, akkor bocs, de te vagy a hunyó, hiszen csak puffogsz, de a hiba _okának_ a megkeresésére nagyívben tojsz.

"hiszen csak puffogsz"
"a hiba _okának_ a megkeresésére nagyívben tojsz"

Ha valami miatt puffogok akkor az ilyen hozzászólások. Mégis mi alapján teszel ilyen feltételezéseket? Nem akartam eleve részletesen leírni az esetet, csupán azt, hogy történt egy ilyen, és ahogy kezelte az üf az esetet, az nem volt túl bizalomgerjesztő. Nem is fogom bizonygatni, hogy minek jártam utána, és minek nem. Azt hiszem ismereteimhez és időmhöz mérten becsületesen utánajártam annak, aminek lehetett, és az ügyfélszolgálatot is zargattam eleget. Ha nem hiszed, ez van :)

Nem az volt a célom hogy elmeséljem részletesen a sztorit,az ügyfélszolgálat hozzáállására akartam kiegyezni a hangsúlyt. Na mindegy, nem jött össze :)

Amúgy lehet, hogy nem szabadott volna piszkálnom az MTU-t, de ez az ügyfélszolgálattal szemben ténylegesen segített, ami elég fontos, ha következő nap melóhoz kell tudnod ssh-zni. (ami szintén nem ment amíg nem "bactattam" az értéket. Tehát volt egy problémám, és megoldottam. Rosszul? Lehet. Segített. Igen. Mit kellett volna tennem? (tényleg érdekel, ha van jobb megoldás)

Egyébként az ötlet innen (szerk, mégse innen, de rémlik, hogy hasonló beszélgetés volt, ott is említve voltak ezek): (lásd linkelt komment, és rá adott 1-2 válasz):
https://hup.hu/node/143970?comments_per_page=9999#comment-2043692

Ugyanezen oknál fogva kértem később, hogy kapcsolják ki az ipv6-ot teljesen, ami megoldotta a problémát azokon az eszközökön is, ahol nem tudtam MTU-t állítani. Azóta visszaállítottam automatikusra, és minden szép.

Ahol ay IPv6 kikapcsolása oldotta meg a problémát, ott nagy az esélye annak, hogy az eszközök IPv6-on akartak kommunikálni, és az nem ment. Az MTU-t nem véletlenül nem lehet piszkálni újabb motyókon - egyszerüen nincs rá szükség. A linkelt kommentekben is az elsődleges kérdés, hogy megy-e a pmtu, úgyhogy egyről beszélünk - te úgy oldottad meg, hogy kézzel beállítottad (ahol még lehet), miközben az eredeti ok nem szűnt meg.

Én azért tennék egy próbát ismét az IPv6-tal - az otthoni szolgáltatásban a publikus ipv4-et egyre több szolgáltató kezdi kivezetni - célszerű a problémáknak elejét venni...

A publikus ipv4-re szükségem van, el akarom tudni érni a hálózatomat máshonnan.

Két dolgot írtál. Az egyik, hogy "az eszközök IPv6-on akartak kommunikálni, és az nem ment". Hát ez az! Miért nem ment? Ráfoghatjuk, hogy az Ubuntu gyárilag rosszul kezelte a helyzetet (nem szokásom a hálózati beállításokban piszkálni), de az androidos telefon, amire nincs ráhatásom, és a saját routerük, amit nem piszkáltam miért nem tudta megoldani a dolgot?

Nem kellett volna tudnia az ügyfélszolgálatnak ebben segíteni? Én nem akadályoztam őket, pontosan és részletesen elmeséltem a hibajelenséget, amire a következő dolgokat kaptam: 1) Kioktatás, miszerint olyan hiba, hogy az internet részlegesen nem érhető el, nem lehetséges. 2) Szokásos indítsuk újra, táv-varázslás, szaki kijön, jelerősséget mér, routert cserél. 3) Nem tudunk segíteni, biztos az oldallal van baj amit el akarok érni.

"MTU-t nem véletlenül nem lehet piszkálni újabb motyókon - egyszerüen nincs rá szükség"

De látod, hogy volt rá szükség. Mi lett volna az alternatív megoldás? Ügyfélszolgálat? Látod hogy nem tudtak segíteni. Használjak vindózt, mert a linux a szar? Az hogy segít az androidos kütyüimen?

Hogy miért nemment az IPv6-os kommunikáció, azt ki lehet(ett volna) deríteni, ott is vannak nagyon jó eszközök a tesztelésre. Igen, Androidon is. Ha csak a szolgáltató eszköze volt az útvonalban, akkor ott kell keresni a hiba okát, és őket kell addig hibabejelentésekkel piszkálni,a míg meg nem oldják a dolgot.
Az indítsd újra nagyon sokszor tud segíteni - ha hiszed, ha nem. Egyrészt azért, mert reboot során újra magára húzza az eszköz a beállításokat, másrészt meg láttunk már karón varjút... Saját sztori: Openvrt, TP-Link router, PPPoE-s szolgáltatás. Logban az látszik, hogy a pppd küldi a kérést, de nem kap választ. Az Ethernet interfészen link van, tcpdump-ban látok forgalmat - a bejövő választ ott sem.
Üfsz. szerint is rendben van a switchport, rendben van a hozzáférés, látja hogy pontosn mikor volt legutóbb auth, azóta nem lát forgalmat az eszközöm felől. TP-Link doboz reboot, és nézzenek oda, prompt felépül a PPPoE...

Az MTU kézi piszkálására csak akkor van szükség, ha valahol elakad a pmtu, ha a fragmentation-re vonatkozó icmp-t valaki nem küldi/nem fogadja. De ilyet értelmes eszköz már nem csinál, ha valaki explicit nem szűri ezt, akkor működni fog a dolog.

Az Android-od milyen verzió, milyen hálózati védelemmel? Mert simán elképzelhető, hogy ott volt az eb elhantolva...

Ja, nekem is volt olyan, hogy az internet-szolgáltatásom lehalt, miközben hét végén távolról dolgoznom kellett volna. Mivel a hét végi munka/készenlét rendszeres (volt), így számomra természetes, hogy egy 3G modem a bele való mobilnettel ott van a gépem mellett, tartalék útvonalként.

"ott kell keresni a hiba okát"

Megtehettem volna, átlaguser nem teszi meg -> upc nem jó célcsoportnak szolgáltat ha az user feladata a debug

"őket kell addig hibabejelentésekkel piszkálni"

Vagy 10-15 hívás, a felénél csak magamat ismételtem, eközben pár hónap eltelt, nulla megoldás. -> upc üf gáz.

"Az indítsd újra nagyon sokszor tud segíteni"

Elhiszem, teszem néhány naponta, mert kell. Hidd el, ezeket a teszteket lövöm el elsőként. Persze az is bosszantó, ha nem képes pár napos uptime-nál többre az a hülye router amit adnak. (tudom, vegyek sajátot, de akkor meg én leszek a hibás, mert biztosasajáteszközarossz)

"Az Android-od milyen verzió, milyen hálózati védelemmel?"

Nexus 5X gyári rommal (Android 6, majd 7) piszkálás nélkül. Azt nem tudom milyen védelem van beépítve, ui-ra kivezetve semmi.
Nexus Player, ugyanez

"számomra természetes, hogy egy 3G modem a bele való mobilnettel"

Felkészültség itt is van, mobilról tudom adni a netet usb-n. De azért mégis csak célszerűbb, ha nem mobilneten mozgatok gigákat, és nem a saját előfizum fogyasztom.

10-15 hívás és pár hónap...? Gondolom pár napot akartál írni, mert ha nagyon nem megy, akkor ez max. néhány nap termése kell, hogy legyen. Ha annyira okos vagy, szerintem a saját eszközön hamarabb megtalálod a hiba okát, mint a hülye üf.szolg. és a mögöttük lévő technikusi csapat a saját motyójukon...
Mindegy, ilyen szopkovácsolás-hegyeket az UPC-IPv6-PMTU témában nem sokat hallottam/láttam, de legalább most már elmondhatom, hogy igen :-)

Próbálj meg kicsit árnyaltabban fogalmazni!
Akinek hiányzanak a karjai és lábai is, azt nem feltétlenül kell a szemüvegesekkel egy kategóriába sorolni, hogy nyomorék! A szolgáltató dns szerverétől eltérő dns szolgáltatás használata bevett szokás.

A "ne használd a dnsüket" enyhe túlzás. Mivel használom az IS. Évente néhányszor benchmarkolom a releváns és egyéb free forrásból származó dns szervereket. A leggyorsabbakat(és nem ferőzhetőket) + google berakom a listába. A router hozzácsapja a dhcp-ből származókat is, és az összes dns szerver párhuzamosan kérdezi le. Ezzel kicsit jobb a sebesség.

Ennek a dns trükknek annyi az előnye, hogy a hőbölgő felhasználó számára az ÁSZF-ben megadott rendelkezésre állás biztosított, míg nekem meg 100% és gyorsabb. Legalábbis dns szempontjából.

minél árnyaltabban?

Őszintén, ha valaki internetet szolgáltat, és olyan a dns-e, hogy átviszi az ingeküszöböt, hogy inkább ad az ember plusz dnst, az bizony szar.

(ha meg azzal kell játszani, hogy párhuzamosítsuk a dns lekérdezéseket egy mai internet elérésen, mert érezhető, akkor még a sávszél vagy a latency is szar)

Mint előfizető teljesen igazad van.
Az internet meg elég kaotikus rendszer. A lassulás nem csak a melletted levő szerveről füg, hanem esetleg másik száztól. Ezt elkerülni csak közvetlen kapcsolattal lehetne.
Ha lehetőséged van, akkor inkább érdemes tenni azért valamit, hogy jobban érezd magad! A dns szerver válaszideje is rengeteg dologtól függhet. Nem vagyok nagy hálózati spiller, de a dns forwarder - ha nem kérd másképp - bizony párhuzamosan kérdezget. Ez csak előny, mert ha az egyik dns szerver véletlenül lassab lenne annál az egy kérdésnél, akkor is előbb kapod meg a választ. Szerintem nincsen ebben semmi hiba.

Ne haragudj, de egy szolgáltatót nem nagyon lehet másképp nézni, mint előfizetői szemmel.

Én sem vagyok nagy hálózati spíler (mert mindig vannak okosabbak, de azért mondjuk, hogy konyítok hozzá "valamicskét"), de az, hogy te vagy én adott esetben körbe tudjuk kacsázni a szolgáltató hülyeségeit, attól még amit a szolgáltató ad, az szar marad.

Egy internet szolgáltatásnak alapvető funkciója, hogy a névfeloldás megbízhatóan működjön. Ez azt jelenti, hogy
1) az előfizető mindig eléri a szolgáltató dns szerverét (nyilván, mikor éppen legalább layer 3 van az üfnél. de ugye ha nincs, az megint csak a szolgáltató)
2) a szolgáltató dns szervere képes feloldani azokat a címeket az interneten, amiket egyébként fel lehet. (Vagyis ha a szolgáltató nem tudja feloldani, a példa kedvéért a google dns szervere meg igen, akkor a szolgáltató dnse szar)
3) A szolgáltató dnse normális sebességgel működik, nincs benne extra latency, és feloldja a hozzá érkező kéréseket.

Ha ezek mennek, akkor sem azért nem kell konfigolni másik dnst, mert van amit nem old fel, sem azért, hogy gyorsabb legyen a feloldás. Ugyanis bár a lassulás nem csak a melletted levő szervertől függ, az tény és való, de speciel dns esetén max attól, hogy az autoratív dns messze van, és lassú. Az meg másnak is így lesz. Namost, ha a szolgáltató linkjén mást kérdezve nem lassú, akkor valamit megint csak a szolgáltató bökött el. (Azt a forwardert meg mutasd már meg nekem, ami ugyanazt a queryt párhuzamosan tolja felfele több helyre, mert elég elbaszott egy szerkezet lehet. Azt a részét meg hagyjuk is, hogy valami nagy közös megegyezés miatt bizonyára minden dns forwarder default konfigja egyforma)

TL;DR hiba az ugyan nincs benne (nagy), csak ettől még a szolgáltatás szar marad.

Nem haragszom ;), csak félreérted az egészban az előfizetői szem szerepét. :)

Ha már előfizető vagy, akkor a sok okoskodás előtt ugorjál neki az ÁSZF-nek. Ha az ott leírtak teljesülnek, akkor a többi az a hőbölgés kategóriájába esik. Ezt hiába szeded potokba, akkor is csak hőbölgés marad.

Tapasztalatból tudom, hogy az UPC-hez képest vannak rosszabb szolgáltatók. Ugyanakkor az UPC a szerződésnek megfelelően szolgáltat. Az elmúlt 15 évben most (pár hónapja) fordult elő először, hogy túllépték a javítási időt 12 órával. Ez azért nem írja felül a 15 éves tapasztalatot és meríti ki a "szar szolgáltatás" fogalmát.
Mindössze ahhoz próbáltam néhány tanácsot adni, hogy a vállalási feltételekhez képest biztosíthatsz magadnak nagyobb rendelkezésre állást, ha csak a dns zakkan meg.

Sajnos van néhány olyan dolog, ami hiányzik az ÁSZF-ből. A hőbölgés ezen sem segít. Viszont az NMHH (és összes névrokona :)) számára be lehet adni kifogásokat. Nem túl rosz a helyzet, mert a lényeges dolgokat előbb-utóbb szabályozni fogják.

"Mindössze ahhoz próbáltam néhány tanácsot adni, hogy a vállalási feltételekhez képest biztosíthatsz magadnak nagyobb rendelkezésre állást, ha csak a dns zakkan meg."

Ez igazán kedves tőled, csak miért? :) Egyrészt nem vagyok upc előfizető, másrészt remekül meg tudom az ilyen jellegű gondomat oldani magam is, ha kell. Az ÁSZFet meg értem én, nem szeretnék most erről sokat regélni, maradjunk annyiban, hogy vállalás ide, vállalás oda, ha lényeges műszaki tartalommal ingerküszöböt átlépő mennyiségben gond van, az (figyelj, fontos) __szerintem__ bizony szar. Volt már pár szolgáltatóm, még senki miatt nem kezdtem el külső dnst hegeszteni.

Egyébként meg (figyelj, megint csak) szerintem az a -- hipotetikus -- lakossági szolgáltató, aki rendszeresen épphogy csak tudja hozni az ÁSZFben meghatározott szintet (ami ugye tipikusan azt jelenti, hogy havonta 2-3 napig vagy net nélkül) az lehet, hogy jogilag rendben van, de ettől még egy trágyafos szolgáltató.

Az meg, hogy az ÁSZFben benne van-e a DNS explicite nevesítve vagy nincs, az bizony olyan szempontból irreleváns, hogy nincs szerintem ma magyarországon éppeszű bíró, aki azt mondaná, hogy az ott nem szolgáltatás kiesés volt. Szerintem szolgáltató se nagyon, aki megpróbálná ezt vitatni, ha a szokásos körök megvoltak (jelentetted a hibát, nem sikerült időn belül megcsinálni). (mondjuk itt már vannak kétségeim, lehet, hogy van olyan hülye manager, aki megpróbálná a nagy tétel miatt bizonygatni, hogy ők biza szolgáltattak)

Az ingerküszöb nem egzakt műszaki fogalom. Nálam < 10 perc. ;)
Az ÁSZF vállalása 98% - az meg < 8 nap.
Az éjszakai karbantartásokat is számítva az összes kiesés << 2 nap. Ezek az éjszkai karbantartások többnyire hálózatbővítést jelentenek, tehát nem tipikusak. Én legalábbis megszoktam az 1-2 év alatt 0 kiesést.
Nyilvánvalóan a havi 2-3 nap az 24-32 nap kiesést jelentene, ami durva és kötbérezhető. Ha a kiesés időtartama > 48 óra -> kötbér. Ha ilyen hibák többen vannak mint 4, az is kötbér. Az ilyet egyik szolgáltató sem kockáztatja. (Na, van kivétel, de az nem a UPC.)

Természetesen a rendelkezésre állás megítélésénél legyek átlagos felhasználó. Tehát nem tudom mi van, csak "nincs net". Akkor is ez látszik, ha elvágták a drótot, meg akkor is, ha csak nincs dns - ehhez még bíró sem kell.

Távol álljon tőlem, hogy bárkire bármit ráerőltessek. Bár úgy látszik, kár volt a UPC-t dícsérgetni, mert éppen 6 óra 10 perckor leállt a net. Én meg itt ülök ugyanúgy a gép előtt és írom ezt a kommentet, mert a tűzfal váltott a tartalék kapcsolatra. :)

És ha már lúd, legyen kövér, én futtatok egy dnsmasq-ot is a desktop-on caching nameserver gyanánt, így engem első kézből a 127.0.0.1 szolgál ki. Jó, nyilván ő sem az ujjából szopja a feloldást, de ha egyszer megvan, legközelebb RAM-ból jön, ami meg gyors.

Igaz, ha van egy router, lokális hálózaton szintén gyors a kiszolgálás.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én Fedorán futtatok egy dnsmasq-ot, de nem okoz semmilyen fájdalmat.

dig hup.hu

; <<>> DiG 9.10.4-P6-RedHat-9.10.4-4.P6.fc25 <<>> hup.hu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62824
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hup.hu.                                IN      A

;; ANSWER SECTION:
hup.hu.                 148     IN      A       185.43.206.113

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Feb 26 22:32:38 CET 2017
;; MSG SIZE  rcvd: 51

Az a 0 ms-os válaszidő elég vonzó.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Bár lehet, hogy vonzó, de in practice szerintem sokat nem jelent. Tipikusan nem szokott ezzel gond lenni, hacsak nem szar ugye az upstream dns. Főleg úgy, hogy az ilyen szempontból legvalószínűbb nyertes, a browser szinte mind maga is cachel.

A dnsmasqal az a problémám, hogy pl ahogy az ubuntu csinálja, egyből elbaszódik a mivan hol egy sima kézzel felhúzott dhcp mellet, ami átírja a resolv confot, hacsak nem patchelték meg ugye a dhcp klienst is, hogy helyette inkább a dnsmasqnak szóljon, hogy változott a forwarder. Ha csak dns cachet akarok, akkor nscd, sokkal egyszerűbb, és rendesen a helyén van.

Szóval ha neked jó, használd, nem para, de ezt így defaultnak betenni csak egy réteg fölösleges absztakció.

Egyébként ha az aláírásodban szereplő opensuseről van szó, anno még 11.valami idején elkezdte azt a zypper, hogy telepítette letöltés közben a csomagokat. Letöltött egyet, felrakta. Letöltött, felrakta. Nem tudom most hogy van. Ez okozott nálam is anno felakadásokat, ugyanis volt, hogy letöltés közben tűnt el egy package egy mirrorról (gondolom épp akkor futott az rsync), és a nem sokkal korábban felrakott lib már nem volt jó a programnak, vagy egyszerűn megállt, hogy foo-3.1.1-112 not found, mert azóta lett helyette foo-3.1.1-113, vagy foo-3.1.2-001. És akkor lettek szép törött függőségek, meg félbemaradt frissítések. Meg tudnám forgatni a tőrt abban, aki ezt kitalálta... Van valami opció, hogy előbb töltsön le mindent, majd dependency check, és aztán install. Valamint van ott is downloadonly kapcsoló.
--
"Sose a gép a hülye."

Nem az aláírásomban szereplő verzió, és nem is jelen gép volt a szenvedő alany.

Alapban letölt, majd ha minden csomag megvan, akkor telepít. Az ellenőrizgetés és kérdezgetés kikapcsolható. Én ezt tettem, mert másik gépen dolgoztam közben 2 szinttel arrébb.

--
openSUSE 42.1 x86_64

( uid_4263 v | 2017. 02. 22., sze – 12:54 )

Az apt szerintem egész biztos nem kezdi el telepiteni a csomagokat ha még nem végzett a letöltéssel, valamit elrontottál.

--
arch,debian,retropie,osmc,android,windows

( igiboy | 2017. 02. 22., sze – 13:05 )

dnf, leánykori nevén yum is olyan emlékeim szerint, hogy előbb letölt és ellenőriz, majd utána telepít ott sem betűrendben, hanem valamiféle függőségi sorrendben.
Általános hiba ilyen frissítésekkor, a netről összevadászott parancs egy benne lévő -y (forced always yes) kapcsolóval.
Van hogy menet közben is kérdez, hogy valami gikszer van és akarod-e valóban tovább csinálni. Nem biztos hogy célszerű ezt eldönteni még a parancs kiadásakor.

ignoráltattam vele a függőségi hibákat is

És ezt így mégis hogy? Mi értelme van? Én megvárom a hibaüzenetet, s abból kitalálom, ha esetleg egy több disztribúcióval ezelőttről ott maradt egy csomag, s az okoz gondot. Eltávolítom, majd újra függőségek kezelésével próbálok upgrade-elni. Nem tölti le újra, ami már megvan. Így biztosan jó lesz, de szerintem nem bölcs a függőségek kezelését kikapcsolni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Mi értelme van?"
Mert volt még más dolgom is, és mivel eddig soha nem volt ebből semmi gond, így sajnos a megszokott ellenőrzés is kimaradt.

Igen, amit "nyertem" vele, hogy nem kellett mellette ülni, elvesztettem a rinyálással és a helyreállítással.

--
openSUSE 42.1 x86_64

"Nem vak az, hanem vakmerő!"
Ezek a mai fiatalok... =) Bezzeg a mi időnkben még elég volt, ha a másodikon Gipsz Jakab túlságosan kinyújtotta a lábát, s leállt az egész épületszárny hálózata. Arról ne is beszéljünk, micsoda csomagveszteségi arányok voltak, amikor a szomszédos épület óriási üvegfelületeit kialakították.
Nincs az a netkapcsolat, amiben ennyire megbíznék, még egy pótolható játszós virtuális gépen sem.

_______Peter
I am a stone. I do not move.

Bár nem tőlem kérdezted, de válaszolok és kérdezek is.

Szerintem jó az UPC, de helyi - pát házat érintő, gyakori hálózatkimaradás miatt van failoverem. Egész véletlenül megtudtam a hiba okát, és meg kellet lépni.

Hidd el, elég alaposan ismerem az ÁSZF-et! Jönnek a (költői) vizsgakérdések! ;)
1. A UPC n db email címet biztosít. Garantálje-e, hogy ezek működnek?
2. A le- és feltöltési sebesség általában a maximum közelében mozog. Pl. a speedtest.net meg is méri szépen, de hibásan. Ugyanakkor előfordult, hogy az RTT 700...1000ms volt hónapokon keresztül. Mit tudok erre lépni?
(jelenleg 6,3..6,9ms, de régebben <2ms volt)
3. A rendelkezésre állás (tán vállalt érték, törvény, kutyafüle, stb.) legyen 98%, ami évi 8 nap kiesést jelent. Ebből vonjuk le a tervezett karbantartást! A maradék kiesés jelentheti-e azt, hogy minden 120 percben 3 percig nincs kapcsolat? Ha nem, akkor ez hol van leírva?

A rendelkezésre állásról nyugodtan kijelenthető, hogy jóhiszemű elbírálás szerint "gondolták". ;)

"Mekkora az általad használt/vásárolt szolgáltatás garantált rendelkezésre állása?"
Több van ígérve, mint betartva. Az ilyen jellegű megkeresésemre pedig leráznak azzal, hogy biztosan a modem mögé kötött routerem a szar. Nyilván csak az lehet a szar, mikor látom a modemen, hogy a kábelen nincs jel. De hát akkor indítsam újra. Hiába volt meg előtte 5 ezerszer, akkor is, indítsam újra. Minő meglepetés utána is szar. De hát a router nélkül a gépbe van dugva a kábel?... IGEN, baszod!... Tele van ezzel már az összes faszom már. Legutóbb odáig jutottunk, hogy azért nem megy, mert nem windows van a gépemen, és itt megköszöntem az együtt nem működést, és inkább vettem még egy mobilsticket.

--
openSUSE 42.1 x86_64

Több van ígérve, mint betartva.
Pedig LeninElvtárs megmondta: Olvasni hatalom!
Ha igazad lenne, akkor a helyedben már szarrá kötbéreztem volna őket.

A kábelmodemet központilag diagnosztizálják, illetve a kapcsolatot is folyamatosan mérik. A modem újraindítását általában nem szokták kérni, mert rá tudnak nézni. Eleve egy hibaelhárítás így kezdödik:
én: Nincs internet, a modemet újraindítottam, nincs jel.
upc: Azért először ránézek a modemre.
én: Nem fog.
upc:(kuncogás)
:)
A modemet eléred a 192.168.100.1 címen.
A hörcsögösködés helyett érdemes a saját LAN körében elvégezni a hálózatdiagnosztikát, és utána a szakszerű hibabejelentést megtenni.
Ezek után indul a 48 óra. Hidd el, nem érdekük az állandó hibabejelentések fogadása, tehát megjavítják.

A modemet semmilyen címen nem lehet elérni, mert semmi IP-t nem kap. A külső IP-t a rácsatlakoztatott eszköz kapja. Nyilván ezért kell nekem kapcsolgatni állandóan. és hiába kezdem azzal, hogy már újraindítottam, nincs jel.
Ha meg véletlen ki is jön a Zember, akkor az egy r=1 júzert megszégyenítő sötétséggel kérdezi meg a cisco cuccokkal teli rackről, hogy "ez mi? hol a róóter?" Szóval ezzel sem vagyok kisegítve.

A szarrá kötbérezés... Általában a késve érkező számlán rajta van, hogy x ezer ft-ot elengedtek a szolgáltatás árából és milyen kurvára sajnálják.

--
openSUSE 42.1 x86_64

Ha valaki szervert akar üzemeltetni ("cisco cuccokkal teli rackről,"), akkor nem üzleti szerződést kellene kötni?

Ha szimpla lakossági net hozzáférést vásárolsz ilyen célra akkor miért csodálkozol?
Ráadásul, ha valóban ilyen rack van otthon, akkor először az otthoni hálózatot kellene tesztelned... Nem a szolgáltatót fikázni, miközben nem a szerződésnek megfelelő módon használod a hozzáférést.

Következő mi lesz? A hálózat miatt bepereled őket, mert bevétel kiesést okoztak?
Bizosan megértők lesznek, mikor kiderül hogy bitcoin-t bányászol/felhőszolgáltatást árulsz/webkiszolgálót üzemeltetsz sima mezei felhasználói szerződéssel.

Egy router van a netre kötve, ami intézi a net elosztást. Mellett (alatta) meg néhány másik, switchekkel együtt, játszani. Egybe van pakolva, mert faszé' legyen külön?... Ettől még nem felhőszolgáltatást árulok home neten. A szerver üzletin megy és nem lakásból... :D

Mondjuk, van szerver is, de nem a rackben, és nem is public hálón van.

--
openSUSE 42.1 x86_64

Akkor ez egy adsl modem? Mert a kábelmodemeknek - akár bridge, router, vagy router bridge módba kapcsolva - mindig van menedzsment címe. Azt nem kapja sehonnan, csak a gyártól. ;) Ha bridge, akkor meg sehonnan nem kap címet, de attól még a menedzsment cím működik.
A szerelőt meg illik kisegíteni. Ezt a mutatóujjammal szoktam megtenni: Ide dughatod a drótot.
A számla nem érkezik késve. A UPC kb. 10-én zárja a számlázási időszakot, majd (valószínűleg) külső szolgáltató nyomja és borítékolja a számlát. Nekik olyanjuk van, hogy 20-a után kapod meg, de minimum december 23-án van a befizetési határidő. :)

Kábelmodem, az 192.168.100.1-es címen csak fehérség jön be, ha bejön valami. és pingre sem válaszol ez a cím.

"A szerelőt meg illik kisegíteni. Ezt a mutatóujjammal szoktam megtenni: Ide dughatod a drótot."
Ki lett segítve, de a kérdés: "hol van a róóter"... Nem mertem rábízni.

"A számla nem érkezik késve. A UPC kb. 10-én zárja a számlázási időszakot, majd (valószínűleg) külső szolgáltató nyomja és borítékolja a számlát. Nekik olyanjuk van, hogy 20-a után kapod meg, de minimum december 23-án van a befizetési határidő. :)"
Ide késve jön. Többi számlát meg nem ide szoktam kapni.

--
openSUSE 42.1 x86_64

Most kipróbáltam.. Újraindulás után valóban betölt az oldal, de semmilyen felhasználónév-jelszó kombóval nem enged be, pár perc múlva ismét fehér oldal, majd később "This site can’t be reached" jön belőle.
Kezdek arra gyanakodni, hogy szar a modem. Viszont most még elfogadható, 100-ból 99 csomag visszatér...

--
openSUSE 42.1 x86_64

Ha jól emléxem (dehogy:)
- vagy alap jelszó
- vagy rá van ragasztva
A régi bridge típusúnál (EPC3212) boot előtt látszik az összes menüpont és a kábelmodem logja. A kapcsolatfelvétel után csak a főmenü, de ezen látod az összes up/down streamet.

Ha van wifi, akkor a Wi-Free menedzseléshez nem, de a routerbe be tudsz lépni. És átkapcsolni bridge módba. ;)

sem "admin-admin" sem a ráragasztott matricás jelszóval nem lehet belépni. :)

Ez amúgy egy EPC3925 bridge módban. Tudom ez nem "csak" modem, de mivel bridge módban van, ezért gyakorlatilag modem.
Viszont megint 50% a packet loss külső címet pingelve 100-asával pingelve, a modem felülete továbbra is elérhetetlen. Így gyanítom továbbra is szar...

--
openSUSE 42.1 x86_64

( locsemege v | 2017. 02. 22., sze – 13:29 )

Ez Fedorán úgy van, hogy előbb letöltjük a csomagokat, utána ellenőrizzük a konzisztenciát, függőségek, minden csomag rendben, majd reboot után egy systemd service offline telepít, aztán megint reboot, s kész. Így távolról, ssh-n is csináltam system upgrade-et.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Letöltöd egy paranccsal az upgrade anyagát. Ez egy sima letöltés, ekkor még használhatod közben a gépet bármire. A végén ellenőrzi a csomagokat, függőségeket.

Utána egy speciális paranccsal kell reboot-olni. Azért így, mert ez élesíti azt a systemd service-t, amelyik az upgrade-et csinálja. Ilyenkor a gép magába fordul, nem interaktív, nem kérdez semmit, csak felfrissít néhány ezer csomagot. Ez értelemszerűen még a régi kernellel fut. Amikor elkészült, akkor ez a service megint, tehát másodjára reboot-ol, ezzel már mindenben az új oprendszer indul az új kernellel.

Ezek közül az első reboot lenne megspórolható, de vélhetően azért csinálták így, hogy ne használják a gépet akkor, amikor minden csomag lecserélésre kerül. Tehát a tényleges frissítés alatt teljesen magába fordul a gép.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Erre tökéletesen alkalmas, erre való. Nem a csomagkezelőt integrálták a systemd-be, nyugi, csak egy systemd unit indítja a csomagkezelőt. Azért az nagyon nem ugyanaz, mint amikor a systemdbe van integrálva már szinte minden. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem nem, ez jól van kitalálva. Ha ugyanis használhatod a gépet frissítés közben, s valahogyan sikerül megborítani, akkor minimális előnyért cserőbe kaptál egy gyakorlatilag helyrehozhatatlanul szétesett oprendszert, amelyben egyes csomagok régiek, mások újak, a csomagkezelő adatbázisa pedig inkonzisztens, a disk cache intenzíven használva volt, nem kizárt, hogy valamelyest a swap is, így jókora adatvesztést is elszenvedtél. És akkor hogyan tovább?

Mindezt miért? Azért, hogy fail videókat nézhess sysupgrade közben a YouTube-on, meg LibreOffice Calc-ban táblázatot szerkessz. Elhiszem, hogy ez nagyszerű szolgáltatás, csak nincs arányban a kockázatokkal.

Most release-ek közötti system upgrade-ről beszélünk, nem egy release-en belüli néhány 10 csomag frissítéséről. Ezen felül ahogy írtam, letöltés közben még használhatod a gépet, akkor nincs módosítás még az oprendszeren.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyszer futottam bele olyanba, hogy ssh-n keresztül frissítettem és elkövettem azt a hibát, hogy a yum-ot nem screenben futtattam. Megszakadt a kapcsolat, így félbeszakadt a frissítés. Gondoltam nem gond, hát úgyis tranzakciók vannak, majd jól visszavonom. De sajnos azt se engedte, hogy a history undo-t lefuttassam, ezért elég sok szenvedés volt, mire megint konzisztens állapotba hoztam a rendszerem.

Értem, de pont az a lényeg, hogy a system upgrade nem így működik. Elkülönítik a letöltés és a tényleges frissítés fázisát, s a tényleges frissítéskor nincs semmilyen interaktivitás, így ssh sem. Még a gép mellett billentyűzet sem. Ennek az az ára, hogy nem egy, hanem két reboot tartozik a release-ek közti frissítéshez. Ó, minő borzalom! :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezzel én is szívtam, de lehet, hogy RTFM, nem tudom, mert sohasem néztem meg, mi a hivatalos eljárás ilyenkor. Ha jól sejtem, azt csináltam, hogy a history-ból kinéztem, mit kezdett meg egyáltalán, utána rpm paranccsal listát kértem ezekre szűrve a sort parancson át pipe-olva, aztán ami duplikálva volt (régi is új), abból leszedtem az újat, s ezt követően megint frissítés. A ciki akkor van, ha függőség miatt már nem lehet leszedni az újat. Erre is ki lehet találni, mi legyen, de szívás némileg.

Lehet, hogy van hivatalosan támogatott eljárás. Ráadásul ilyenbe régen futottam bele, s a dnf is fejlődik, szóval nem kizárt, hogy csak egy ügyesen paraméterezett parancs a megoldás. Például:

dnf --allowerasing distro-sync

Akár. Vagy ki tudja.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Semmi interaktivitás nincs. Működik. Ugyanakkor tudom, ez egy mélységesen szakmaiatlan válasz, írom tehát, mi történik.

Amennyiben egy konfigfile-hoz nem nyúltak, tehát a default, az cserélődik az újra. Általában készül a régiről egy *.rpmsave állomány. Ha hozzányúltak, akkor jellemzően marad a file, de az új default egy *.rpmnew formában mellé kerül. Persze lehetnek egyedi esetek, mint például a grub.conf, amit szerkeszt. Átveszi a jelenlegi kernel paramétereit, megírja az új bejegyzést úgy, hogy hozzáfűzi a paramétereket.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

És mit csinál a testreszabott konfigokkal? Egy dist-upgrade során változhat a formátumuk is, lehet, hogy bizonyos paramétert el kell hagyni, másokat másképp kell hívni, másképp értelmezni... Azért az a választási lehetőség hogy a saját/acsomag összerakójának a verziója/mutass diff-et, és eldöntöm jó dolog.

Ebből eddig sohasem volt gond. Mondom, vagy *.rpmsave, vagy *.rpmnew van, ahol számodra kritikus, tudsz majd diffet csinálni, manuálisan vagy sed-del merge-elni. Ami viszont nagyon jó, hogy nem a frissítés közben kell kötelezően meghoznod felelős döntéseket, hanem ráérsz ezzel akkor foglalkozni, ha már megy az új oprendszer, meg amikor időd van, meg amikor már van böngésződ, a helyes döntéshez túrhatod a netet, olvashatod a dokumentációkat.

Egyébként természetesen az rpm csomagokban lehetnek egyedi pre- és postinstall scriptek, tehát elvi akadálya nincs valami speciális megoldásnak a szokásostól eltérő esetben.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Frissítés esetén (RHEL) nem fog a konfig formátuma/értelmezése megváltozni (főverzión belül marad a frissítés), a dist-upgrade jellegű váltásnál meg ez bőven nem garantált - így szépen bele lehet rongyolni olyasmibe, hogy a frissítés miatt valami nem, vagy hibásan működik mindaddig, amíg a már futó rendszeren az összes *.rpm* fájlt (és a hozzájuk rendelhető eredeti konfigot) össze nem veti az ember. Ezt a .deb alapon működő rendszerek jobban kezelik - bár amíg az rpm-es vonalon nem volt támogatott a dist-upgrade jellegű frissítés, addig ott a probléma gyakorlatilag fel sem merült.

De nem így van. Ha *.rpmnew van a * mellett, akkor a régi konfiggal megy, s nézheted, mi újdonságot érdemes átemelni az újból.

Ha *.rpmsave van ott, akkor a korábbi mentve lett, s a disztribútor az ujjat használja, a régiből visszatehetsz dolgokat, ami kell.

Ugyanakkor manapság az a divat, hogy a /etc/valami.conf a default, nem piszkáljuk, a /etc/valami.conf.d/*.conf file-okon végigmegy, s amit ott talál, azt használja a default után. Így a beállításaid maradnak, de az új default simán cserélhető.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jaj, de utáltam Arch-nál a sok *.pacsave és *.pacnew fájlt.

A mostani megoldás (irány) a legszimpatikusabb: minden konfigfájlt a csomagkezelő foo.conf.sample néven hoz. Ha kell konfigfájl, csinálsz ebből egy másolatot foo.conf néven, szerkeszted, és annyi. Frissítéskor nem törlődik, nem írodik felül, stb., a csomagkezelő látókörén kívül van.
Többek között azért is praktikus, mert mindig van egy eredeti konfig (jellemzően megjegyzésekkel tűzdelve).

Szerk.: arch-wiki szerint ha frissíted a csomagot, és az original = X, current = Y, new = Y eset lép érvénybe, akkor a csomagkezelő beszippantja a módosított konfigfájlt (merthogy ugyanaz a tartalma, mint az új verzióban). Aztán a következő original = X, current = X, new = Y-szerű frissítéskor felülíródik?
Nyilván az XYY kicsi eséllyel fordul elő (pl. egy olyan eset jut eszembe, hogy a musicpd-ben a kimenetet az alapértelmezett X-ről átállítod Y-ra, a csomagkészítő is kitalálja ezt, frissül a csomag - de ezután a csomagkészítő rájön, hogy mégse jó valami miatt az Y kimenet, ezért a default konfigban ismét X lesz, user elveszti az Y kimenetes konfigját), de azért akkor is.

Viszont a sample-ös megoldással még kevésbé vagy rákényszerítve arra, hogy összemergeld a saját configodat a csomagból érkezővel. Ez akkor nem probléma, ha a configfile formátuma változott, mert legfeljebb nem indul el a service. De mi van akkor, ha valamilyen security issue volt a default confoggal?

Ha biztonsági probléma van az alapértelmezett beállításokkal (magyarra lefordítva :) ), az mindkét megoldásban probléma, egyik se nyújt rá automatikus megoldást (nyilván ha a default konfiggal dolgozol, akkor csomagfrissüléskor).
Ha a konfigfájl formátuma változik, ritkán megy automatikusan a változtatás, felhasználói beavatkozás nélkül.
A sample-féle megoldásnál miért vagy kevésbé rákényszerítve? Nem dob egy warning-ot, az igaz (ez lenne a nagyobb kényszerítés?), de látod, hogy frissült, és esetleg meg kellene nézni.

Ez rpm, itt nincsenek olyan úri huncutságok, mint a debconf. Az rpm nem kérdez, felmásolja a dolgokat, annyit tud tenni, hogy ha egy konfignak jelölt file változott, akkor nem csapja felül, hanem egy konfig.rpmnew-t mellé. (És bár először ezt egyértelműen fosnak tartottam az rpmben a dpkghoz képest -- ami furi, mert egyébként egy csomó jó dolga meg van -- egyre inkább kezdem úgy látni, hogy ez egy elég jó design döntés).

Persze lehet taknyolni pre- meg post-inst scriptekben kézzel, de az az álmoskönyv szerint nem jó ötlet.

Ott valóban nincs, de az, hogy egyáltalán nem pöcsöl interaktív dolgokkal telepítés közben, az dist-upgadetől független dolog, egy sima update is pont ugyanolyan.

De egyébként ja, RHELen nincs dist upgadre, illetve ahogy mondod, 6->7 között van valami, ami bizonyos peremfeltételek mellett működik, de sose láttam, mert ahol eljutunk odáig, hogy mehet a váltás, ott szivatjuk magunkat ilyenekkel, kitesztelt új cuccból reinstall. (Ez persze környezetfüggő, nálunk nem nagyon lett volna erre igény.)
(az mondjuk humorherold, ha egy default installon már nem megy)

fedora viszont elvileg csinál. Most az van desktopon, majd ha jön, megnézem.

cserébe nem döglik be benne minden héten valami (nem viccelek, szerintem kb minden páros héten baszakszik a dokkoló), meg default installos csomagok nem verik be folyamatosan a fejüket a selinuxba.

És az igazság az, hogy arra a sok nagyon friss dologra nincs olyan cefetül szükség ott, ahol ezeket használják.

ja, és a dist upgrade meg nem azért ilyen, mert még nem ért oda, hanem mert nagyon igény nincs rá.

Évek óta tökéletesen frissül a rendszerem kiadásról-kiadásra (Ubuntu) úgy, hogy közben használom. Értem mit mondasz, de idejét nem tudom, mikor borult meg utoljára a saját rendszerem normál használat vagy upgrade közben, nem érzem valós veszélynek az összeomlást. Ha mást nem, de az upgrade alatt szeretek legalább olvasgatni. A böngésző a betöltött libjeivel elvan a memóriában, aztán alóla cserélődhet a többi komponens. Cserébe ha jönnek a hibák, megértem hogy hopp, ez az upgrade miatt van.

Ami pedig az esetleges megborulást illeti, nos többször is volt szerencsém rendszerfrissítés közbeni nem szoftveres okokból adódó megszakadáshoz. Ha máshogy nem is, de egy helyreállító módot mindig el tudtam indítani és onnan szépen megkértem a dpkg-t hogy ugyan fejezze már be amit csinált. De arra is volt példa, hogy a rendszer normál módban éppen csak egy konzolig jutott. A dpkg innen is szépen rendbe tette. De ha nagyon-nagyon megdöglik, akkor Ubuntu LiveCD + chroot.

Szóval nem igazán értem ezt az óvatoskodást, mert működik anélkül, hogy a félórás upgrade folyamat kényszerpihenőre küldene, ha meg megszakad na bumm, majd jól helyreállítja a dpkg, ahogy eddig is.

Azért azt gondolom érted, hogy ez olyan frissítés mintha Win7-ből Win10 lenne.
Amikor frissítesz azonos kiadáson belül bármi szoftvert akkor nem kell újraindítani. Sőt volt hogy közben olyannal dolgoztam amit frissített, pl. LibreOffice és ez sem jelentett gondot.
Kernel frissítéskor szoktam újraindítani az egész rendszert vagy disztribució teljes frissítésekor, cseréjekor frissítések miatt. Ha csak egy program frissült akkor csak a programot indítom újra a frissítés után. De frissítés alatt is használhatom, bár nem célszerű. Kicsit olyan érzés mint autópályán 120-nál beönteni az ablakmosót.
De úgy tudom van megoldás már a kernelfrissítés miatti újraindítás kiküszöbölésére is. Szóval már akkor sem kell újraindítani.

> Azért azt gondolom érted, hogy ez olyan frissítés mintha Win7-ből Win10 lenne.

Persze. De windows-on sem a userland programok frissítése igényli az újraindítást. Mi több, a frissít-miközben-használom című feature a MS Office-ban is megvan - bár több szempontból aggályosnak tartom.

Ha jól értelmeztem disztribució frissítést csinált. Miközben elszállt a net. (tehát ablakosként lehet úgy értelmezned hogy win7-ből win10-t csinált éppen.)
A "forced always yes" paraméter volt a gond, nem pedig az internet problémája.
Vannak emlékeim egy rendszerről ami hasonlóan áll a dolgokhoz, csak ott nem a felhasználó adja ki, hogy akkor is telepítsen ha nem kellene. Szerencsére már csak emlékeim vannak. Így nem látom kikapcsoláskor a 75 valamilyen frissítést, majd a reggeli bekapcsoláskor 74 kiválasztottnak a visszavonását.

Ó, a Win10 legalább képes előadás tartása közben is újraindulni frissítés címén, jelzés nélkül (volt is ilyen post a BMEME-n, az én órámon történt).

Az egészben az az izgalmas, hogy most már group policyban be van állítva, hogy csak felhasználói kérésre frissítsen, de így is előjönnek non modal, képernyősötétítő ablakok (amik megölése kb. három-négy klikk). Óra közben élmény. Enterprise. A Start menübe visszakúszó szutykokról nem is beszélve.

Komolyan, tényleg fogok indítani egy Windows 10 debloat laboratóriumi tárgyat.

( wachag | 2017. 02. 22., sze – 13:39 )

Amúgy milyen os ez? Milyen disztribúció?