-
PROHARDVER!
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
-
daninet
veterán
válasz
bambano
#34980
üzenetére
Most ezt találtam:
# /etc/systemd/system/wait-for-ping.service[Unit]Description=Blocks until it successfully pings 192.168.1.200After=network-online.target[Service]ExecStartPre=/usr/bin/bash -c "while ! ping -c1 192.168.1.200; do sleep 1; done"ExecStart=/usr/bin/bash -c "echo good to go"RemainAfterExit=yes[Install]WantedBy=multi-user.targetEnable that service with:
sudo systemctl daemon-reloadsudo systemctl enable --now wait-for-ping.serviceThen edit your fstab as follows to include this as final mount option:
x-systemd.after=wait-for-ping.service -
-
#34897
lionhearted
őstag
bambano
#34894
-
Vasti74
senior tag
válasz
bambano
#34755
üzenetére
OK, tehát akkor kijelenthetjük, hogy a ventilátor szoftveres piszkálása - szabályozása eleve halott ötlet. Csak tudnám, hogy akkor ki volt az a szerencsétlen eltévedt programozó, aki ezt nem tudta, úgyhogy megcsinálta az ehhez szükséges programokat pl. linux alá?! Sőt, mások sem tudták - ők meg Windows alá készítettek hasonló alkalmazásokat! Ezt a sok elfecsérelt időt... ;-)
Egyébként pont leírtad ennek ellenére, hogy mit szeretnék szabályozni, szóval valami értelme mégis lehetne a dolognak... ;-)
Kész, feladtam! Régimódi vagyok: ha kérdezek egy konkrét valamit, akkor arra lehet kapni szerintem egy választ olyantól, aki tud rá válaszolni. Vagy lehet nem kapni választ, ha nincs olyan, aki tud válaszolni. Kb. ezek a lehetőségek. Szerintem. -
totron
addikt
válasz
bambano
#34755
üzenetére
Hízelgőnek is tarthatnád, hogy kinézi a megoldást az itteniekből. Küszöbértékek variálásával, egyéni tűréshatárra szabott finomhangolással igenis beállítható egy nagyságrendekkel élhetőbb görbe, egy jóval értelmesebb zajeloszlás. Nem kotyogó venti és minőségi csapágyak mellett persze. Ha csak a hardverre hagyatkozik, akkor egy következő BIOS-kőbe vésettséggel találja csak szembe magát.
#34748lionhearted, csak ugye a lassabb ventitől melegedni fog a rendszer, szóval a vezérlés görbe másik pontjára jutunk.
Ez egy deszép megfogalmazás.
Ha már szóba került, tudtok ajánlani valamit? Brand gépet ezek szerint nem. Néha már váltanék ThinkPad-ről asztalira, de Vasti problémája engem is visszatart. Referencia a TP FanControljának jó hangolhatósága. -
Vasti74
senior tag
válasz
bambano
#34751
üzenetére
Ezt tényleg nem értem.
Még mindig ott tartok, hogy egy linuxos fórumon megkérdeztem, hogy a gépemen lehet-e valahogy a procihűtő fordulatszámot szabályozni?
Linux alatt!
Mert ez egy linuxos fórum.
Ez azt jelenti, hogy szoftveresen, mert a linux ugye tulajdonképpen egy szoftver.
Erre már mindenféle barkácsolós ötlet jött (ráadásul erősen kétséges sikerű - hasznú) , illetve hogy inkább ne csináljak vele semmit.
De linuxos - szoftveres ötlet még egy sem!
Ez hogyan hogy így akkor most mi?! :-)
Kész, ennyi feladtam... -
Vasti74
senior tag
válasz
bambano
#34746
üzenetére
OK, hogy átkapcsolom, ha lehet "feszültségvezérelt módba": de mit fog ehhez szólni a BIOS? Hogyan fogja utána vezérelni? Mert gondolom a szoftver, ami vezérli, nincs erre felkészítve.
A szabályozást meg nem kellene elveszíteni, mert akkor hogyan tovább? Egy fordulaton forogna a ventilátor, ami "hideg" procinál túl sok, melegben meg esetleg túl kevés?
Elnézést, de tényleg nem áll össze a dolog: vagy valamit rosszul tudok, vagy valamit félreértek, de szerintem ez így nem OK ;-) -
Apollyon
Korrektor
válasz
bambano
#34726
üzenetére
Vagy csak pusztán azért, mert a gúgli aljas és kész. Ungoogled-chromiumban minden letiltott kiegészítővel is ugyanaz a hiba, ugyanúgy nem tölt be a tecső videó hacsak nincs webgl tiltva. Ez böngésző specifikus tiltás, direkt erre célozva. Ellenben Vanadium alatt nincs ilyen gond, de az meg csak okostelóra van.
Firefox alapú böngetők meg szimplán büntetve vannak a betöltés delay-jel. -
#34722
lionhearted
őstag
bambano
#34720
válasz
bambano
#34720
üzenetére
Miben más?
Az általad leírt igények:
- X-hez kell a /home
- /home-hoz kell a drbd
- drbd-hez kell a networkingNem konfiguráltam fel neked drbd-t, így tényleg más "problémára" megoldás, de a valóságban egyszerűsítettem a drbd által adott inputot és outputot, miszerint: kell neki networking (curl exit code 0/nem0), ha van networking, akkor lesz egy blockdevice (drbd a /dev/akármit csinálja, az én implementációm meg egy konténerfájlt valós helyi deviceról másolva.)
Nincs arról szó, hogy a systemD-hez internet kellene, ez egy adottság volt az én környezetemben, de nem a service leíróban megfogalmazott követelmény, hanem a "kódban" (curl).Tényleg felfogni sem tudom, hogy mi az, ami neked ebből nem világos, amiből azt gondolod, hogy ha így megcsinálod a saját valid drbd megoldásod, akkor ahhoz kötelezően internet kell.
Egyszerűen át sem gondoltad, csak a sok szívásodat arra töltöd ki, hogy lehetetlen, bármit írok. Nem az, és minden igényt teljesített, nem volt/kell extra megszorítás.
@emvy: nyilván, de így is teljesen felesleges volt 10 percet is eltöltenem az egésszel (ebből kb 90s a gép létrehozása "üres" környezetben), ha az egész napom arra megy el, hogy magyarázzam a falnak, hogy működik, amit szeretne.
-
#34719
lionhearted
őstag
bambano
#34718
válasz
bambano
#34718
üzenetére
Ott megoldás. Független attól, hogy a hálózat helyi vagy nem, mert a drbd nem igényli majd, csak az én curlom. Bizonyítani került bele, hogy van hálózat, ahelyett hogy felkonfigoltam volna csak neked egy igazi drbd-t.
Internet nélküli gépet nem tudok csinálni, mert a felhőben fut, el se érném... De lényegtelen is, mert nem akarod elfogadni a tényt, hogy működik, nem kuszál össze semmit, és nem a drbd a hálózati menedzser, akár helyi háló, akár nem.
Ne harcolj olyan démonnal, ami nincs.
Várjuk a következő feladatot, ingyenes oktatási keretre.![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#34717
lionhearted
őstag
bambano
#34716
válasz
bambano
#34716
üzenetére
Mi a különbség az internetes networking és a lan között ? szerintem csak a gateway címe. Nekem így volt egyszerűbb tesztelni, hogy van hálózat, de ez nem igénye a megoldásnak.
a network-online.target nem azt jelenti, hogy van internetkapcsolat, vagy nem értem hol beszélünk el egymás mellett.
Csak azt, hogy a networkmanager (bármelyik is az) up-ot ad vissza. -
#34715
lionhearted
őstag
bambano
#34713
válasz
bambano
#34713
üzenetére
Megoldottam szerintem, Móricka behelyettesíttéssel.
drbd service before remote-fs-pre.target after network-online.target. Úgy néztem meg, hogy van-e háló, hogy google.com curloztam, majd ddvel csináltam egy file alapú blockot.
Utána mount after remote-fs-pre, before remote-fs, ez csatolja az mnt alá a képfáljt.
Mindkettő wantsby multi-user, de akár graphical target, display nekem itt nincs, a ploton minden jól kivehető.
És semmi rendszerfájlhoz nem nyúltam, kettő újat írtam csak, 22 LTS Ubuntu, systemD 249 -
#34712
lionhearted
őstag
bambano
#34711
válasz
bambano
#34711
üzenetére
Nyilván, de az mitől függ? Lokális diszk csak elérhető, random pendrive nem mérvadó, távoli eszköz meg gondolom ugyanúgy networking. Így nem kivehető, hogy mi a gond... lassan éled fel egy lokális blokkos eszköz? Timeout megvárja... Vagy mi a nehezítő körülmény. Te hoznád létre valami fájlból? Annak is mennie kéne (snap is így megy).
-
#34710
lionhearted
őstag
bambano
#34708
válasz
bambano
#34708
üzenetére
Nyilván nem fogja helyetted megírni, de amúgy mintha hiányozna egy lépés, mert most 2-2 esemény párt írtál csak (drbd a networkinget várja, lightdm a mountot).
Nyilván tucatnyi service van, ami megvárni a networkinget, valamint egy rakat mount is (snap, ha más nem
). A mount unit egyetlen kínja, hogy a fájl neve nem választható, hanem az elérési útvonal, hiába kell a tartalmában is megadni ezt... 
bináris log: aki tömöríti az előző napi logot, az már binárisban tartja.
-
válasz
bambano
#34698
üzenetére
> ha keresek valamit a logban, akkor systemd esetén journalctl-lel kilistáztatom és utána grep-pel vagy valamivel keresem, megnézem.
Valld be, hogy csak szivatsz minket!
tenyleg kis ceg vagyunk, igy az applikacionk csak havi 5 terabajt logot produkal, sok sikert a greppel akar egy napi lognal is! (Nem, nem lehet mindig mindent ELK-ban tartani. (journalctl | grep az tenyleg kismeretu logoknal jol mukodik, de akkor nem fogod tudni hasznalni pl. a beepitett indexalast)> szerk: egyébként egy lemezhiba esetén annak van nagyobb valószínűsége, hogy a bináris log olvasható marad, vagy annak, hogy a text?
ez relevans lenne, ha pl. merevlemezre irjatok az adatokat bitrol bitre, es igy vegulis le lehet majd olvasni elektronmikroszkoppal -- de 2025-ben flash alapu tarolokat hasznalnak, titkositassal, tomoritessel, es SEMENNYIRE nem use case, hogy valaki beleb*szik egy csavarhuzot a diszkbe, es a maradekot szeretnenk visszaolvasni egy masik IBM XT-ben
de a valodi valasz egyebkent: ha fontos a log tartalma, akkor nem uldogel egy diszken backup nelkul, hanem valos idoben replikaljuk mashova is, tehat van backup
-
urandom0
senior tag
válasz
bambano
#34699
üzenetére
Mivel én nem használok DRBD-t, életemben kb. kétszer láttam, így nem tudom, mi okozhatja nálad a problémát. De azt ugye érted, hogy ennek az ég világon semmi köze sem a SysV inithez, sem a Systemdhez?
De én most le vagyok sokkolódva attól, hogy van, aki úgy grepeli ki a journalból az infókat. Azért nem ezt gondoltam volna, főleg olyantól, aki régóta a szakmában dolgozik...
Mondom én, hogy itt arról van szó, hogy ti nem akarjátok megismerni a Systemd-et, jól elvagytok ti a régi világban, és nektek az úgy oké. Egyébként szeretném jelezni, hogy a Systemd képes SysV init scripteket futtatni, úgyhogy tulajdonképpen nem olyan nagy baj, ha nem akartok közelebbi kapcsolatba kerülni a Systemddel. -
urandom0
senior tag
-
urandom0
senior tag
válasz
bambano
#34665
üzenetére
Az svr4 init is újraindít processzeket, ehhez csak az inittabba kell egy sor. Nem rakás unit file szerteszéjjel szórva a komplett fájlrendszerben.
Nincsenek szerte szét szórva, minden egy könyvtárban van...
Elhiszem, hogy a doksiban el tudtad olvasni, hogy tud dependelni. A valóságban nem működik rendesen.
Nálam eddig mindig működött. Pont a napokban csináltam rsync-hez egy service-t, ami fájlokat szinkronizál két RPi között,
A szöveges logokat is lehet szűrni grep-pel. Nem találjuk fel újra a kereket.
Hát persze, amíg egy-egy kifejezésre akarsz szűrni, ez addig jó. De ha kicsit pontosabban akarsz szűrni, mondjuk X-Y dátumtartományon belül szeretnéd szűrni egy adott service-től érkező üzenetek közül a critical üzeneteket, de azok közül is csak azokat, amik adott usertől érkeznek, úgy, hogy szerepeljenek benne plusz adatok (pl. a teljes cmd line, a hostname, ...), az journaldctllel egy sor. Grepeld ki ugyanezt...Azokat a beállításokat, amiket a journald-nek meg lehet adni, csak bináris naplózással lehet megadni?
A beállításokat szöveges conf fájlban adjuk meg.
Van biztosíték arra, hogy azokat a bináris naplókat 10 év múlva is fogod tudni olvasni bármivel?
Miért akarnék 10 év múlva logokat olvasni? 10 év múlva jó eséllyel a mostani rendszerek fele sehol sem lesz, nem hogy a logjaikat olvasgassam.
De ha annyira fontosak a logok, be lehet állítani a journal.conf-ban, hogy továbbítsa a syslognak, vagy systemd-journal-remote-tal átkültheted log szerverre.
Egyébként a Systemd-et le fogod tudni fordítani 10 év múlva is.Az, hogy amit svr4 initben 20 másodperc alatt egy darab vi-jal elintézek, azt systemd-nél három nap guglizás után se lehessen elintézni, az nonszensz.
Pl?
-
urandom0
senior tag
válasz
bambano
#34660
üzenetére
Ha be van állítva DNS cím, akkor nem fallbackkel, még akkor sem, ha nem elérhető a DNS szerver. Ha viszont nincs beállítva statikus DNS cím, és a kliens nem kap sehonnan sem DNS címet, akkor lép életbe a fallback DNS.
Egy processz elszállhat tőle független okokból is, viszont van értelme újraindítani a processzt az ok megszűnése után.
De én nem ezért szeretem a Systemd-t, hanem mert úgy általában lehet dependelni a szolgáltatásokra, nagyon egyszerűen. Pl. a network-wait-online-re (vagy a network-pre.targetre) dependelve biztos lehetek benne, hogy addig nem fog elinduli a service-em, amíg nincs hálózat.
És én a logolást is szeretem, nagyon könnyen lehet szűrni egy unitra, vagy adott időtartományra, stb. A journald-nak van egy csomó beállítása, meg lehet adni, hogy meddig logoljon, mennyi tárhelyet használhat maximum, és ezt megint viszonylag egyszerűen.
De ha csak arról van szó, hogy egy sima service-t kell indítani, azt is pár perc összerakni...Ha mást akarsz, mint amit a csomagkarbantartók kitaláltak, akkor nem meglepő, hogy falakba ütközöl, azért ez nem egyedi jelenség.
-
urandom0
senior tag
válasz
bambano
#34651
üzenetére
Ismerem a nézeteid a Systemdről, és tudom, hogy ha ezer hozzászólást írnék arról, hogy szerintem miért nincs így, akkor te az 1001-ben leírnád, hogy de, így van
Én is Linux (és Windows) üzemeltetésből keresem a kenyerem, és sosem volt gondom a Systemddel.Csak ezekre válaszolok:
Aki olyan baromságot csinál, hogy ha nemlétező user alatt kellene futtatni egy programot, akkor falbackkel rootra, és azóta sem látszik, hogy javult volna a hozzáállása, azt nem engedjük be komoly rendszerbe.
Ez jelen pillanatban úgy működik, hogy ha nem létező user-t adsz meg, akkor nem indul el a service ("Failed to determine user credentials: No such process").
Lásd még fallback google dns-re.
Ez tényleg rossz lépés volt, de úgy látom, javítva lett, most már megadva FallbackDNS, csak lehetőségek vannak felsorolva:
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google: 8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9: 9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net -
-
urandom0
senior tag
válasz
bambano
#34530
üzenetére
Mert a Systemd nem tudja, hogy melyik fájlrendszer lokális és melyik hálózati, és ez így van jól. A rendszergazda majd eldönti.
Vasti74
Érdemes még beleírni a reconnect és a x-systemd.mount-timeout=5 opciókat is. Az előbbi arra utasítja a rendszert, hogy próbáljon meg újracsatlakozni, ha valamiért lecsatlakozna, a második pedig arra, hogy ne tartson tovább 5 másodpercnél a csatlakozási kísérlet. Mert ha próbál csatlakozni, de nem tud, akkor a fájlkezelőt megakaszthatja.
-
#34533
lionhearted
őstag
bambano
#34530
-
Vasti74
senior tag
válasz
bambano
#34530
üzenetére
Passz... Én már egyre kevésbé értem a számítógépes dolgokat, és az az igazság, hogy már nem is akarom megérteni - csak az zavar, hogy kicsúszik az irányítás a kezemből ;-)
Most éppen a Virtualbox szívat, ami eddig (Debian - Ubuntu - Mint) annyi volt, hogy feltelepítettem, és használtam, a Fedora alatt meg X lépésben feltelepítettem, és nem működik a régi virtuális gépem. De elfogyott a türelmem, egyelőre feladom ;-) -
#34507
lionhearted
őstag
bambano
#34503
-
ViZion
félisten
válasz
bambano
#34436
üzenetére
ehh...
Jó hír: fstab van itt is (headles minimal debianon van, de tartottam tőle, h ezt is átvariálja).
Rossz hír: "The optionnosuidignores the setuid and setgid bits completely, whilenoexecforbids execution of any program on that mount point, andnodevignores device files. This sounds great, but it:
only applies toext2orext3file systems
can be circumvented easily"Bang... ez ext4 természetesen. De ez egy közel 10 éves leírásból van...
-
ViZion
félisten
válasz
bambano
#34436
üzenetére
Köszönöm!
hopszi... ezt akkor meg kell keresnem, h hogyan kell. Fstab az OK, de ez nem ott van csatolva. Proxmox bind mount, csak azt nem tudom, h a PVE-be csatolt HDD paraméterek öröklődnek-e (gondolom igen). Illetve a PVE a mezei adat HDD-ket hogy csatolja (itt is van next-next finish, és lövésem nincs mi a default, de este meglesem).
Az is zavar, h SMB mappáknak 777 permission kell, majd smb-ben create mask. Nyugodtabb lennék, ha a szülő mappát is korlátozhatnám. -
#34425
lionhearted
őstag
bambano
#34423
-
#34424
lionhearted
őstag
bambano
#34420
-
válasz
bambano
#34392
üzenetére
Err:5 http://deb.debian.org/debian bookworm-backports InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131Nem lett jobb
Ezt a két kulcsot hol tartják? honnan tudnám letölteni, és hová kell rakni?
Fórumon találtam egy olyan tippet, hogy
sudo gpg --keyserver deb.debian.org --recv-keys 0E98404D386FA1D9 6ED0E7B82643E131
de nem csinál semmit, vár valamire, csak ctrl+c-vel tudom megszakítani. -
CPT.Pirk
Jómunkásember
válasz
bambano
#34276
üzenetére
Igen... Tudtam róla, hogy megjelent pár bad sector és már tervben is volt a cseréje... Aztán most hirtelen 10x annyi bad sector lett meg 4000 gyenge és azt mondja a hd sentinel, hogy még van 4 nap hátra az életéből...
Mondjuk tök jó, hogy kifejezetten 24/7-es üzemre való, kamerarendszerhez kitalált hdd-t használtam és alig 4 évet bírt ki...májkimiki: lehet sosem végeznék vele. Még a fájlkezelőben a mappák között navigálás is fájdalmasan lassú ezen a cuccon. Most meg egy svn mappát próbálok menteni, ami rengeteg apró fájlból áll... Asszem egész éjjel ezen fog dolgozni.
-
CPT.Pirk
Jómunkásember
válasz
bambano
#34232
üzenetére
De kint van, ahogy a gépeink is, onnan backupolja a OneDrive / sharepoint megosztásainkat. Már csak ezért is frissíteni kell időnként legalább a klienst, mert szokott változni az OneDrive API.
Ráadásul az svn szervert is elérhetővé kellett tenni kívülről, sajnos a legfőbb munka programunk egy bug miatt csak ilyen formában tud svn szervert kezelni, majd ha egyszer veszünk új verziót akkor ez megszűnhet, csak hát méregdrága a program...
A net a cégnél meg ilyen telephelyi net, ami megoszlik több cég között... Szóval semmi sem ideális, én meg nem vagyok IT-s, nincs is IT nálunk.
Illetve van, én mert más nincs... Érted. -
CPT.Pirk
Jómunkásember
válasz
bambano
#34230
üzenetére
Megjavítani nem akarom ami működik, de azért egy LTS Uborkától szokatlan, hogy ne lehetne pár hetente frissíteni hiba nélkül, miközben itthon meg már több éve Arch alapú pörgő disztrókat használok és minden frankó...
Amúgy igazából idő kellene, hogy átgondoljam ezt az egész backup szerver témát, de annyi meló van, hogy "jóvanezígy". Most csak egy összetákolt régi gép egy vacakoló szünetmentesre kötve egy "garázscégben".
-
#78522999
törölt tag
válasz
bambano
#34158
üzenetére
Nincs dns. A phpmyadmin-t is csak amolyan szórakozásként tettem fel, de ja... nagyon nem kéne.
Az egyik query-re 200 volt a response, azt megnéztem magam is és szórt ki valami adatokat. Ez bizony csúnya bug.
Szóval megy le a gépről.Elég elkeserítő amiket látok. IP alapján mongól, tajvani és kínai támadások ezek.
De mindenesetre tanulságos.
Még szerencse, hogy hobbi vps ez.Amúgy lehet hülyeség, de mintha azóta lenne ez a sok furcsaság, mióta a certbot-ot használtam a domain-ekhez.
-
-
urandom0
senior tag
válasz
bambano
#34146
üzenetére
Ebbe így még nem gondoltam bele.
Én 2000 fölé szoktam rakni az SSH portot a WAN felől elérhető eszközeimnél. Most ha lenne valamilyen kártevő valamelyik gépemen, akkor első körben le kéne állítania az sshd-t, hogy bindelni tudjon a portjára, de ehhez már eleve root jog kell (ha csak nincs valami local privilege escalation vulnerability a rendszerben), de ha már van root joga, akkor cseszhetem. Akkor ellophatja a privát kulcsomat, stb.
Te hát mindenképp kell neki root jog, ha át akar verni. -
#34103
lionhearted
őstag
bambano
#34102
-
válasz
bambano
#34086
üzenetére
Na, itt az van, hogy a NAS az kb. egy archív. Redundánsnak kell lennie, amin van, de nyilván van róla backup is.
A KVM host meg egy mezei asztali gép.@lionhearted : Miért?
Néztem, hogy 2012-es fórumokon meg előadásokon van szó több terás guest diszkekről KVM-en.A ZFS csak egy lehetőség. Pont az a kérdés, hogy ha ilyen eset van, akkor mit érdemes, ami RAID0, FS szinten, és jó VM alá.
Az Ext4 nem olyan jó, az FS szintű tükröt nem tud, a software raid mondjuk OK, de elég rugalmatlan.
Janos666 kifejtette múltkor, de ott még csak NAS felhasználás volt a cél. -
válasz
bambano
#34069
üzenetére
> és ti a terabyte nagyságrendű logokat összeöntitek egybe?
Persze, hogy keresnél egyébként? Mármint nyilván szénné van indexelve, de nem az van, h van óránként meg szolgáltatásonként egy fájl.
De természetesen strukturált logra van szükség ekkora mennyiségnél.
> miért nincsenek olyan macerák a journalnál, amiről azt hiszed, hogy text lognál vannak?
Mondj egy konkrét példát, és beszélhetünk róla. Legyen mondjuk a log rotation?
-
válasz
bambano
#34061
üzenetére
1. Az Unix alkotoinak az elkepzeleseit te is csak ertelmezed, nyilvan a sajat szemszogedbol.
2. Valtozik a vilag, nem kotelessegunk azt csinalni, amit a PDP-11-et hasznalva gondoltak az alkotok. Miert lenne?> ha az operációs rendszer nem felel meg az eredeti, alapvető tervezési filozófiájának, akkor katyvasz lesz belőle
tok jok ezek a levegobol vett allitasok, nyilvan lehetetlen ertelmes beszelgetes folytatni roluk
> majd meglátjuk, hogy a dinamikus dns konfiguráció a fontos-e vagy a jogszabály
na jo
-
válasz
bambano
#34056
üzenetére
Ezek ilyen filozofalgatasok, neked ez az elkepzelesed az Unixrol, masnak meg mas. Es jelenleg akik alakitjak a Linuxot, ok mashogy akarjak.
> Alaposabban belegondolva mondhatjuk, hogy a tailscale a saját megoldása miatt erősen elfogult, tehát az, hogy szerintük mi a jó dns rezolválás, messze van az általános objektív valóságtól.
A Tailscale szeretne valamit megvalositani. Olyasmit, amire oriasi igeny van. Az oprendszernek nem az a feladata, hogy valami filozofianak megfeleljen, hanem hogy lehetove tegyen kulonfele use case-eket. A dinamikus DNS konfiguracio fontos. Ezt resolv.conf hekkelessel nem tudod elegansan es robusztusan megoldani.
-
válasz
bambano
#34049
üzenetére
Ha neked elég az ASCII log, akkor több lehetőséged is van azt használni. A világ elég jó részének nem optimális, mert túl komplex (igen - egy JSON logban szűrni sokkal egyszerűbb).
A probléma az, hogy azt gondolod, hogy egy sztékes helyen ülsz, de a többiek azt látják, hogy egy enyhén pityókás, morcos bácsi morog a Hawaii bowl-os helyen valami olyasmiről, hogy ez régen egy jó grillező volt, és követeli, hogy neki adjanak rendes húst
-
-
Vladi
nagyúr
válasz
bambano
#34031
üzenetére
igen... smindezt az ingyen kellene topikban.
Egyébként ilyenkor érdmes ránézni, hogy maga a projekt hol tart, aztán megnézni az update-testing tárolót és a rawhide-ot is. Ez utóbbiban szabad rablás van, tehát tolják bele az új kódot egy ideig. Hajlamos összeomlani de a legfrissebb fedorák közül. MOndjuk waylandnál van már 2-3 napos release amit még nem követett le.
-
#34002
lionhearted
őstag
bambano
#34001
-
válasz
bambano
#33986
üzenetére
Valoszinuleg utobbi miatt esett az xz-re a valasztas. A systemd felzabal mindent, korbe dependalnak egymasra, atlathatatlan az egesz, igy a tamadok felteteleztek, atcsuszik a kod.
Egyes feltetelezesek szerint nem is backdoor, hanem RCE - es mivel az sshd root kontextusban fut, a dalnak vege lett volna.
Az azert nem hagy nyugodni: ha egy Intel mernok nem futtat benchmarkokat es nem tunik fel neki, hogy tul sok CPU-t zabal az ssh, meddig terjed szet a kod?
-
urandom0
senior tag
válasz
bambano
#33977
üzenetére
Nem mondom, hogy nincs igazság abban, amit mondasz. Az tény, hogy a systemd marha nagyra nőtt, és ott van már PID1-ben majdnem az egész Linux, és ez nem biztos, hogy jó így.
De ez itt nem a systemd hibája volt. Ha bele akarunk menni, megkérdezhetjük, hogy miért gondolták jó ötletnek azt, hogy az sshd dependáljon a systemd-re? Én nagyjából tudom (mert utánaolvastam), azért, mert a systemd által nyújtott sd_notify() fv-t használja arra, hogy értesítse a systemd-et arról, amikor elindult.
Nem lehetett-e volna megoldani valami jó kis POSIX cuccal, vagy UNIX socket domainnel?
De biztos meg lehetett volna, de szerintem teljesen jogos volt a maintainerek törekvése arra, hogy ha már úgyis systemd-es környezetben fog futni az sshd, akkor használjuk már ki a systemd szolgáltatásait (ezzel systemd függővé tenni az sshd-t), mert hogy ennek előnyei is vannak. Nyilván, ha nem lennének előnyei, nem használnánk.
Tehát itt volt egy döntés a Debian és néhány másik disztribúció részéről, aminek lettek következményei. De szerintem ebbe nem nagyon lehet belekötni. -
Livius
őstag
válasz
bambano
#33751
üzenetére
A
br0interface-nek van IP cím adva, azon is működik minden DHCP és DNS már csak, a többin nincs semmi beállítás. A bridge jól működteti a LAN-t, ha a desktop PC arra van bedugva egyből jön is a DHCP-től az IP cím és megy a kapcsolat, SSH/SFTP belépéssel tesztelve lett gond nélkül. De a másik USB Gadget RNDISusb0interface az nem csinál semmit. Amikor a desktop PC USB-én arra van bedugva akkor unplugged-nek látja, tehát mintha a bridge nem csinálná meg a link kapcsolatot az RNDIS felé, csak az Ethernetes LAN felé van kapcsolata. -
válasz
bambano
#33732
üzenetére
én úgy látom nem
lenry@vavatch:~$ cat /proc/meminfo
MemTotal: 65769168 kB
MemFree: 973844 kB
MemAvailable: 51837440 kB
Buffers: 677280 kB
Cached: 50765676 kB
SwapCached: 0 kB
Active: 2061772 kB
Inactive: 51819556 kB
Active(anon): 18040 kB
Inactive(anon): 2582792 kB
Active(file): 2043732 kB
Inactive(file): 49236764 kB
Unevictable: 64 kB
Mlocked: 64 kB
SwapTotal: 4117508 kB
SwapFree: 4116996 kB
Zswap: 0 kB
Zswapped: 0 kB
Dirty: 876 kB
Writeback: 0 kB
AnonPages: 2403540 kB
Mapped: 1269580 kB
Shmem: 162444 kB
KReclaimable: 581068 kB
Slab: 780972 kB
SReclaimable: 581068 kB
SUnreclaim: 199904 kB
KernelStack: 22176 kB
PageTables: 49540 kB
SecPageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 37002092 kB
Committed_AS: 12910736 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 259584 kB
VmallocChunk: 0 kB
Percpu: 21120 kB
HardwareCorrupted: 0 kB
AnonHugePages: 610304 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
Unaccepted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 1580052 kB
DirectMap2M: 20348928 kB
DirectMap1G: 45088768 kB -
tvamos
nagyúr
válasz
bambano
#33543
üzenetére
Ugy ertettem, hogy a gep kiakad tole, vagy a steam nem indul, vagy ilyesmi, ha parancssorbol letorlom.
A gyerekkel majd leugyezem, vele nem lesz gond.
(#33542) csixy
Synaptic? Meg sosem hasznaltam...A Timeshift-tel le tudom torolni, csak gondoltam elrakom, ha kell valamikor. De vegulis igazad van, nyugodtan legyakhatom az egeszet.
-
#33464
fatpingvin
addikt
bambano
#33460
fatpingvin
addikt
válasz
bambano
#33460
üzenetére
ez néha bajos. én RAID elemekkel szoktam néha szívni, pontosan nem emlékszem mi volt de valami olyasmi hogy ha a mda magához vette akkor a kernel visított ha az egyszeri diszket le akartam dzsuválni és nem engedte.
igazából a lényeg annyi hogy semmi ne akarja használatba venni mielőtt nullázol.
-
vicze
félisten
válasz
bambano
#33443
üzenetére
Ezekhez a gyártók már tegnap elkezdték kiadni a BIOS frissítéseket jó pár hibára, de brutál bonyolult a mennyiség miatt, hogy mi érintett.
pl. Lenovo (Valaki nagyon jól szórakozott a táblázatokon az tuti...)Ezek a hibák: AMD-SB-4003, AMD-SB-7005, INSYDE-SA-2023018, INSYDE-SA-2023034, INSYDE-SA-2023036, INSYDE-SA-2023038, INSYDE-SA-2023039, INSYDE-SA-2023047, INSYDE-SA-2023048, INTEL-SA-00813, INTEL-SA-00828, INTEL-SA-00836, INTEL-SA-00837, INTEL-SA-00783
Nem néztem végig mind(rohadt sok), de kernerlből szinte egyikre se lesz workaround. pl. az InsydeH2O-nél az egész BIOS-t frissíteni kell nyilván.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Csak azt, hogy a networkmanager (bármelyik is az) up-ot ad vissza. 
). A mount unit egyetlen kínja, hogy a fájl neve nem választható, hanem az elérési útvonal, hiába kell a tartalmában is megadni ezt... 
Köszönöm!
Illetve van, én mert más nincs... Érted. 
Új hozzászólás Aktív témák
Hirdetés
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Vírusirtó, Antivirus, VPN kulcsok
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Gyermek PC játékok
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest