- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- Honor 200 Pro - mobilportré
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Samsung Galaxy Watch7 - kötelező kör
- Samsung Galaxy A53 5G - kevesebbet többért
- Netfone
- Poco F6 5G - Turbó Rudi
- Samsung Galaxy A54 - türelemjáték
- Milyen okostelefont vegyek?
- Android alkalmazások - szoftver kibeszélő topik
-
Mobilarena
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
-
ivivan
tag
Hát szerintem ez reménytelen. Persze függ attól is, hogy mekkora a vinyó és mit csináltál vele a Debian telepítésen kívül? És persze, hogy mi mindent raktár fel, mert ha mondjuk 50%ig tele van már a vinyó, akkor reménytelen...
ui: ki az, aki 2010-ben Fat32-n adatot tárol?
-
ivivan
tag
válasz
bambano
#9154
üzenetére
Nem csak szerinted, hanem valóban tud konzisztens állapotot menteni már évek óta, és elvileg a mysqldump is konzisztens állapotot ment, ha a tábla tárolási metódusa ismeri a tranzakciót (mondjuk InnoDB), de az igazat megvallva, ezt még nem próbáltam: olyan esetekben, amikor fontos a konzisztencia mindig Postgrest használok.
-
#9106
ivivan
tag
macskajancsi
#9105
ivivan
tag
válasz
macskajancsi
#9105
üzenetére
Ennél sokkal nagyobb fájllal próbáld ki szerintem, mert ezt okozhatja még a RAMba írás, 10-20GB-os fájl szerintem már megteszi...
ivivan -
ivivan
tag
válasz
bambano
#9062
üzenetére
"Azt elég bátor lenne kijelenteni, hogy más módon nem hekkelhető a rendszer..."
Nem mondtam, hogy másképp nem hackelhető, csak azt, hogy most nem így hackelték...
"Pár napja azt írtad, hogy az egész cucc meghaladja a képességeidet"
Most is ezt mondom, de nem tolonganak a jelentkezők, akik karbantartanák...
"Ha valami táphiba vagy tűz miatt megáll a cucc, akkor viszi a vinyót is a diszkrétre..."
Hát a tűz és egyéb elemi kár valóban necces, de szerintem a táphiba nem árt a külső vinyónak, hiszen annak saját tápja van. Bár eddig még egy tápom sem robbant le úgy, hogy volt rajta külső vinyó, így nem tudom, hogy ártana-e neki...
Jelenleg a mentés ugyanarra a vinyóra történik, amit mentünk. Annál azért többet érne a külső vinyó :-) -
ivivan
tag
válasz
bambano
#9050
üzenetére
"De nem marad ugyanaz, mert először a web szerveren levő cuccok segítségével megtörnek egy mezei accountot"
Hát én most azt olvastam, hogy nem törnek meg accountot, csak egyes apache szálakat függetlenítenek az apache-tól, és ha pechedre éppen azt a szálat kapod a pool-ból, akkor vírust kapsz vissza.
"Mindezt természetesen felügyelet nélkül"
Ez biztosan meghaladja a képességeimet, ezért inkább nem rontom el vele...
"Az se lenne baj persze, ha sok meghajtón lenne a diszkterület"
Ebben a szerverben max 4 vinyó fér el és jelenleg ez a 4x250G egybe van szedve egy RAID5 vinyóvá (ami valamiért még 700G sincs, nem értem miért...), így nincs lehetőség még egy vinyót belerakni, pedig jó lenne. Most backup-ra tervezünk hozzá venni egy külső USB vinyót, de az nyilván nem lenne elég gyors ahhoz, hogy másra is használjuk...
-
ivivan
tag
válasz
bambano
#9046
üzenetére
"Ehhez kell másik gép és pxe"
Azt nem értem, hogy mit érek el egy gyors újrarakással, ha az adatok - azaz azok, amik a hibát okozzák - ugyanazok maradnak?
Egyébként ez a pxe hogyan működik? Ennél célszerűbb lenne egy teljes image-t csinálni a vinyóról és azt visszatölteni, ha gond van, mert az exim-et vagy 3 napig lőttem be, hogy jó legyen és a levlisták még mindig nem mennek... Szóval lehet, hogy villámgyorsan van egy alap Debianom, de utána napokig állítanám be..."előfordulhat, hogy megállnak azok a cuccok, amik arra a partícióra akarnak írni"
Ez igaz, de kisebb valószínűséggel telik meg egy db több száz gigás partíció, mint 4-5 20-30 gigás. A mostani szerverünkön van még 200G szabad hely, amit azért loggal teleírni bazi sokáig tart, annyi idő alatt csak kiszúrjuk (remélem)
A latex-hez ezt találtam: http://amath.colorado.edu/documentation/LaTeX/reference/faq/a4.html
Valahogy ott is meg lehet adni a lapméretet, de kb 5 éve latex-eztem utoljára, úgyhogy már nem emlékszem :-) -
ivivan
tag
válasz
bambano
#9039
üzenetére
"kell lenni időpontnak, amikor lemountolhatsz egy fájlrendszert és átméretezheted"
Hát történetesen az egy cégnél lévő szerver, ahova ugye hétvégén nem nagyon tudok bejutni, hétköznap meg használják és nem lehet leállítani, ezért nem lett átméretezve, inkább symlinkek halmazával oldottam meg a problémát. Viszont ebből azt a következtetést vontam le, hogy az lvm nem oldja meg a problémát úgy, hogy 200km-re vagyok a szervertől, ezért lett egyetlen partíció, bár olvastam olyat is, hogy reiserfs-t át lehet méretezni menet közben is, de nem akartam vele kísérletezni.
"A pxe arra lenne jó, hogy hálózatról újra lehessen rakni a debiant."
Aha, hát ezt nem értem :-)
"A dellben távoli szervizprocesszor van?"
A nagyokban igen, de sajnos abban, ami nekünk van én úgy tudom, hogy nincs.
-
ivivan
tag
válasz
bambano
#9037
üzenetére
"Arra, hogy ne teljen be egy partíció, ext3-as fájlrendszer és lvm való."
Van ilyen gépem. Sajnos ebből is csak baj van, mert van 40G ki nem osztott hely, amit nem tudok újraosztani, mivel menet közben nem lehet ext3-at növelni, viszont lemountolni sem tudom menet közben és csak ezért nem akarok hétvégén Pestre menni...
Pont emiatt a rossz példa miatt nem lett lvm, pedig egy rendszergazda ismerős nagyon rá akart beszélni."pxe-t tud a hálókártyád?"
Mi az a pxe? A szerver egy sima DELL szerver, nem tudom, hogy azoknak az integrált hálókártyája mit tud.
"van kéznél tartalék gép?"
Ott a régi gép, amit lecseréltünk a mostanira, de mire megyek vele?
-
ivivan
tag
válasz
bambano
#9035
üzenetére
"ugye azóta külön fájlrendszerre került a /tmp és a /var/www is, nodev,nosuid,noexec-cel mountolva? (értelemszerűen ha eddig nem így lett volna.)"
Nyilván nem. Menetközben ezt aligha tudnám megtenni. Igazából nem menetközben sem tudom, hogyan kellene...
És nem is értem, hogy miért jók ezek a szétbontások. Eddig mindig csak problémám volt a szanaszéjjel particionált vinyókból, mert az egyik partíción mindig elfogyott a hely, míg a többin szabad hely hegyek voltak...
Ezért ezen a gépen szándékosan egyetlen partíció van, hogy ne legyen gond abból, ha esetleg a szerver telepítésekor rosszul becsülöm fel, hogy melyik partíciónak mekkora hely kell."ugye azóta lekerült a setuid bit a mountról"
Most levettem, de nem értem, hogy ez milyen problémát okozhatott?
-
ivivan
tag
Úgy tűnik megtaláltam a hiba forrását! Legalábbis az elmúlt 24 órában egyetlen vírusos választ sem kaptam.
A megoldás annyi volt, hogy rákerestem a "base64_decode" függvényre a /var/www könyvtárban és egyesével átnéztem a több száz találatot.
Viszont ebből következik, hogy a gép újratelepítése semmit nem ért volna!
-
ivivan
tag
válasz
bambano
#9018
üzenetére
Nem kétfelé, sokfelé szoktam a vinyót particionálni, minden külön partícióra kerül, ami menet közben üzemszerűen növekszik és ha valami megszalad, elszedheti mástól a helyet
De ez így nem különbözik az én egybeformázott verziómtól, csak nyilván lassabb, nem?
A teljes vinyót, minden bitjét legyalulnám nullára, sosem tudhatod, hova dugta a lomját.
Akkor a két nap elég sem lenne, lévén cirka 500G adat van a szerveren jelenleg (csak adatbázisból 200nál is több)
és egyébként is local root exploitos a kerneled
Remélem nem az, ezért frissítem rendszeresen a Debian-t.
És erősen fontold meg a virtualizációt
Az már sajnos meghaladja képességeimet. Lehet, hogy ki kellene adni alvállalkozónak a szerver karbantartását, csak akkor az a kis haszon is elveszne, ami eddig volt rajta...
-
ivivan
tag
Ilyenkor csak újrahúz, frissít, kész. max 2 óra.
Nem igazán vágom hogy gondolod. Gondolom kétfelé particionálnád a vinyót: egy rendszer és egy többi részre és a rendszer partíciót húznád újra. De miből gondolod, hogy az, aki feltörte oda rakta a dolgait? Többnyire a /var/... vagy a /home/... tudnak írni az ilyen esetben, amit viszont a te módszereddel nem cserélnél le...
Mi van azzal a tűzfallal? Legalább valami hardveres akármi van előtte?
Egy ici-pici iptables alapú izét raktam rá, kb 10 sor, de ezenkívül semmi. És most elbizonytalanodtam, hogy egyáltalán boot közben lefut-e az a script!
-
ivivan
tag
-
ivivan
tag
válasz
bambano
#9011
üzenetére
Kösz, ezt az apt-get reinstall dolgot kipróbálom egy nem életfontosságú gépen (valszeg egy virtuális gépen)
A jótanács a teljes gyalu és újratelepítés (ami nem tudom, miért tart 2 napig)
Mert béna vagyok, mivel főállásban programozó vagyok és nem rendszergazda (programozónak jobb vagyok :-) )
de ha ez nem megy, akkor live cd-ről bootolva chrootolva újrarakni minden binárist
Ez meg nekem nagyon bonyesznek tűnik...
Még olyan kérdésem van, hogyha egyszer valahogy kiírtom ezt a galibát, akkor hogyan tudom megakadályozni, hogy újra bekapjak egyet?
-
-
ivivan
tag
válasz
bambano
#9005
üzenetére
A tesztelt domain tiszta, megnéztem, direkt azért választottam ezt.
Ezért gondolom, hogy a probléma nem weboldal, hanem webszerver szintű, tehát az egész gépet feltörték, de nem tudom hogyan tudnám ezt leellenőrizni (a chkrootkit-et ismerem csak, de az semmit nem talál) -
ivivan
tag
Sziasztok
Többször írtam már itt a fehér képernyőről, de sajnos eddig minden segítség hiábavaló volt, mert nem találtuk meg a hibát.
Viszont most új fejlemény jelentkezett, ami teljesen megváltoztatja a dolgok állását!Írtam egy egyszerű "scriptet", ami az egyik weboldalunkat percenként letölti, hogy én is lássam, mennyi is a 0 byte-os fájlok aránya. Nem várt eredményt kaptam: nem 0 byte-os fájlokat kaptam, hanem 10-15k-s vírusos oldalakra mutató linkekkel tömött html-t!
A konklúzió egyszerű: a szervert feltörték és valami nem olyan, mint kellene. Az a kérdésem, hogy hol és hogyan találhatom meg a fertőzést és hogyan tudom kiírtani?
És hogyan akadályozhatom meg, hogy még egyszer feltörjék?
ui: a szerveren a legfrissebb Debian lenny van
-
ivivan
tag
válasz
bambano
#8945
üzenetére
Biztos emlékszel még a régi Apache problémámra, miszerint néha fehér képernyőt ad vissza.
No azóta volt egy Apache frissítés, amitől a segmentation fault-ok eltűntek a logból, ennek ellenére néha - most már kicsit ritkábban - kapunk fehér képernyőt a kérésre, de most már úgy néz ki, mintha a hibák főleg a csúcsidőre - amikor másodpercenként 8-10 kérést kap a szerver - korlátozódnának.
Ezért gondoltam, hogy esetleg a rengeteg megnyitott fájl okozhat gondot... Ráadásul megnéztem és a vmstat szerint másodpercenként 500-1000kbyte írás olvasás van folyamatosan a szerveren, amit én - más ötlet híján - a logok írására-olvasására fogok. -
ivivan
tag
Sziasztok
Megint lenne egy nem olyan egyszerű kérdésem apache-al kapcsolatban.
Van egy Debian szerverünk, amin cirka 400 domain webje és levelezése fut. Az apache simán vhost-al van bekonfolva, jelenleg úgy, hogy minden vhost-nak saját access és error logja van.
A probléma az, hogy csúcsidőben akár 50 ezer fájlt is megnyitva tart a log könyvtárban az apache, amit én egy kicsit sokallok (a log könyvtárban összesen 702 fájl van, mert sok domain ugyanabba a logba ír)
Hogyan lehetne elérni, hogy kevesebb fájlt tartson megnyitva? Mondjuk minden fájlt csak egyszer? -
ivivan
tag
Visszatérve erre:
Amúgy azt tudja valaki, hogy miért nem látja a Linux soha a teljes fizikai memóriát? Például a szerverben van 6G, azaz 6*1024*1024 = 6 291 456 kB RAM, ezzel szemben a Linux 6 131 844 kB memóriát lát. Hol van a többi?
Itt még nem is nagy a gond, a "veszteség" 2,5% körül van, de van egy ici-pici szerverecském itthon, ahol a 32M=32 768 kB RAMból a Linux csak 29 288 kB-ot lát a Linux, itt már majdnem 11% a "veszteség" és bizony jól jönne az a 3M plusz :-) -
#8737
ivivan
tag
Speeedfire
#8736
ivivan
tag
válasz
Speeedfire
#8736
üzenetére
Hát 633as Celeron messze nem lesz elég a DVD lejátszáshoz szerintem.
Amúgy a TVout-ra ki lehet irányítani a rendes képet (sőt kell is, ha videót akarsz rajta nézni) és akkor nem kell bonyolultkodni a konzollal... -
#8724
ivivan
tag
Speeedfire
#8723
ivivan
tag
válasz
Speeedfire
#8723
üzenetére
Nem az "m" betűt kell megnyomni, hanem az "M" betűt, azaz SHIFT-m és akkor memória használat szerint sorba rendezi.
Egyébként nincs ezzel semmi baj: van 33M szabad memóriád és 377M cache (az Linux alatt mindig akkora, amekkora szabad memóriád van :-) Legalábbis nekem nem sikerült még lekorlátozni valami épelméjű szintre)
Amúgy azt tudja valaki, hogy miért nem látja a Linux soha a teljes fizikai memóriát? Például a szerverben van 6G, azaz 6*1024*1024 = 6 291 456 kB RAM, ezzel szemben a Linux 6 131 844 kB memóriát lát. Hol van a többi?
-
ivivan
tag
Sziasztok
Kicsit zavarban vagyok, mert ilyet még nem láttam. A munin-ban a verzió váltás óta (etch->lenny) nem megy a exim_mailstats plugin és ma rászántam magam végre, hogy megnézem mi baja van.
A problémát a következőképpen tudom összefoglalni:new:/home/ivivan# sudo -u munin cat /var/log/exim4/mainlog
cat: /var/log/exim4/mainlog: Hozzáférés megtagadva
new:/home/ivivan# ls -la /var/log/exim4/mainlog
-rwxrwxrwx 1 Debian-exim Debian-exim 3091884 okt 26 16.22 /var/log/exim4/mainlogTehát a mindenki által olvasható, írható, bármit csinálható fájlt a munin felhasználó nem tudja olvasni. Nincs ötletem. Valaki tud segíteni?
ivivan
-
-
ivivan
tag
válasz
bambano
#8584
üzenetére
Hát most egy nagyon paraszt megoldással kikerülöm a problémát: minden reggel 5kor újraindítom az apache-ot cron-ból. Estig általában kibírja...
Remélem hamar lesz apache és php frissítés lenny-ben és az talán megoldja...
És közben ha járok Pesten, akkor nézek egy memtest-et is.ivivan
-
-
ivivan
tag
válasz
bambano
#8578
üzenetére
Hát elvileg marha drága CRC-s RAM van a DELL szerverben, csak nem hibás...
Ha már így a hibás működés szóbakerült, akkor még egy kérdésem lenne: ez egy DELL szerver, hardveres RAID vezérlővel, 3db SATA vinyóval RAID5-ben. Az a kérdésem hogy honnan tudhatom meg, hogyha az egyik vinyó esetlen elromlik?
-
ivivan
tag
válasz
bambano
#8575
üzenetére
Nekem sem, de a tünet hajszálra ez: megtaláltam végre, hogy hova logolja a sok vhost mellett a segfaultokat és bőséges a termés :-(
Egyébként nekem 5.2.6.dfsg.1-1+lenny3 PHP és 2.2.9-10+lenny4 apache van.
Nem tudom, hogy ez ugyanaz a bug-e, vagy csak az eredmény ennyire hasonló, de mindenesetre érdekes véletlen lenne, mert a jelenség éppen a lenny-re való frissítés óta jelentkezik (dist-upgrade volt az előző stable-ről, aminek már nem emlékszem a nevére) -
ivivan
tag
válasz
zoltanz
#8527
üzenetére
Lehet, hogy nem mindenki viszi vissza a freedosos laptopot, de szerintem nyugodtan kijelenthetjük, hogy gyakorlatilag senki nem használ freedossal laptopot, de egyébként a Linuxosról volt szó.
És tapasztalatból mondom, hogy egy-két fanatikus Linuxoson kívül mindenki Windowst használ a laptopon. Mondom ezt úgy, hogy én magam is programozó vagyok és a környezetemben is többségében vannak a programozók.
Mégis, mindössze egyetlen embert ismerek, akinek régen Linux volt a laptopján (Gentoo, hardcore user volt :-) ), de már Ő is Windowst használ a laptopon, mert megunta a Linuxos játszadozást :-)De hogy ON is legyek egy kicsit: ki tud valami jó levlista kezelőt Debian és exim4 alá? Olyan kellene, ami több domaint is tud kezelni.
-
ivivan
tag
válasz
bambano
#8472
üzenetére
Megnéztem a logokat: éjjel fél 12kor volt az utolsó 0 byte, azóta nem, de azóta nem változtattam semmit rajta, szóval ha akkor lehetett ilyen gond, akkor az még lehet most is, csak most pihen a hiba :-)
Egyébként ezt is megfigyeltem már, hogy a hiba nem egyenletes: egy sűrűbb, problémásabb 3-4 nap után "pihen egy kicsit", de aztán újra előjön néhány hét múlva...
Ráadásul most erre a szerverre pakolok még át domaineket, szóval a terheltsége még nőni fog, talán ettől a hiba előfordulása is. Úgy talán könnyebb lesz tetten érni... -
ivivan
tag
válasz
bambano
#8468
üzenetére
Nah, közben erre rájöttem :-)
Van egy oldal, amin - valamiért - errorhandler-el van megcsinálva, hogy az oldal rövidlinkes legyen (szóval ne az id=1231 látszon) és ez most úgy irányította át, hogy az error handler után is hibát okozott, ami miatt megint betöltötte az oldalt, megint hibát okozott és megint...
Szóval végtelen ciklus rulez, de legalább megvan a hiba! -
ivivan
tag
válasz
bambano
#8466
üzenetére
egyszer már belinkeltem a munin grafikont: normál használat mellett ritkán megy 100 fölé az apache processek száma, tehát nem elfogy, hanem valamiért beragadnak a szálak (most is a beragadás előtt 30-40 szál dolgozott)
Azért felemelem, mert 110-120 körül van a max, ami már közel van a limithez, de ez szerintem nem fogja megoldani a problémát, csak több szál fog beragadni! -
ivivan
tag
Na, eddig volt jó. Most megint azt csinálja, hogy az összes 150 worker thread foglalt, de ez lehet, hogy nem ugyanaz a probléma. Mindenesetre a http://127.0.0.1/server-status?auto-re (sok idő múlva) ezt kapom:
Total Accesses: 150559
Total kBytes: 5219117
CPULoad: 1.14544
Uptime: 50762
ReqPerSec: 2.96598
BytesPerSec: 105283
BytesPerReq: 35496.9
BusyWorkers: 150
IdleWorkers: 0Ötlet?
-
ivivan
tag
válasz
bambano
#8459
üzenetére
Most beírtam a végére, hogy:
www-data hard nofile 100000
www-data soft nofile 100000
ivivan hard nofile 100000
ivivan soft nofile 100000De ivivanként még mindig:
ivivan@new:~$ ulimit -n 16384
bash: ulimit: open files: cannot modify limit: A művelet nem engedettValamit újra kell indítani, hogy érvényesüljön?
-
ivivan
tag
válasz
bambano
#8455
üzenetére
Benne van a /etc/profile-ban:
ivivan@new:~$ cat /etc/profile
# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...)....
export PATH
umask 022
ulimit -n 16384
És a sysctl.conf-ban is:
ivivan@new:~$ cat /etc/sysctl.conf
...
# Maximum file descriptor
fs.file-max = 331287 -
ivivan
tag
Ha már ilyen jól megoldottuk az előző problémát (legalábbis most jól működik) lenne még egy probléma ugyanezzel a szerverrel.
A probléma az, hogy sokan használják és nem lőhetem le a felhasználókat :-)
Szóval a probléma az, hogy a rengeteg domainhez van ftp hozzáférés és sajnos töltenek fel vírusos gépekről vírusokat a szerverre az ftp-n keresztül.
A szerveren fent van a clamav víruskereső, de most csak utólag lehet megkeresni a vírusokat, ráadásul eltávolítani kézzel kell, mert a clamav nem képes ilyenre.A kérdésem az, hogy nem-e lehetne, hogy a proftpd össze legyen kapcsolva a clamavval és feltöltés közben ellenőrizze és ha vírusos, akkor ne töltse fel? Keresgéltem a neten, és találtam egy mod_clamav nevű kiegészítőt proftpd-hez (http://www.thrallingpenguin.com/resources/mod_clamav.htm), de nincs ilyen csomag debianban és újra nem akarom fordítani a proftpd-t, mert akkor nagyon macerás lesz a későbbi frissítés. Más ötlet?
-
ivivan
tag
válasz
bambano
#8448
üzenetére
Jelenleg 79db kapcsolat van a 80as illetve 443as portra. De most néztem párszor: ez elég változó, néha 70 néha 140.
Munin van fent, de nem látom, hogy melyik lenne a 3 Apache közül: van egy, ami a másodpercenkénti kérések számát mutatja, egy ami az apache szálak számát és egy ami az apache által bonyolított adatforgalmat. Ezek közül szerintem egyik sem az, ami most minket érdekel... És nem is szokott a hiba esetén sem kiugróan magas lenni egyik sem.
-
ivivan
tag
válasz
bambano
#8444
üzenetére
"Először a globális descriptor limitet kell feltolni, szerintem akár 1 millióra is, utána a /etc/profile-ba írt ulimit-tel a per processz limitet."
Elvileg átállítottam 16384-re.
"A df -i megmondja, összesen hány inode van a fájlrendszerben, ha a 160 ezer ehhez közel jár, akkor bajban vagy
"Közben rájöttem, hogy rájöttem, hogy ez:
new:/home/ivivan# df -i
Fájlrendszer Inode-ok IFogl. ISzab. IFo.% Csatl. pont
/dev/sda1 0 0 0 - /azért lehet nálam, mert reiserfs-t használok, amiben ugye nincsenek inode-ok (ha jól tudom)
Most várunk, kíváncsi leszek, hogy a változtatások most érnek-e valamit...
-
ivivan
tag
válasz
bambano
#8442
üzenetére
"hány file descriptort tud megnyitni a gép"
Ezt hogy lehet megnézni?
"ulimit -n kimenetet kérdeztem már?"
new:/home/ivivan# ulimit -n
1024"hogy a diszkre fér-e még file"
Bőven fér most, de ugye letöröltük a 160 ezer fájlt... De most 1%ot ír ki a df -i, csak nem lenne 160 ezer fájltól 100%? -
ivivan
tag
válasz
bambano
#8440
üzenetére
Konkrétan 0 byte-os fájlt szed le. Most csináltam egy bazi egyszerű scriptet, ami 3 percenként leszedi a "veta.hu" címet (ez egy nálunk lévő domain) wget-el. 100x 7144 byte, egyszer 0.
Tűzfal nincs rajta, még iptables alapú sem (a múltkor leszedtem és még nem raktam rá újat)Most egy olyan jutott eszünkbe, hogy van egy Mage alapú weboldalunk, ami saját session kezelést használ (miért nem jó neki a sima? Na mindegy) és ezek a session-ök ott maradnak. Most töröltük le: 160 ezer fájl fölött járt már... Ettől történhet ilyen?
-
ivivan
tag
Sziasztok
Most megint visszatérnék a már régen említett problémára hátha valakinek most van legalább ötlete, hogy merre induljak el.
Van egy debian szerverünk, aminél a tünet a következő: az Apache (2.2.9-10+lenny2) időnként (becsléseink szerint kb minden 100. kérésre) 0 byte-os fájlal válaszol, ami többnyire üres képernyőt jelent, de alkalmanként a CSS-t vagy egyes képeket nem ad vissza. A probléma szinte biztosan az Apache-al van, mert a munin apache része is meg-megszakad néha.
Először az e-accelerátorra gyanakodtam (ez az egyetlen nem csomagból felrakott izé), de kipróbáltam, hogyha nem töltöm be az e-accelerátort, akkor is produkálja.Valakinek valami ötlete, hogy mit nézzek meg? Hol lehet a hiba?
ivivan
-
ivivan
tag
Ebben nem vagyok nagyon penge, de a 600as jog annyit tesz, hogy a fájl tulajdonosának írási és olvasási jogai vannak, senki másnak semmi.
Ebből egyenesen következik szerintem, hogy a kérdésedre a válasz "nem".
Ehhez 660as jog kell és egy csoportba kell lennie a két felhasználónak. -
ivivan
tag
válasz
zoltanz
#8195
üzenetére
Ezt jó ideje nem frissítik, nem hiszem, hogy ez nyerő lenne... (2007-es a weboldal utolsó frissítése és "Athene 2005 CD"-nek nevezik) Még OO 1.1.4 van benne, pedig már a 3.1-nél tartanak.
Viszont jó lenne egy hasonló kezdeményezés, ami végre tényleg megkavarná a Linux állóvizét, de szerintem fizetősen nem tudják megverni a Windowst! -
ivivan
tag
Hmmm... De akkor nem értem, hogy miért csak a mi oldalainknál? Más oldalakon még soha nem tapasztaltam, de a mienknél néha valóban előjön (és olyankor az apache "szaggat", amit visszább már írtam, de senkinek nem volt ötlete)
De azért holnap megnézem az fprot-ot, hátha... Soha nem lehet tudni!
-
ivivan
tag
válasz
bambano
#8190
üzenetére
Erre mi is gondoltunk. Volt is már több ilyen is, hogy a feltöltő gépe vírusos volt és onnan került vírus rá.
De történetesen van egy oldal, ami a sajátunk és évek óta nem volt feltöltve rá semmi. Még ftp hozzáférés sincs hozzá!
És ha lenne is, akkor is konstans lenne egy ilyen hiba: ha van redirect a html-ben, akkor az mindig benne lenne, egy F5 nem javítaná meg! -
ivivan
tag
válasz
bambano
#8188
üzenetére
Perszehogy vírusos a neborin.info! Pont az a kérdés, hogy miért dob át arra az oldalra!
Kb 2 tucatnyian jelezték már a problémát és a céges gépeken is előfordul, pedig van vírusírtó minden gépen és programozók ülnek a gépek előtt, akik nem töltenek le akármit, szóval elég biztos vagyok benne, hogy a probléma szerver oldali.
Persze lehet, hogy kliens oldali, de akkor minden gépünk és csomó különböző ügyfél gépe egyformán vírusos, amit én elég hihetetlennek találok... -
ivivan
tag
Sziasztok
Volna egy érdekes kérdésem, mert ilyet még nem láttam és teljesen tanácstalanok vagyunk...
Szóval van egy sok domaines (200+ domain) Debian szerverünk, amin most a következő jelenség jön elő: időnként - teljesen random módon - egyes domaineket vírusriasztással állít meg a kliens vírusírtója, de egy F5 után az oldal hiba nélkül bejön. Ezen a képen látható egy ilyen riasztás:
Úgy néz ki, mintha át akarná irányítani az oldalt egy másik weboldalra. A szerveren van clamav vírusírtó, amivel éjszakánként a teljes /var/www könyvtárat átellenőriztetem, a jelentés szerint a szerver tiszta.
Egyelőre az apache-ra vagy az e-acceleratorra gyanakszunk, mert egy apache restart megoldja a problémát rövidebb-hosszabb időre.
Bárkinek valami ötlet? -
ivivan
tag
válasz
#41635072
#8159
üzenetére
Hát először egy 128as RAMal próbálkozz, az szinte biztos bele megy...
És miért nem jó a Win98, ha már az megy rajta? Le kellene valami hasonló korú Linuxot szedned, de fogalmam sincs, hogy olyat hol találsz?
És a RAM is biztos segít, azzal talán egy pár évvel fiatalabb Linux is eldöcögne rajta... -
ivivan
tag
válasz
#41635072
#8155
üzenetére
A nagyobb órajelű RAMok elvileg lejjebb butulnak, de ki kell próbálni. Inkább az lehet a bukta, hogy ezek az ős lapok általában csak egy oldalas SD-ket fogadtak, na olyan most lámpással se találsz, ezért ha szerzel valahonnan egy 128ast, akkor abból nagy eséllyel csak 64et fog látni...
Egyébként mit akarsz egy ilyen őskövülettel? Ugye nem gondolod, hogy Win95nél komolyabb izé rámegy? (esetleg ha nem raksz X-et rá, akkor talán valami minimális Linux, de az se fog suhogni)
-
ivivan
tag
Már nem használok desktop Linuxot, ezért nem tudom kipróbálni és akárhogy töröm a fejem sehol nincs két szerverünk egymás mellett úgy, hogy Samba legyen rajta, ezért még ki se tudom próbálni, hogy az már megy-e...
Egyébként a KDE (asszem) ronda piros háttérrel jutalmazott, ha root-ként beléptem :-)
-
ivivan
tag
Hát én már megint fekete bárány vagyok: mindig root-ként lépek be Linuxra illetve ssh-n az első parancs a su (vagy sudo bash) (Sőt, még a screen-em is root-ként fut)
Egy ideig én is próbáltam paré júzer lenni, de valahogy mindig oda jutottam, hogy root jog kellett. Ugye nyilván ha valahova be ssh-zok, akkor azért megyek oda, mert csinálni akarok valamit (apache újra indítás, biztonsági mentés, logok megnézése stb) és biztos, hogy ezeket csak a root teheti meg, tehát vagy minden utasítás előtt sudo-t adok ki vagy simán root-ként tevékenykedem. Nekem az utóbbi egyszerűbb és nem látom nagy veszélyét a dolognak...
-
ivivan
tag
Szia
Milyen proci? A P3-asoknál 55-60 szokott lenni a max, a P4-eseknél meg elég változó 70-100-ig bármi leállíthatja...
Én Debianban még nem láttam ilyen vészleállító dolgot (sajnos), külön kellett nekem hackelni a régi szerveremre egy ilyet (nem volt rajta venti, hogy csendes legyen :-) )
ivivan -
ivivan
tag
válasz
ragazzo
#8070
üzenetére
Én inkább javaslom, hogy csak max fél tucat disztribúció legyen magyarul, de az tényleg rendesen le legyen fordítva! És akkor csak ezzel a néhány disztróval kellene foglalkozni...
Az igazat megvallva szerintem összesen is bőven elég lenne egy tucat distro: még szerintem népszerűbb is lenne tőle a Linux, mert most bármilyen kérdést tesz fel az ember, rögtön az a válasz, hogy: "Nem tudom, hogy az XXX distroban ezt hogy kell, de használj YYY distrot, mert abban így: ..." Kezdő koromban én is gyakran belefutottam ebbe, ezért álltam át végül Debiánra, mert annak elég széles a felhasználótábora ahhoz, hogy mindig tudjon valaki válaszolni.
-
ivivan
tag
Azt nézd meg, hogy mennyi szabad memória van és mennyire használja a swap-et (mondjuk egy konzolt indíts, aztán "vmstat 1" és kicsit használd a gépet, majd nézd meg, hogy mi van a swap oszlopokban, annak 0nak kell mindkét oszlopban lenni, ha nem az van, akkor kevés a RAM)
"
Új hozzászólás Aktív témák
Hirdetés
- Luck Dragon: Asszociációs játék. :)
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- Nintendo Switch 2
- Kerékpárosok, bringások ide!
- Eredeti játékok OFF topik
- Honor 200 Pro - mobilportré
- Béta iOS-t használók topikja
- Milyen TV-t vegyek?
- AliExpress tapasztalatok
- Vezetékes FÜLhallgatók
- További aktív témák...
- Antivírus szoftverek, VPN
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Apple iPhone 13 256GB Kártyafüggetlen, 1Év Garanciával
- Országosan a legjobb BANKMENTES részletfizetési konstrukció! Dell G15 5530
- LG 55C4 - 48" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - A9 Gen7 CPU
- Lenovo Thinkpad P1 gen1, gen2, P52s FHD, 4K oled touch
- Creative Sound BlasterX G5 (70SB170000000) (Sound Blaster) (DAC)
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest