- Google Pixel 8 Pro - mestersége(s) az intelligencia
- Garmin Forerunner 970 - fogd a pénzt, és fuss!
- QWERTY billentyűzet és másodlagos kijelző is lesz a Titan 2-ben
- Samsung Galaxy A56 - megbízható középszerűség
- Google Pixel topik
- A Galaxy Z Fold7, minden színben és oldalról
- Macrodroid
- Nem fogy a Galaxy S25 Edge?
- Fotók, videók mobillal
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
Új hozzászólás Aktív témák
-
mrots
tag
Most, hogy a CA/B Forum megallapodott arrol, hogy a jelenlegi maximum 398 napos TLS tanusitvany elettartam 2029-re 47 napra fog csokkenni (harom lepesben, elso lepeskent 200 napra csokken 2026 marciustol) elgondolkodtam, hogy a NASon levo tanusitvannyal mit csinaljak.
Nyilvan hagyhatnam a francba, elvegre szinte sosem kell a webes menedzsment feluletet hasznalni, szoval kit erdekel, ha egy ervenytelen tanusitvany uzenetet meg le is kell okezni az elejen. Ez egy valid opcio, noha nem elegans.
Ugyanezt az eredmenyt adna, ha self signed-ra cserelem, ami ezer evig jo, a bongeszok akkor is nyafogni fognak, hogy nem biztonsagos, megint csak le kell okezni egy ablakot, amibe nem halok bele.
Ki is kapcsolhatnam a https-t es csak hagyhatnam http-n, de mivel ipv6-on elerheto (nyilvan tuzfalon keresztul), nem szivesen kommunikalnek cleartext http-n az internet felett. Hanyszor kell tavolrol, internet felett elerni ipv6-on a menedzsment feluletet? Meg ritkabban, szoval akar ki is kapcsolhatnam. De igazabol ez sem az igazi.
Nyilvan a helyes megoldas a tanusitvany megujitas automatizalasa. Sajat PKI-t tartok, tehat a sajat CA irja ala az ilyen dolgok tanusitvanyait. Automatizalni a kulcsgeneralast, az alairast nem problema. Pontosabban nem ez a problema. Hanem a kesz tanusitvany importalasa a qnap-ba.
Az elegans megoldas egy API lenne vagy valamilyen mas felulet, amit a qnap nyilvan nem kinal. Nem neztem, nem kerestem utana, de az ilyen otthoni kommersz cuccok valoszinuleg nem tamogatnak API-t, szoval nem is keresek ilyen iranyba.
A tanusitvanyt amugy siman megtalalni a filerendszerben es be is tudom azonositani, hogy ez a tanusitvany valoban az, mint ami a https forgalomhoz hasznalva van:
[admin@nas ~]# openssl x509 -text -noout -in /etc/stunnel/stunnel.pem | grep SerialSerial Number: 79280529 (0x4b9b991)Jelenleg nincs jobb otletem, mint lescriptelni, hogy a legeneralt kulcsot es alairt tanusitvanyt egy file-ba helyezve SCP-vel egy script masolja fel a fenti helyere, felulirva a regit es inditsa ujra csak a https processzt, hogy a valtoztatas ervenyre is jusson (a NAS teljes ujrainditasa nyilvan nem opcio, mert diszruptiv a klienseknek).
Igazabol mukodik, egyszeru, de kicsit fapados. Valakinek van jobb otlete?
-
-
mrots
tag
Valoszinuleg rosszul fogalmazhattam, mert lathatoan nem ment at a lenyeg.
Nem arrol van szo, hogy melyik okoz nagyobb gyorsulast, mar a felvetes is teljesen ertelmetlen. A tenyek a kovetkezok:
- mindketto CPU csokkenest okoz, a titkositas kikapcsolasa is, meg a jumbo frame bekapcsolasa is, mivel mindketto azt eredmenyezi, hogy a CPU-nak kevesebb dolgot kell csinalnia, illetve ugyanazt kevesebbszer kell csinalnia
- az, hogy a titkositast kikapcsoltam, egy elfogadhato lepes egy vedett halozaton, de nem elfogadhato egy publikus halozaton, tehat ez a lepes nem mindig opcio mindenkinek
- a ketto nem vagy vagy, mint lathato, hanem egymastol fuggetlenek es kulon-kulon vagy egyutt is hasznalhatoak optimalizalasraA kerdes sosem az volt, hogy egyiket vagy masikat, hanem onnan indultunk, hogy szerinted a jumbo frame bekapcsolasa jelentektelen. Erre hoztam magyarazatot, hogy ez miert nincs igy, es egyebkent innen elkanyarodtunk, hogy a titkositas mennyivel jobban fogja meg a CPU-t, ha hasznalatban van. De ez nem minositi a jumbo frame-et.
-
mrots
tag
"Többet ér a CPU-t kevésbé terhelő beállítás, mint a Jumbo frame állítása"
Ez a mondat ket okbol sem igaz.1) mindket beallitas CPU-t kimeli, az egyik jobban, a masik kevesbe, de alapvetoen az eredmenye ugyanaz: kevesebb dolgot kell a CPU-nak csinalnia, tehat gyorsabb a masolas
2) Nem vonhatsz le kovetkeztetest abbol amit leirtam, mert eloszor lett jumbo frame es utana lett kikapcsolva a TLS az FTP szerveren. Ez utan meg ki kellett volna kapcsolni a jumbo frame-et, hogy lassam mennyi a befolyas a CPU-ra akkor, ha egyeb mas szuk keresztmetszetet kiiktattam. De mivel igazabol nem erdekel, ezert erre mar nem kerult sor.
"Mit szólnak hozzá, ha nyitsz rá egy hibajegyet, hogy az aposztrófos fájlnév újraindítja a NAS-t?"
Oszinten, nem annyira erdekel. Egyszerubb atnevezni / firmware -t downgrade-elni sem mint helpdeskkel vacakolni.A kodlap beallitas nalam is ugyanez.
-
mrots
tag
Hatha valakinek hasznos lesz ket aprosag. Az egyik: visszakanyarodok a sebesseghez. Gondoltam kiprobalom mennyit szamit a jumbo MTU. Beallitottam, igazabol semmit nem szamitott, tovabbra is kb 7000 kbyte/sec -cel masoltam ftp-n a helyi halozaton. Eloszor azt gondoltam, hogy jo, akkor nem szamit sokat. Aztan rajottem, hogy ezt ha atvaltom emberi mertekegysegre akkor kb 56 mbit/s sebesseg. Azert az picit lassu, valoszinuleg nem a jumbo frame miatt. De aztan gyerek furdetes, mese, stb, nem foglalkoztam vele, mignem masnap reggel bevillant, hogy az ftp tls-en keresztul fut a nason. Oszinten, szerintem mar elfelejtettem miert. Valoszinuleg azert, mert a csalad egyeb otthonaibol ha el akartam erni evekkel ez elott a nas-t akkor (mivel ipv6 van mindenhol) internet felett ertem el tavolrol a v6-os cimen at, nem pedig a lakasok kozott kihuzott VPN-en at (ha csak ipv4 lenne). Ez meg sok evvel ez elotti allapot, es kb 3-4 eve megcsinaltam, hogy minden lakasbol barmelyik masik lakasba ipv6 felett is a vpn-ben utazzon a forgalom. Igy a TLS-nek mar nem volt ertelme, de a ketto kozott eltelt par ev, nyilvan elfelejtettem, hogy TLS-en hagytam az ftp szervert. A sebesseg meg nem zavart senkit. Na, gondoltam akkor visszarakom plaintext-re. A nas-ra masolas sebessege hirtelen felugrott 56 mbit/s -rol nagyjabol 470-480 mbit/s -re ami szerintem mar elfogadhato a halozatban. Ennyit arrol, hogy az ember a jumbo frame-ekkel pocsoljon, vagy inkabb nezze at a beallitasait es dontse el, van-e ertelme mindegyiknek. Igy visszagondolva, valamikor 2018 kornyeken amikor megvettem a qnap nas-t kapasbol titkositott filerendszerre formaztam, aztan hamar kihatraltam ebbol amikor rajottem, hogy ez mekkora irasi es olvasasi sebesseget jelent izzado CPU mellett. Mivel az iment beszeltunk sebessegrol, gondoltam megosztom.
A masik erdekesseg, hogy kicsit a k.vaanyjat a qnap-nak, hogy megnehezitik az ember eletet. Tortent, hogy egy eleg regi, 1999-ben tv-ben adott sorozatot akartam felulirni. Ez egy het evados sorozat, az elso negy angolul a masodik harom magyarul van meg. Ez sokaig zavart de nem nagyon. Most nagyon zavarni kezdett ugyhogy kitalaltam, hogyan szerezzem meg eredetiben. Ez meg is tortent es gondoltam felmasolom a nas-ra a magyar nyelvu verzio helyere. Igenam, de osszekavarodtam, hogy melyik evad melyik epizodja mi (eredetiben s05 e01, a magyarban 132. resz). Gondoltam akkor kezdjuk el mar nezni ezt a 132-es reszt, hogy ugyanaz-e. Samban van kiajanlva es halozati meghajtokent felveve. Megkeresem, enter. Semmi. Varok. Varok. Sipolas a NAStol. Hmm. Nem is tudtam, hogy ez tud sipolni. Nem akkor sipol ha bootol? De. Nade miert bootol? Lenyeg a lenyeg, hogy valahanyszor el akartam volna inditani VLC-vel a lejatszast, a qnap elcrashelt. Persze utana file system check stb, szoval egy enter utan minden alkalommal egy 30 perces musor volt. Gondoltam talan sectorhibas a diszk es bizonyos file-ok olvasasa okozza. Akkor talan ideje lemezt cserelni? Elokerestem, hogy egyatalan mi van benne - lefotoztam a diszket mikor beleraktam. Apro erdekesseg, hogy 2017 december 16-an fotoztam a lemezt, szoval azota megy 7/24 ez a lila WD benne. 4TB-s, amugy is 90 giga van uresen, gondoltam akkor talan ideje beruhazni egy ujba, ha mar meg is telik es ugy tunik sectorhibas is.
Igaz, a tesztek nem mondtak semmit, a log se nagyon. Megneztem amazonon, 2 darab 6 TB diszk (mert ugye backup is kell, amire havonta mentest csinalok a nasrol) az durvan 120k magyar penzbe faj - igaz, holnapra kihozzak a lemezeket. Azert ez megis csak nagyobb osszeg, nezzuk meg azert, hogy biztosan hibas-e a lemez? Mivel a NAS nem bobeszedu (logokat neztem, semmi) gondoltam kiveszem a lemezt, berakom egy raspberry pi-be, felmountolom es eloidezem a problemat ugyanugy, lassam, a linux mit loggol le. Itt kezdodtek a nehezsegek.
Az egy dolog, hogy fel ev hijan nyolc eve nem volt kinyitva a NAS doboza, nem is emlekeztem hogy nyilik. TS128 egyebkent, szoval egy lemezes kis vacak. Jutub video kellett ahhoz is, hogy kinyissam - ez elmondja mennyiszer volt dolgom a nassal az elmult majdnem nyolc evben. Kivettem, jo poros minden, nyilvan - szekreny tetejen lakik egyebkent, gyerekek kezeitol messze. Dokkoloba lemez be es radugtam a pi-re. Az elso meglepetes, hogy volt rajta ot particio. Mi a fene. Jo, mindegy, biztos a sajat vackai vannak rajta - mint OS meg egyebek. Egyetlen particio van ami 3.6T, nylivan az kell nekem, de felmountolni nem lehet:
root@thermo-living:~# mount -t auto /dev/sda3 /contentmount: /content: unknown filesystem type 'linux_raid_member'.Mi a fene. Egy lemezes NAS, minek ide raid? Nyilvan azert, mert az osszes qnap termeken ugyanaz a szoftver fut, nem csinalnak kulon rendszert az egy lemezesre. Jovan akkor, legyen raid. Akkor ossze kene rakni a tombot valahogy es felmountolni ugy:
root@thermo-living:~# mdadm --examine /dev/sda3/dev/sda3:Magic : a92b4efcVersion : 1.0Feature Map : 0x0Oke, igy mar jutunk valahova, tenyleg raid van ott, meghozza raid 1. A timestamp szerint 2024 aprilisi letrehozassal - gondolom akkor frissitettem valami qnap firmware-t ami nem kototte az orromra, hogy mi a fenet csinal eppen, valoszinu akkor tertek at erre a megkozelitesre.
Akkor talan epitsunk egy array-t:
root@thermo-living:~# mdadm --assemble -v --name=1 /dev/md0 /dev/sda3mdadm: looking for devices for /dev/md0[...]mdadm: /dev/md0 has been started with 1 drive.Es valoban, most mar az mdstat is azt mondja, hogy van raid:
root@thermo-living:~# cat /proc/mdstatPersonalities : [raid1]md0 : active raid1 sda3[0]3897063616 blocks super 1.0 [1/1] [U]Az U-val nem kell foglalkozni, raid 1 van egy darab lemezzel - gondolom en. Nosza, mountoljuk akkor fel, de meg mindig nem sikerul:
root@thermo-living:~# mount -t auto /dev/md0 /contentmount: /content: unknown filesystem type 'LVM2_member'.Jaj de orulok, nem eleg, hogy egy primitiv egy lemezes nasban raid 1 van, de meg LVM is, hurra. Keressuk akkor meg mi a device amit mountolni kell:
root@thermo-living:~# lvscanACTIVE '/dev/vg288/lv544' [<37.28 GiB] inheritACTIVE '/dev/vg288/lv1' [3.59 TiB] inheritOke, akkor mountoljuk ezt fel, marmint nyilvan a 3.59 terasat:
root@thermo-living:~# mount -t auto /dev/vg288/lv1 /content -o roEs vegre ugy tunik celban vagyunk, ott van felmountolva:
root@thermo-living:~# mount | grep content/dev/mapper/vg288-lv1 on /content type ext4 (ro,relatime,stripe=16)Keserves kuzdelem volt. Azt kell mondjam, hogy ha tortenetesen tonkrement volna a NAS (de a lemez nem) es adatot kene mentenem rola, akkor elegge izzadtam volna. Frusztralo, hogy ott a kezemben a lemez, de ugraltatnak aprosagokkal, nehogy veletlen hozza is tudjak ferni az adatokhoz. Gondolom a helpdesk ilyenkor azt mondana, hogy vegyek toluk masik nas-t es tegyem bele abba, hadd koltse csak a felhasznalo a penzt naluk.
De a lenyeg, ami miatt az egesz szenvedes volt: az ominozus file-t siman tudtam olvasni, az eg vilagon semmi baja nincs a lemeznek. Ejjel futtatok egy komplett smart tesztet de az olvasas teljesen jol megy, a linux kernel nem nyafog arra, hogy a diszk ne valaszolna, vagy hogy hibas lenne a szektor. Ugyhogy megneztem jobban es azt lattam, hogy az adott konyvtarban a file neve aposztrofok kozott volt ('). Ugyhogy valoszinuleg a gond az lehet, hogy ettol hasal el a qnap, nem birja, ha a file nevben szokoz es ' van. Mert a rpi siman olvasta, nem volt semmi gond. Ugyhogy a lemez most megy vissza a nas dobozaba, mivel lathatoan nincs semmi baja, csak a qnap szoftver a fos. Megprobalom majd atnevezni, ha SMB-n at nem is, mert elhasal akkor majd ssh-val belepek es szepen a cli-bol atnevezem oket.
Ugyhogy megsporoltam durvan 120k elkolteset, azaz egesz pontosan el tudom tolni a vasarlast, mert nem surgos. A hely tovabbra is fogytan van, szoval hacsak nem torlok, a nagyobb lemezekre majd valamikor szukseg lesz egyszer.
A qnap meg rakjon fel sunt maganak, az elejen amikor meg total nem ertettem mi van es rakerestem, az internet tele volt olyan forumokkal es levlistakkal, hogy a qnap rendszere zart, vagy legalabbis zartta probaltak tenni, ilyen esetben adatmentest csak ugy lehet csinalni, ha a lemezt masik qnap eszkozbe rakja az ember. Mondjuk jo tudni, hogy nem.
-
mrots
tag
A legtobb esetben a jumbo frame tamogatas bekapcsolasa a hordozo halozatban a legfontosabb. Ha ott megvan es tamogatja, akkor lenyegesek a vegpontok. Az, hogy a teve nem tamogatja az ket okbol nem problema. A jumbo frame tamogatas lenyege, hogy minel tobb adatot szuszakolj bele egy keretbe, mert a hasznos vs haszontalan arany igy lesz a legjobb, illetve igy tudod a legtobb adatot tovabbitani a legkevesebb eroforras-hasznalattal. Namost ez pontosan az ellentettje annak, amit a teven akarsz. A teven nem azt akarod, hogy baromi gyorsan menjen az adat, hanem azt, hogy minel kisebb kesleltetessel. Hiaba tudna a teve sokkal gyorsabban lehuzni adatot a NASrol, te attol nem fogod tudni a ket oras filmet masfel ora alatt megnezni. Tehat a reszponszivitas a lenyeg, a real-time elmeny. Ehhez pontosan az kell, hogy az adatot amint keszen van azonnal kuldeni kell, nem pedig osszevarni meg ot csomagot, hogy tobb hasznos adatot lehessen az egy csomagba belerakni. Mivel tagadhatatlan, hogy egy hatszor akkora csomagot osszerakni tovabb tart mint egy hatod akkorat, nyilvan lathato, hogy legalabb az elejen valami kesleltetes kell, legyen amit persze a buffereles orvosol.
A dolog masik resze pedig az, hogy a legtobb esetben a forgalmat nem a nas inditja a teve fele, hanem a teve a NAS fele. Ki kell valasztanod, milyen tartalmat akarsz nezni es ezt a tartalmat a teve huzza le a nasrol, tehat a kapcsolatot is a teve kezdemenyezi. Ha a teve csak 1500 byte MTU-val tud mukodni, akkor ennyivel fog forglamazni. A NAS-t nem fogja erdekelni, hiszen a 9k-nal kisebb az 1.5k.
A harmadik resze a dolognak pedig az, hogy a TCP fejlecben van MSS, amivel a handshake soran az egyik oldal jelzi a masiknak, hogy mekkora a legnagyobb szegmens amit kezelni tud. Az alapertelmezett ertek az MTU minusz 40 byte. A SYN es SYN+ACK csomagok fejleceben mindket fel megtalalja a masik altal jelzett MSS erteket es a ketto kozul a kisebbet fogjak hasznalni azert, hogy ne legyen tordeles az utvonalon. Az egyik oldal azt jelzi, hogy tamogat 9k-t, a masik hogy 1460 byte-ot => 1460 byte-os kereteket fognak hasznalni. Amennyiben a forgalom UDP felett van, akkor MSS nincs, kezfogas sincs, ha valaki tul nagy csomagot kuld akkor azt valaki el fogja dobni es az alkalmazas feladata a hibakezeles - ezert hasznal UDP-t.
Amennyiben az oprendszer tamogat PMTUD -t akkor ezen a ponton is kiderul meg a kommunikacio megkezdese elott, hogy mennyi az annyi es mekkora a legnagyobb keret amit meg tordeles nelkul lehet elkuldeni.
-
mrots
tag
Felteve, hogy a halozati eszkozok rendben vannak - es miert ne lennenek - szerintem a jumbo frame ennel tobbet szamit. A kevesebb, mint 5%-ban igazad lenne, ha csak siman a matekot vennem. Mert az ethernet keret ugye 1522 byte (ha van vlan), amibol 18 + 4 = 22 byte az ethernet header, az IP header 20, a tcp header tovabbi 20, tehat 1522 byte-ra jut 1460 byte hasznos adat. Tehat a veszteseg a matek alapjan valoban 4.1% korul van.
Ugyanakkor ha csak az 1500 byte-os MTU-val szamolok (ethernet header es footer akkor is van, ha jumbo MTU-t hasznalok) akkor egy 9k -s frame pontosan hatszor akkora, mint egy 1500 byte-os frame. Ami azt jelenti, hogy 9k -nyi adat elkuldesehez nem hat, hanem csak egy keretet kell elkuldeni. Ez pedig azert fontos, mert mindenki, aki az utvonalon foglalkozik a kerettel (mindket vegpont, switch(ek) a helyi halozatban stb) annak hatod annyi CPU idot kell toltenie a fejlecek vizsgalataval.
Hat csomaghoz nyilvan hat fejlec is tartozik, ezeket pedig mind nem kell elkuldeni, hatszor, csak egyszer.
Aprosagnak tunik, de ha ki akarsz hajtani egy gigabites vonalat, akkor nem mindegy, hogy kb 80k keretet kell kikuldened, azaz minden eszkoznek 80k fejlecet kell megvizsgalnia, ami CPU es egyeb eroforrasba kerul, vagy csak 14k fejlecet. Ha raersz, szerintem erdemes kimerned sajat magadnak a sajat halozatodon, mert a nyereseg csak egy resze fog a fenti matekbol kijonni, a masik resze abbol fog kijonni, hogy egy csomo dolgot nem kell a halozati eszkozoknek, valamint a masolasban reszt vevo ket vegpontnak megcsinalnia.
-
mrots
tag
Az elso linkedben: "could allow remote attackers who have gained user access to execute arbitrary "
Tehat azok a tamadok, akiknek mar van hozzaferesuk, azok hajthatnak vegre tamadast, hogy meg tobb joguk legyen. A masodik linkedben sem latom sehol leirva, hogy azonositatlan felhasznalok tudnak nullarol tavolrol kihasznalni a hibat. De igazabol mindegy is. Az en eszkozom problemajat nem kell elmeselned mert nem az enyem ami kint log az interneten.
-
mrots
tag
A linkelt oldalon nincs olyan hiba, amit ervenyes felhasznalonev / jelszo paros nelkul ki lehet hasznalni.
Ezzel nem azt mondom, hogy csinalja csak, hanem azt, hogy az ervedet, amivel amugy egyetertek, a linkelt oldal nem tamasztja ala, mert azok kozott nincs semmi ami ra veszelyes lehet. Inkabb az olyan hibakkal kapcsolatban kellene aggodnia, ami autentikacio nelkuli tavoli hibakihasznalast tesz lehetove, amik kozul viszont a linkelt oldalon egy sincs.
-
mrots
tag
válasz
PHenis
#12319
üzenetére
"Az a kérdésem, hogy ha a qnap meghal de a hdd túléli, akkor a tartalma olvasható majd egy linux vagy windows rendszeren?"
A rovid valasz igen. A hosszu valasz, hogy egy korabbi OS verzioval futottam bele olyan bugba, hogy a drive encryption passphrase-nak csak az elso 16 karakteret hasznalta a qnap. Azaz mikor felmountoltam, megadtam a 16 karakternel hosszabb passphrase-t, mukodott, hasznaltam evekig. Aztan egyszer csak migraltam, kivettem a HDD-t, fel akartam mountolni egy linuxban es az istennek nem sikerult. Felkutattam a fel internetet mire megtalaltam ezt a bugot. Utana megprobaltam csak a passphrase elso 16 karakterevel es ugy mar ment kulso linuxon is.A fenti bugtol eltekintve a valasz igen. Ha pedig nem hasznaltal titkositott filerendszert akkor a problema nem is erint.
-
mrots
tag
"De se az SSH, se a crontab manipulacioja nem az a felhasznaloi feladat"
Nem is allitottam, hogy az lenne. Valaki azt irta: nem lehet megtudni, milyen utemezett feladatok futnak a hatterben. Az en allitasom pedig az, hogy de.Nem irtam, hogy barmit modositani kene, nem irtam, hogy szerkeszteni kene. Csak azt, hogy de, van egy lista amiben minden utemezett feladat megtalalhato.
-
mrots
tag
válasz
morfondőr
#12288
üzenetére
"Sajnos nincs egy olyan menüpont, ahol az összes ütemezett feladat össze van szedve."
De, van. Belepsz SSH-n es megnezed, mi van a crontabban. Nem csak azt latod, hogy mi fut, de azt is, hogy mikor, igy tudsz korrelalni a "leallas" idejevel.
[~] # uname -a
Linux nas 3.10.20-al-2.5.3 #976 SMP PREEMPT Wed Jan 31 05:56:57 CST 2024 armv7l unknown
[~] # whoami
admin
[~] # crontab -l
# m h dom m dow cmd
0 2 * * * /sbin/qfstrim
36 9,21 * * * /sbin/notify_update --nc 1>/dev/null 2>&1
0-59/20 3 * * * /sbin/adjust_time
0 1 * * * /etc/init.d/flush_memory.sh >/dev/null 2>&1
0 4 * * * /sbin/hwclock -s
0 3 * * * /sbin/vs_refresh
0 3 * * * /sbin/clean_reset_pwd
0-59/15 * * * * /etc/init.d/nss2_dusg.sh
30 7 * * * /sbin/clean_upload_file
30 3 * * * /sbin/notice_log_tool -v -R
*/10 * * * * /sbin/config_cache_util 0
00 03 * * * sh /share/CACHEDEV1_DATA/.qpkg/MalwareRemover/MalwareRemover.sh scan;#_QSC_:MalwareRemover:malware_remover_schedule:None:d::
30 07 * * * sh /share/CACHEDEV1_DATA/.qpkg/MalwareRemover/Upgrade.sh;#_QSC_:MalwareRemover:malware_remover_upgrade:None:d::
0 3 * * 0 /etc/init.d/idmap.sh dump
* * * * * /var/cache/netmgr/lock_timer.sh
0 4 * * * /etc/init.d/wsd.sh restart
4 3 * * 3 /etc/init.d/backup_conf.sh
0 12 * * * /mnt/ext/opt/LicenseCenter/bin/qlicense_tool local_check
0 0 * * * /usr/local/sbin/qsh nc.archive >/dev/null 2>&1 -
mrots
tag
válasz
gallimi
#12032
üzenetére
Ha az IP pingel, akkor a doboz nem halt meg. Feltetelezem, hogy az ssh engedelyezve van es ennek ellenere nem valaszol. Gondolom egy telnet <ip> 22 -t is kiprobaltal, hogy latszodjon, az ssh demon egyatalan valaszol-e es csak a kulcsok egyezteteseben akad el, vagy mar a udvozlo sor sem jelenik meg. Egy wireshark is meg tudja mondani, hogy a putty belepesi probalkozasra TCP RST jon-e (az ssh nem fut), vagy lezajlik a TCP hanshake es utana megall (fut az ssh de molyol, szamol, lassu, elfogytak az eroforrasai stb), vagy nem jon semmi valasz (nem valoszinu, mert az halozati hibara utalna, de a ping megy, szoval halozati hiba valoszinu nincs).
En meg megprobalnam, hogy amikor elerheto (azt irtad reboot utan elerheto) akkor belepnek ssh-val, ott hagynam (mondjuk egy raspberry pi-rol screen -en at). Megvarnam amig nem mukodik es amikor a hiba elojon megneznem, hogy az ott hagyott ssh session mukodik-e meg? Ha igen, akkor belulrol is korbe lehet nezni. Logokat megnezni, megprobalni a nas-rol kifele ssh-zni, megnezni hogy all a memoria, cpu terheles. Olyasmiket amik ravilagithatnak arra, miert nem valaszol az ssh-ra.
Vagy, ha a reboot nem takaritja ki, utolag is lehet logokat nezni, de az nem feltetlen tartalmaz mindent.
-
mrots
tag
válasz
Beni2360
#11988
üzenetére
Koszi, kedves, hogy segiteni probalsz / javaslatot teszel, de per pillanat ezt elengedtuk. Mielott a gyerekek szulettek, egy projektorra volt rakotve egy regi laptop es azon ment a netflix. Mikor az elso szuletett, elpakoltuk, mert se idonk nem volt mar nezni, se nem akartuk, hogy mikor jarni kezdett, lerangassa a vezetekeknel fogva. Azota ha egyatalan van idonk leulni, akkor egy ipaden nezunk netflixet, illetve van rajta VLC, samban latja a nas-t, es onnan tud lejatszani sajat tartalmat. A plex egy hirtelen otlet volt, mert tulajdonkeppen a qnap semmilyen hozzaadott erteket nem hasznalom ki (kb egy alkalmazas sincs felrakva az alapertelmezetten tul) es gondoltam hasznaljuk mar valamire, ha egyszer qnap. Megbantam. Elengedtem. Majd egyszer.
-
mrots
tag
Hasonloan jartam en is. Gondoltam ott van 2-3 TB film amit valoban nezunk is ha idonk engedi, de ne mar samban nezzuk. Gondoltam felrakom a plexet. Hat, nem jott be. NAS kompletten meghalt tole. Vegul ugy sikerult eletre lehelni, hogy HDD kivesz, adatok lement egy kulso merevlemezre, HDD visszarak, factory reset, adatok visszamasol. Sose kapom vissza azt a ket napot az eletembol. Azota elunk plex nelkul es kibirjuk, hogy kevesbe csilli feluleten a VLC-ben valogatunk, mit akarunk nezni.
-
mrots
tag
válasz
Lackó1984
#11959
üzenetére
A raid1 definicio szerint azt csinalja, hogy ket lemezen akar futni es ha egy lemez eltunik, akkor amint megjelenik egy masodik lemez, elkezdi a tomb ujraepiteset. Azert nem sikerult amit csinaltal, mert az eredeti lemez tovabbra is raid1 -ben volt es varta, hogy mikor jelenik meg egy masodik lemez, amit bevonva helyreallithatja a raid allapotat.
-
Új hozzászólás Aktív témák
Hirdetés
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Elektromos cigaretta 🔞
- Google Pixel 8 Pro - mestersége(s) az intelligencia
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Kerékpárosok, bringások ide!
- Windows 11
- AMD Navi Radeon™ RX 9xxx sorozat
- PlayStation 4
- Kerékpársportok
- Garmin Forerunner 970 - fogd a pénzt, és fuss!
- További aktív témák...
- Csere-Beszámítás! Intel Core I5 14600K Processzor!
- Csere-Beszámítás! Lenovo Legion 5 White ! R5 5600H / RTX 3050Ti 6GB / 16GB / 500GB SSD
- T14 Gen1 14" FHD IPS i5-10310U 16GB 256GB NVMe magyar vbill ujjlolv IR kam gar
- FÓLIÁS! LG UltraWide 35WN75C-B Ívelt Monitor! 3440x1440 VA / 100Hz / 5ms / FreeSync
- Tom Clancy's The Division - Sleeper Agent Edition Xbox One
- 15" Workstation: Lenovo Thinkpad P1 gen1/gen2 // P52 // P52s // P15 gen1 // FHD, 4K oled touch
- Beszámítás! HP Z2 G4 Tower Workstation számítógép garanciával, hibátlan működéssel
- ÁRGARANCIA! Épített KomPhone i5 13400F 32/64GB RAM RX 7700 XT 12GB GAMER PC termékbeszámítással
- Bomba ár! Dell Latitude 3590 - i5-8GEN I 8GB I 256SSD I HDMI I 15,6" FHD I Cam I W11 I Garancia!
- Bomba ár! Lenovo ThinkPad T470 - i5-G6 I 8GB I 256GB SSD I 14" FHD I HDMI I Cam I W10 I Garancia!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged