-
Fototrend
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
bambano
titán
systemd-s bohóckodás helyett vagy beírod a crontab-ba (annak az usernek a crontabjába, amelyikkel futtatni akarod) @reboot címkével, vagy berakod a /etc/rc.local fájlba. Ez utóbbihoz lenni kell systemd service-nek, szóval nem teljesen systemd mentes megoldás.
De egy program elindítása az linux-kezdő kérdés, nem haladó.
-
#35132
bambano
titán
lionhearted
#35126
bambano
titán
válasz
lionhearted
#35126
üzenetére
-
#35128
bambano
titán
lionhearted
#35126
bambano
titán
válasz
lionhearted
#35126
üzenetére
A többi hogy lett lefoglalva kicsiben?
szerk: közben látom, hogy azok másik vg.
De azért az is furcsa, hogy a vg-k nem egyformán lettek megkreálva. -
#35120
bambano
titán
IstvánLászló
#35119
bambano
titán
válasz
IstvánLászló
#35119
üzenetére
Az átlag alaplap nem tud raidet, softraid van rajtuk, ami nullát ér.
-
#35116
bambano
titán
IstvánLászló
#35114
bambano
titán
válasz
IstvánLászló
#35114
üzenetére
Ha van lehetőség, akkor a raid1-ben KÜLÖNBÖZŐ diszkeket kell tenni. Annyi a lényeg, hogy az elérési idejük között ne legyen túl nagy különbség, mert ha az egyik sokkal hamarabb végez, mint a másik, akkor a lassút kidobja a kernel a tömbből.
-
bambano
titán
válasz
Ablakos
#35112
üzenetére
az efax végű az smr, az earx meg cmr.
ez baj.
ezt rosszul tűri a kernel. javasolt a cseréje. (az smr cseréje)az, hogy install után elindul a szinkronizáció, önmagában nem baj, mert tömb létrehozásakor kell. de ha ismételten elindul, az gond.
szerk: diszk hibát destruktívan badblocks -vsw-vel szoktam ellenőrizni, de ahhoz szét kell szedni a tömböt.
-
bambano
titán
válasz
_kovi_
#35060
üzenetére
Nem ártana elmondani, hogy mi az a storage.
fc? escon? ficon? iscsi?
a debiant lehet telepíteni iscsi-re, akár full iscsi-re, ha a bios képes bootolni iscsi-ről vagy http-ről, akár úgy, hogy a /boot egy pendrive-on van (jelzem, csomó szerverben ezért van usb csatlakozó az alaplapon, hogy oda bedugj egy pendrive-ot.
Ha felraktad a debiant alap iscsi-re, akkor tudsz olyan kernelt fordítani, ami kell, olyan initramfs-t, ami kell. Megcsinálod a multipath-ot, és utána repóból felhúzod rá a proxmoxot (nem csak iso-ból lehet proxmoxot telepíteni, hanem alap debianra apt-get-tel is).Emlékeim ködösek, hogy ilyet csináltam-e már 12-es debiánnal, de 13-assal biztosan, nincs két hónapja se és működött rendesen.
-
bambano
titán
válasz
Vasti74
#34752
üzenetére
Először is abból a puszta tényből, hogy megkérdezted, még nem következik, hogy az itteni fórumtagok tudják rá a választ. Másodszor az sem következik, hogy egyáltalán létezik rá válasz.
Eleve, amennyire én tudom, a hűtést *NEM SZOFTVER* vezérli. A hűtést egy mikrokontroller szerűség vezérli, a kontroller jelleggörbéjét lehet szoftverből állítani. Gyakorlatilag egy függvény, ami hőmérséklethez fordulatszámot rendel, és kb. ennek a meredekségét tudod állítani. Gyakorlatilag azt tudod állítani, hogy milyen proci hőfoknál kezdjen hűteni, és mennyire drasztikusan emelje a venti fordulatszámát, ha melegszik a proci. Ezzel be lehet állítani egyfajta egyensúlyi pontot, ahol a terhelés függvényében pörög a venti. De van még két marék paraméter hozzá.
Az egésznek mégiscsak az az alapja, hogyha melegszik a proci, növeli a vélt hűtési teljesítményt. Ha ettől nem hűl le a proci, akkor még növeli, ciklus vége. Tehát vagy le tudja hűteni, vagy feljebb pörgeti. Ezért hiába is erőlködsz, a terhelés alatti zajt érdemben nem tudod befolyásolni, max azt, hogy mikor kezdjen leszabályozni a proci.
Én ezért mondtam, hogy hagyd a fenébe, nem lehet vele mit kezdeni. Csak azt lehet vele kezdeni, hogy megoldod, hogy kevesebb hőt termeljen a proc. Vagy hardvert cserélsz.
Attól a kérdésed még helytelen marad, hogy linuxos fórumban tetted fel, ezt felesleges ezen a topicon és a topiclakókon leverni.
-
bambano
titán
válasz
Vasti74
#34745
üzenetére
A pwm-es ventilátorban két drót (+ test + fordulatszám ellenőrzés) megy a ventilátorba. Ha csökkented a feszültséget, akkor emiatt fizikailag két lehetőséged van:
1. a pwm vezérlés feszültségét csökkented, akkor egy darabig semmi nem fog történni, majd az egész vezérlés összeomlik.
2. a venti tápot csökkented, akkor a pwm feljebb fogja húzni a fordulatszámot.szerk: úgy tudod a pwm-es ventilátor fordulatszámát csökkenteni, ha képes rá, hogy átkapcsold feszültségvezérelt módba és ott csökkented a feszültséget.
a másik megoldás, hogy csökkented a proci terhelését és akkor nem kell majd annyi hűtés
-
#34720
bambano
titán
lionhearted
#34719
bambano
titán
válasz
lionhearted
#34719
üzenetére
Nem foglalkoztam azzal, hogy a te megoldásod, amelyet teljesen más problémára adtál, mint amit én kérdeztem, működik-e vagy sem. Indifferens.
"Ne harcolj olyan démonnal, ami nincs.": nincs systemd?![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#34718
bambano
titán
lionhearted
#34717
bambano
titán
válasz
lionhearted
#34717
üzenetére
A drbd nem internetről jön, hanem helyi hálózatról. Az, hogy van-e hálózat, nagyon egyszerű: ha elindult a drbd, akkor van, ha nem indult el, akkor nincs.
-
#34716
bambano
titán
lionhearted
#34715
bambano
titán
válasz
lionhearted
#34715
üzenetére
jéééézus...
tehát ha nincs internetem, csak helyi háló, akkor ez el se indul?
tuttkó megoldás, megdöglött a routerem, de az a gép is, amiről a routert életre pofozhatnám.szerk: szerintem jelentkezhetnél systemd fejlesztőnek
-
#34713
bambano
titán
lionhearted
#34712
bambano
titán
válasz
lionhearted
#34712
üzenetére
Ha beállítod a drbd unitjait, akkor a systemd elindítja. A gond az, hogy a systemd megállmodói szerint van egy logikai sorrend, ahogy össze kell rakni egy gépet, és ha ezt a logikai sorrendet te felrúgod, akkor felborul a systemd is.
Akik megálmodták a debiant, azok azt gondolják, hogy úgy kell működnie, hogy vannak a blokkos eszközeid (tipikusan hdd, sdd), arra húzol raid-et. A raidre lvm-et (esetleg cryptot), az lvm köteteket pedig mountolod. Az oprendszer többi része meg ettől függetlenül ahogy a proci bírja lóerővel, indul vagy sem.
Namost ebben az esetben a drbd-nek előbb kell elindulnia, mint ahogy minden mount lefut, mert mountolni kell. A lightdm-nek meg kell várnia azt, hogy a drbd-re rakott home dirt felmountold, mert az X-nek kell a home, ahol tárolva vannak a grafikus beállítások. Szóval bele kell nyúlni a szokásos boot folyamatba, hogy előbb álljon fel a hálózat, mert a drbd-nek kell, utána teremtődjön meg a home blokkos eszköze, mountolódjon, és utána mehet a lightdm.
-
#34711
bambano
titán
lionhearted
#34710
bambano
titán
válasz
lionhearted
#34710
üzenetére
"A mount unit egyetlen kínja, hogy a fájl neve nem választható": emlékeim szerint ez benne volt valamelyik kottában.
Gondolom azt nem kell külön specifikálni, hogyha mountolni akarsz egy blokkos eszközt, akkor a blokkos eszköznek léteznie kell. -
bambano
titán
"kis ceg vagyunk": vagyis a te szükségleted az általános az összes debian usernél?
"ez relevans lenne, ha pl. merevlemezre irjatok az adatokat bitrol bitre": mindig lemezre írod az adatot, az ssd is solid state DRIVE.A logod nem csak kifejezetten lemezhiba miatt borulhat össze, hanem más hiba miatt is.
Az az orbitális nagy vicc, hogy pont ma délután futottam bele egy memória hibába, ami simán összeborogathatott volna bármilyen bináris adatállományt, miközben egy text log részben menthető maradt volna.
-
bambano
titán
válasz
urandom0
#34706
üzenetére
"Mivel én nem használok DRBD-t": nem te mondtad, hogy annyi az egész, hogy csinálunk egy unitot és akkor működik?
Nem kell tudod, hogy mi az a drbd, nem kell tudnod, hogy hogyan konfigurálódik be maga a drbd, elég, ha azt tudod, hogy systemctl enable drbd.unit (most nem írom a betű szerint pontos parancsot) elindítja.Ezek után azt kell tudnod, hogyan csinálj egy olyan működő mount unitot, ami egy blokkos eszközt megadott csatolási pontra felmountol.
Utána azt kell tudnod, hogy hogyan szinkronizálod össze azt, hogy a drbd unit csak a hálózat éledése után induljon, és a unit, ami a lightdm-et indítja, megvárja, hogy ez a specifikus mount unit lefusson.
Ezt így kell csinálni a systemd-ben.
CSAK NEM MŰKÖDIK!
Akármennyi doksit olvastam, gugliztam, NEM MŰKÖDIK!
Ami erről a systemd doksijában van, az NEM IGAZ.
NAGYON SOK napot elcsesztem erre, gugliztam, rebootoltam ezerszer ÉS NEM MŰKÖDIK.Tessék, itt van előtted a pálya, bizonyítsd be, hogy én vagyok a hülye. Ja, és ez az első forduló, ha megoldottad és nekem is működik, akkor jön a következő feladat
Meg kellene kis magyarázatocska, hogy a szerteszéjjel össze-vissza linkelt unitok (a wants meg a provides meg a társai) mitől egyszerűbbek, mint két sor az rc.local-ba.
Érdekelne az is, hogy erre csinálok egy mount unitot, az nem működik, csinálok egy exec unitot, amiben egy darab mount parancs van, az működik.
Mellesleg abba az rc.local-ba, amire külön systemd unitot kell engedélyezni, hogy a systemd bootkor lefuttassa. sysv initben meg belinkeled a runcontrol szkripteket oszt jónapot.
-
bambano
titán
válasz
urandom0
#34697
üzenetére
"10 éve használok desktopon Linuxot": örülök, hogy fiatal pályakezdők is elkezdenek linuxozni
Ez egyébként valami isteni gondviselés lehet, mert nekem pont két órával ezelőtt szállt el egy gépem memória hiba miatt. Óriási csodának gondolom, hogy nem dőlt össze a komplett root fájlrendszer.
-
bambano
titán
válasz
urandom0
#34681
üzenetére
tehát neked kell egy összekonfigurált drbd meg egy komplett teszt rendszer, ahol egy ilyenre rá tudsz nézni, és megfelelő mennyiségű találgatás után esetleg lesz megoldás.
ha te kérdeznéd ugyanezt, hogy oldjam meg sysv inittel, én fejből megmondanám, hogy mit csinálj.
Hát EZ a nagy különbség.
-
bambano
titán
ha keresek valamit a logban, akkor systemd esetén journalctl-lel kilistáztatom és utána grep-pel vagy valamivel keresem, megnézem.
ha text a log, akkor a grep külön program nélkül saját maga is képes elvégezni a munkáját.erre jobb napjaimban azt mondanám, hogy fork bomba
szerk: másik hsz-edre: "Stimmel. És a journalctl nem elérhető neked, vagy mi vele a gond?" például ha egy php alkalmazásban logot kell olvasni (nekem van ilyenem), akkor text lognál simán megnyitom, beolvasom, átnézem. bináris lognál forkolni kell egy journalctl-t és úgy kell elolvasni.
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?
-
bambano
titán
válasz
urandom0
#34670
üzenetére
jaja, logszerver... múltkor is kaszálnom kellett, mert logszerverek nőttek a réten és zavarták a kilátást.
De mondok neked egy relatíve egyszerű dolgot:
debian trixie, van egy bekonfigurált drbd-m. ezt fel kell moutolni a home-ba, és ha sikerült, akkor engedni, hogy elinduljon a lightdm.ez rc.localban pár sor. lássuk a te systemd-s megoldásodat. ez egy ilyen történet, amire én gondoltam, a csomagkarbantartók meg nem. de a második fordulóra van ennél jóval cifrább is.
-
bambano
titán
válasz
urandom0
#34662
üzenetére
Ha hibás a dns konfig, akkor hibásnak *KELL* lenni a hálózatnak, különben sosem derül ki, hogy hibás a konfig. Annak is célnak kell lenni, hogy kitakarítod a hibákat a rendszerből.
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.
Elhiszem, hogy a doksiban el tudtad olvasni, hogy tud dependelni. A valóságban nem működik rendesen.
A szöveges logokat is lehet szűrni grep-pel. Nem találjuk fel újra a kereket.
"biztos lehetek benne, hogy" a szolgáltatásod vagy elindul, vagy nem.
Azokat a beállításokat, amiket a journald-nek meg lehet adni, csak bináris naplózással lehet megadni? Van biztosíték arra, hogy azokat a bináris naplókat 10 év múlva is fogod tudni olvasni bármivel?
Azt akarom, hogy ha más a feladat, és svr4 initben pikk-pakk össze lehet rakni, akkor systemd-ben még kevesebb meló legyen összerakni, különben nincs okom váltani. 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.
-
bambano
titán
válasz
urandom0
#34659
üzenetére
"Ez jelen pillanatban úgy működik": és itt a hangsúly a jelen pillanaton van.
Szerintem ha rossz a dns konfig, akkor működjön rosszul (vagyis ne működjön). A hiba elmaszkolása azt okozhatja, hogy a hiba oka nem kerül kijavításra.
Egyébként ezt az egész systemd alapgondolatot nem értem. Azt mondják, akik szeretik, hogy azért is jó a systemd, mert menedzseli a processzeket, újraindítja, ha elszálltak, stb. De miért is száll el egy processz, amire fontos feladatokat akartak bízni? Ha egy processz elszáll, akkor nem az a megoldás, hogy körbepakoljuk mindenféle szeméttel, ami újraindítja (és maga is bughalmaz), hanem az, hogy kijavítjuk a programot és akkor nem fog elszállni.
Egyébként amíg out of the box használom a debiant, nekem sem szokott semmi bajom lenni, még a systemd-vel sem. De abban a pillanatban, ahogy valami mást akarok, mint a csomag-karbantartók, rögtön falakba ütközöm.
-
bambano
titán
-
bambano
titán
Például a google szerverein szinte biztosan nem oob linux disztró fut. Tehát pont ők azok, akiknek teljesen mindegy, hogy mi van az átlag desktop user linuxában.
Az ibm pc azért nyert, mert az ibm hagyta, hogy belepiszkáljanak a vasba. A linux azért nyert a mininx-szel szemben, mert Linus hagyta, hogy mások is hozzájáruljanak a kernelhez. A minix egy zárt rendszer, aminek elolvashatod a forrását. Mondjuk lehet, hogy lehetne párhuzamot vonni Pöttering és AST stílusa között... lol.
Mondjuk az egy érdekesebb vita lehetne, hogy a linux miért nyert a freebsd-vel szemben is...
-
bambano
titán
válasz
urandom0
#34644
üzenetére
Az első és legfontosabb probléma a systemd-vel, hogy Pöttering elvtárs sokszor és alaposan eljátszotta a bizalmat. 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. Lásd még fallback google dns-re. És akkor még nem beszéltünk arról, hogy pulseaudio téren is futott már ámokot az elvtárs.
A második probléma, hogy a systemd nem működik. Amennyiben olyat szeretnél vele csinálni, ami nem az alap, akkor nem működik.
Harmadik, hogy a unix az sor alapú szöveges dolgokra van optimalizálva. Az, hogy a sima txt logokról áttért binárisra, az lehet egy jó választás, ha windowsod van, de unixon nem csinálunk ilyet.
Negyedik, hogy ki a franc ez a pöttering, hogy rákényszerít engem és másokat is olyan plusz munkára, ami nem térül meg soha? Az eredeti sysv init tudott mindent, amire valóban szükség van, ha kellett syslog, ntpd, felraktad, oszt jónapot. Abnormális kiadásokra kényszerít. És ne csak arra gondolj, hogy otthon van egy linuxod, amit néha bekapcsolsz két windowsos játék között, hanem arra is, hogy vannak, akik linux üzemeltetésből keresik a kenyerüket.
Mondjuk Pöttering pont annál a redhat-nél dolgozott sokáig, akik hamisítottak már gcc-t is, mit csodálkozunk. Azóta meg összenőtt, ami összetartozik.
Tőle függetlenül én azt egy beteges dolognak gondolom, hogy egyes programozók akkor is programoznak, amikor nincs mit értelmesen programozni. Tölthetnék hibakereséssel is az idejüket, csak az büdös.
KISS: Keep it stupid and simple. Ami nem ilyen, az nem unix. Csináljon csilivili processz managementet windowsra, az oda való, minket (pláne a mi munkaeszközeinket) meg hagyjon békén.
-
#34503
bambano
titán
lionhearted
#34491
bambano
titán
válasz
lionhearted
#34491
üzenetére
"Én azt nem értem, hogy ha a linux egy nyílt környezet, akkor hogy van az, hogy adott dolog egy másik disztróban adatik csak meg.": mert nyílt környezet. Mindenki azt farag belőle, amit akar, nincs központi utasítás.
-
#34426
bambano
titán
lionhearted
#34425
bambano
titán
válasz
lionhearted
#34425
üzenetére
-
#34423
bambano
titán
fatpingvin
#34422
bambano
titán
válasz
fatpingvin
#34422
üzenetére
nem.
bele akarok rakni a pdf-be, mint konténerformátumba, egy xml fájlt IS.
mint pl. az elektronikus számla. generálsz egy pdf-et, amiben benne van a számlakép, amit nyomtatsz, ha szükséges. plusz legenerálod az online számlarendszer szabályai szerint a számlát xml-ben, és azt is belerakod a pdf-be.másképp fogalmazva: a zip vagy a tar az egy konténer formátum. zip-be (tar-ba) bele tudsz csomagolni több fájlt. tudomásom szerint a pdf is ilyen, belerakod a dokumentumodat, és rakhatsz mellé más fájlt is.
ezt hogy linuxon, cli-ben?
-
-
#34353
bambano
titán
Roland861010
#34347
bambano
titán
válasz
Roland861010
#34347
üzenetére
ebben a hsz-ben nincs kérdés.
milyen választ szeretnél? -
#34288
bambano
titán
Speeedfire
#34287
bambano
titán
válasz
Speeedfire
#34287
üzenetére
iotop?
a magas load jelentheti azt, hogy sok processz vár io-ra.szerk: elvileg nem kellene raid-et szinkronizálnia, de ne zárjuk ki.
-
bambano
titán
válasz
CPT.Pirk
#34281
üzenetére
valójában nem teljesen nagyobb írási sebességről szól a történet, hanem konstans késleltetésről. ezt úgy éri el, hogy kevésbé foglalkozik az írási hibákkal, ettől lesz kicsivel gyorsabb. a kamerarendszereknél kevésbé fontos, hogy egy-egy kép részlete megőrződjön, sokkal fontosabb, hogy hiba esetén a többi kép rögzítésre kerüljön.
igaza van ubyegon2-nek, az a diszk csak kamera real time rögzítésére való, másra nem.
-
#34256
bambano
titán
lionhearted
#34254
bambano
titán
válasz
lionhearted
#34254
üzenetére
két felhasználó apacs jelszavának tárolásához pár giga ram, néhány cpu mag, jáva, webes admin felület, saját webkonténer...
valamit nagyon nem egyformán értünk a KISS elvről.
-
bambano
titán
válasz
CPT.Pirk
#34231
üzenetére
nekem az a problémám, hogy ha egy gép nincs publikus hálózaton, nincs vele baj, akkor minek hozzányúlni?
frissíteni? mióta systemd van a legtöbb disztróban? öngyilkosság.
ha nincs olyan sérülékenység vagy hiba, ami téged konkrétan akadályoz és a frissítés megoldja, akkor felesleges frissíteni. főleg, ha "annyi meló van".ismétlem magam: ha nem romlott el, ne akard megjavítani.
-
-
-
bambano
titán
-
-
bambano
titán
válasz
#78522999
#34156
üzenetére
ja, ha mindenféle webes admin felületnek látszó hibahalmazt raksz fel a gépedre, akkor ne csodálkozz, hogy 20 percet se bír ki...
egyébként a dns szervert szokták még megborítani, ha van fent olyanod, szedd le vagy állítsd be rendesen.
lehet még olyan ok is a döglődésben, hogy a vps szolgáltató tűzfala már felfigyelt a gondjaidra, ezért lassítja a hozzáférést. velük is beszélned kellene.
-
bambano
titán
válasz
urandom0
#34153
üzenetére
ha rootként van bent, akkor ami azon a gépen van, az kuka, a komplett gép kompromittálódott.
nyilván hozzáfér az adott gépen levő privát kulcsodhoz is, ahogy leírtam az előző hsz-emben.ha nem követted el azt az orbitális hibát, hogy másolgatod a kulcsaidat mindenféle gépre, akkor ez nem olyan nagy probléma. ha ugyanazt a kulcspárt használtad egy rakás gépről, akkor bajban vagy
-
bambano
titán
válasz
urandom0
#34148
üzenetére
vajon hogyan lopja el a privát kulcsodat, ha azt soha, semmilyen körülmények között sem adod ki a kezedből? oké, a feltört rendszeren levő kulcsaidat ellophatja, de itt arról van szó, hogy aki távolról be akar jelentkezni a feltört gépre, azzal lesz baj. ha be akarsz jelentkezni a feltört gépre, akkor sem adod ki a sajátodról a saját privát kulcsodat.
-
bambano
titán
válasz
urandom0
#34143
üzenetére
ez így a nemlétező esemény. hogy sebezhetőség van az openssh szerverben, azt ki tudta lőni, de a 22-es portra nem tud rábindelni, annak nulla az esélye. a credentials lopásnak meg azért nincs értelme ebben az elképzelt felállásban, mert ha a jogosult user tudja, hogy nem a 22-es portra tette az ssh-t, akkor nem fog a 22-es porton próbálkozni, tehát nem fog legális azonosító adatokat kapni ott, aki meg a 22-es porton próbálkozik, az fake.
ha elköltöztetted az ssh-t a 22-es portról, akkor egy rakás cpu-t megspórolsz, amit a fail2ban elhasználna.
-
#34108
bambano
titán
lionhearted
#34107
bambano
titán
válasz
lionhearted
#34107
üzenetére
unixon a diszk partíció egy hatalmas blobb...
-
#34102
bambano
titán
lionhearted
#34101
bambano
titán
válasz
lionhearted
#34101
üzenetére
"Nem tudom ki hol találkozott enterprise-szal,": otthonra kell neki nas. nem enterspájz hiperkonvergált vállalati ócskavastelep
-
bambano
titán
szerintem mindent, ami állandó, és nincs túl nagy igény a biztonsági szeparációra, azt egy helyre kell tenni.
veszed a vasat, ráraksz egy alap debiant, és azon összedrótozod a kvm hostot meg a nast.egyébként meg az is kérdés, hogy neked mi az, hogy nas? nekem a nas az egy nfs szerver és pont. nincs mit virtualizálni rajta. ha guesteket akarsz rátenni, akkor lvm2.
Szerintem nem kell túlbonyolítani semmit, fájlrendszer az ext4 és jónapot. Arra kell figyelni, hogy alap beállítással kvm-et ne rakj raid1-re.
-
bambano
titán
-
bambano
titán
hogy rotálod a bináris logokat? eldobálsz fájlokat, nem?
a jobb syslogd-knek meg lehet adni, hogy milyen nevű fájlba logoljon. hogy a gép nevét bele lehet-e rakni a logfájl nevébe, azt még nem próbáltam. hogy dátumot bele lehet-e, tetszőleges formátumban, azt igen, működik. simán tudsz csinálni/var/log/%Y/%m/%d/syslog
nevű fájlt. nem kell rajta rotálni semmit, max. ráteszel egy linket a hagyományos helyéről.
-
bambano
titán
nem nekem van elképzelésem a unixról, hanem az alkotóinak. és a teljes rendszert ahhoz igazították. az, hogy csővezeték van, olyan parancssori cuccok vannak, amilyenek, az átirányítás meg a file descriptorok rendszere, mind azt mutatja, hogy szöveges feldolgozásra optimalizálták a kernelt. minden más elhajlás. jelen esetben indokolatlan és helytelen.
ha az operációs rendszer nem felel meg az eredeti, alapvető tervezési filozófiájának, akkor katyvasz lesz belőle. lásd még: m$
majd meglátjuk, hogy a dinamikus dns konfiguráció a fontos-e vagy a jogszabály. mellesleg most is dinamikus a konfig, a dhcp kliens átírja a resolv.conf-ot.
-
bambano
titán
Oké, menjünk éttermi hasonlattal.
Régen volt mindenféle étterem, majd jött a maffia, mindet erőszakkal átvette, és azóta mind vegán étterem. De az ételt mindig elsózzák és kozmás.Tehát ne csak azt az állításomat figyeld, hogy a unix filozófiájának nem felel meg a systemd, hanem azt is, hogy egyébként a systemd jelenlegi állapotában egy bughalom.
Más: az előbb jutott eszembe, míg szűkös magányomban agyaltam (
), hogy a legújabb gyerekvédelmi szabály(tervezet) fényében a systemd-resolvd nem törvénysértő?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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Milyen légkondit a lakásba?
- GL.iNet Flint 2 (GL-MT6000) router
- Automobilista 2
- Pánikban a világ a Radeon RX 5000 és 6000 sorozat támogatása miatt
- AMD Catalyst™ driverek topikja
- TCL LCD és LED TV-k
- OLED TV topic
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Apple MacBook
- 5.1, 7.1 és gamer fejhallgatók
- További aktív témák...
- BESZÁMÍTÁS! GIGABYTE B250M i5 7400 16GB DDR4 512GB SSD RX Vega 64 8GB DEEPCOOL Tesseract BF 650W
- Újszerű! HP EliteBook 840 G7 i5-10210U 16GB 512GB FHD 400nit 1 év garancia
- 153 - Lenovo LOQ (15IRX9) - Intel Core i5-13450HX, RTX 4060
- Nagyakkus! Dell Latitude 5430 i7-1255U 16GB 512GB 14" FHD 1 év garancia
- HIBÁTLAN iPhone 13 512GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3273, 100% Akkumulátor
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: Promenade Publishing House Kft.
Város: Budapest