Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
Mobilarena
Kérdés feltevése előtt kérlek olvasd át figyelmesen az alábbi leírást!
Új hozzászólás Aktív témák
-
#18124
Mr Dini
addikt
huliganboy
#18119
Mr Dini
addikt
válasz
huliganboy
#18119
üzenetére
Szia!
FFp USB-s verzió egy külön stickre. Akkor ugyan gyári csomagokat nem, de FFp-seket tudsz telepíteni.
-
Mr Dini
addikt
válasz
Vigyorka
#18094
üzenetére
A \\NSA310S\admin\download\ "mappa" egyenlő a /i-data/md0/admin/download/ "mappával". Azaz használhatod a symlinkes/mountos megoldást, vagy a TM webes felületén írd át az útvonalat erre. Illetve ha a webGUI nem ad rá lehetőséget (amit kétlek, ha 2.92-ről van szó), akkor meg kell keresni a Transmission-öd settings.json fájlját, s azt kell szerkeszteni (topik keresője segít). Nomeg ott van még a Transmission Remote GUI kliensprogram, amivel szintén lehet állítani a letöltés helyét.
-
Mr Dini
addikt
válasz
Vigyorka
#18090
üzenetére
Az egy picit trükkös, mivel tudtommal megosztásokat csak a behelyezett HDD-ken tudsz létrehozni (illetve a külső adathordozók kivételt képeznek). Egyébként a többi mappa megosztására nem is nagyon lehet szükség, mivel azok legtöbbje kizárólag olvashatóként elérhető, vagy reboot után visszaáll alapra. A /opt, vagy /ffp "mappák" kivételesek, mivel azok a HDD egy rejtett mappájából vannak a gyökérbe felcsatolva. S ezt a rejtett mappát természetesen Wines megosztásokkal nem fogod tudni elérni (hacsak nem írod át kézzel az smb.conf-ot).
Alternatív megoldás lehet, hogy mondjuk a /opt/etc/downloads mappát felcsatolod a /i-data/md0/admin/letoltes-nek.
Erre két lehetséges megoldást tudok hirtelen. Az egyik ezek közül a mezei szimbolikus linkelés:
ln -s /opt/etc/downloads /i-data/md0/admin/letoltes
Viszont itt okozhat esetlegesen az gondot, hogy a /opt már eleve egy symlink, szóval feltételezem, hogy a "keresztbe" linkelést a rendszer nem fogja kitörő örömmel fogadni. Így, amennyiben hibát dob, add ki ezt:
ls -la /opt
S ebből a kimenetből ki tudod hámozni a /opt mappa valódi fizikai elérési útvonalát.
A másik megoldás pedig a csatolás:
mount --bind /opt/etc/downloads/ /i-data/md0/admin/letoltes
Viszont, mivel ezek a változtatások a RAM-ban tárolódnak, egy reboot után újra symlinkelni/újracsatolni kell a parancs manuális ismételt kiadásával. Alternatív megoldásként javaslom, hogy hozz létre az entware-ng-s /opt/etc/init.d mappában mondjuk egy S00usersymlinks fájlt (nincs most előttem, hogy az entwarenél hogy vannak a számok, de a 00 biztosan hamarabb fog lefutni, mint a TM), s másold bele a parancsot. Aztán tedd futtathatóvá a chmod +x /opt/etc/init.d/S00usersymlinks paranccsal.
-
Mr Dini
addikt
válasz
Thomas16
#18086
üzenetére
Én sajnos nem tudok ilyen helyről. Esetleg egyeztess a ZyXEL magyarországi helpdeskjével, hogy vállalnak-e szervízelést még (persze valamennyi "munícióban" érdemes megegyezni velük). De pontosan mi a probléma a NASoddal? Egy lapból áll, nekem nem tűnik nagy mutatványnak a javítása (persze ez függ attól nagyban, hogy mi romlott el).
-
Mr Dini
addikt
válasz
8nemesis8
#18079
üzenetére
Egyébként mi a diffi a 310 310a között?
Tudtommal hardverügyben semmi, szoftverileg lehet valami kis eltérés, de hogy erre pontosan miért volt szükség, azt egyelőre csak a ZyXEL fejlesztők tudják.
Az is lehet, hogy egy fw frissítést követően vissza fog állni a sima 310-re. Pl itt egy logbejegyzés róla, amit még régebben gyűjtöttem be valakitől:[zypkg_get_server_path_from_model][318] NSA310a -> NSA310310S tudom, hogy picit erősebb hardverrel dolgozik!
Nem egészen. Úgy tippelünk a kollégákkal, hogy az 'S' karakter a ZyXEL termékek nevében a smallra (kicsi) utalhat. A 310 és a 310S közt csak annyi a különbség, hogy a 310-nek 1200 MHz-es CPU-ja van, míg a 310S-nek csak 1000 MHz. Azonkívül a 310S szoftveres támogatottsága tovább tartott, mint a 310-nek, mivel később jelent meg.
Egyébként jelenleg is van FFP telepítve a NAS-ra, ez nem okozhat gondot neki, ugye?
MetaRepo telepítem, utána kikapcsolom pendrive leválaszt és mehet az FFP vagy egyből mehet az FFP install a HDD-re?Amint kihúzod a pendriveot, az FFp-nek hűlt helye sem marad.
Viszont a két FFp nem szereti egymást, s nem várt gondokat okozhat, így a telepítés előtt mentsd le a régi pendriveos FFp számodra érdekes mappáit/fájljait a NAS HDDjére mondjuk (figyelj arra, hogy a jogokat is másold át), majd ahogy írod, NAS kikapcsolás, pen lecsatolás, NAS boot, FFp telepítés és a régi mappák visszahelyezése (ismét jogok megtartásával).Pl ha a Transmission-t szeretnéd teljes mértékben áthelyezni, akkor a /ffp/tm/ mappát kell menteni. Viszont ez magát a csomagot nem tartalmazza, csak mindenféle adatot. Így a friss FFp-nél a visszahelyezés előtt telepíteni kell slackerből a TM-met, s csak aztán mehet a /ffp/tm/ mappa visszamásolása. De figyelj arra, hogy a TM ne fusson, amikor visszamásolod!
-
Mr Dini
addikt
válasz
8nemesis8
#18076
üzenetére
Pedig ez a kimenet teljesen rendben van. Látszódnia kellene a listában is...
Ilyen jelenséggel nem is találkoztam még korábban, pedig azért nem egyszer fordultak elő már érdekes jelenségek a csomagkezelő hatáskörében.
De akkor telepítsd fel kézzel a MetaRepository-t, így:
/usr/bin/ipkg-cl -f /etc/zyxel/zy-pkg.conf -t /usr/local/zy-pkgs/tmp -nodeps install MetaRepositoryHa hibát dobna ez a telepítés, akkor használd a teljesen manuális verziót:
wget http://downloads.zyxel.nas-central.org/Users/Mijzelf/zypkg-repo/NSA310a/4.40/zypkg/MetaRepository_20160513_arm_013.zpkg -O /tmp/MetaRepository_20160513_arm_013.zpkg
/usr/bin/ipkg-cl -f /etc/zyxel/zy-pkg.conf -t /usr/local/zy-pkgs/tmp -nodeps install /tmp/MetaRepository_20160513_arm_013.zpkg
rm /tmp/MetaRepository_20160513_arm_013.zpkgEgyébként megsúgom, hogy nagyon nem tudnál mellényúlni a MetaRepository telepítővel, mivel mindegyik NAS-ra ugyanaz a csomag kerül fel. A mappaszerkezet csak azért kell, mert minden NAS típus máshol keresi a hozzá való csomagot. Egyébként azt hiszem az eredeti a 310 mappájában van, a 4.40 alatt. A többi csak symlink oda.
-
Mr Dini
addikt
válasz
8nemesis8
#18051
üzenetére
Szia!
Elnézést a kései válaszért, de csak most jutottam NAS közelbe. S egy információmorzsára szükségem volt az élő rendszerről.
Frissíts rá kérlek a csomaglistára, majd add ki ezt a parancsot SSH-n:
cat /usr/local/zy-pkgs/tmp/zypkg.log | tail -n25A kimenetet nézd át, hogy van-e valami árulkodó jel benne. Ha pedig nincsen, akkor manuálisan is tudod telepíteni a csomagot, hiszen a NAS csomagkezelője mögött tulajdonképpen egy módosított Optware-s ipkg van. A helpjét az
ipkg-cl -hparanccsal tudod elérni, s minden parancsnak ezzel kell kezdődnie, erre figyelni kell:/usr/bin/ipkg-cl -f /etc/zyxel/zy-pkg.conf -t /usr/local/zy-pkgs/tmpSzóval, hogyha kézzel letöltöd a MetaRepository-t, majd felcédézel az őt tartalmazó mappába, akkor ez a parancs telepíti Neked repository nélkül a repot (feltéve, hogy "MetaRepository_20160513_arm_013.zpkg" a fájl neve):
/usr/bin/ipkg-cl -f /etc/zyxel/zy-pkg.conf -t /usr/local/zy-pkgs/tmp -nodeps install ./MetaRepository_20160513_arm_013.zpkgÚgy vélem, hogy ezeket az nfs-utils csomaggal tudtad hozzáadni a meglévő megosztásokhoz (vagy frissült ilyen tekintetben az NFS csomag, csak nem tudok róla). És igen, látszik az is a ZyXEL-es listában, amit nem azzal hoztál létre, mivel mindkét verzió (FFp-s és csomagos) egy fájlból dolgozik.
-
Mr Dini
addikt
válasz
M_AND_Ms
#18058
üzenetére
Az, hogy NFSv2 alapú, ami nem mai verzió már, s sok mindent nem támogat. Pl. a PXE alól diskless bootolást sok kernel nem szereti NFSv2-vel megtenni, illetve kevésbé biztonságos, mint a 3/4...
De a legnagyobb hátránya szerintem, hogy akármilyen mappát nem enged megosztani, hanem mindenképp az NFS mappában kell lennie.
-
#18060
Mr Dini
addikt
Success555
#18057
Mr Dini
addikt
válasz
Success555
#18057
üzenetére
Van ffp mappád? Mit ír a PuTTy bejelentkezés után? Mert nekem ez a BB-os shellnek tűnik, nem pedig az FFp-snek (
~ $)...Javaslom inkább a programcsomagos FFp verzió telepítését egyébként. Ahhoz leírást a ZyXEL NSA325v2 topikösszefoglalójában találsz, s a MetaRepository telepítése szükséges hozzá.
-
#18054
Mr Dini
addikt
Success555
#18053
Mr Dini
addikt
válasz
Success555
#18053
üzenetére
Szia!
Írja az a jelszót, csak biztonsági szempontból vizuálisan nem kapsz róla visszajelzést. Írd be a jelszót, majd nyomj egy entert!
-
Mr Dini
addikt
válasz
8nemesis8
#18042
üzenetére
Mielőtt feltennéd a csomagos verziót, terminálból másold le a tm mappát a HDD-re úgy, hogy q jogok megmaradjanak:
cp -a /ffp/tm/ /i-data/md0/admin/
Majd frissíts rá a csomaglistára. Ha nem jelenik meg ennek ellenére sem a MetaRepository, mint egyetlen csomag, akkor vagy korábban hozzáadtad már, vagy az fw verziódhoz nincsen fent leírófájl repo oldalon. Hanyas fw verziód van jelenleg?
Ha megjelenne a MetaRepo, tedd fel, menj rá a frissítésre, majd kapcsold ki a NAS-t, húzd ki a pent, s bootolás után tedd fel a csomagosat!
Aztán tedd fel a Transmission korábban is telepített verzióját, s add ki ezeket(az első parancsnál nem gond, ha hibára fut):
rm /ffp/tm/ -R
mv /i-data/md0/admin/tm/ /ffp/És mehet a TM indítás.
-
Mr Dini
addikt
Akkor root-tal fut. Egyébként entware-ng-s telepítésnél a /opt/etc/init.d mappába kerülnek az indítófájlok, ott lesz nagy valószínűséggel a TM-é is SXYtransmission, vagy valami hasonló néven (XY helyére két szám kerül).
Egyébként a settings.json-ban az
umaskértéket írd át nullára, ebben az esetben mindenki hozzáfér majd a letöltött amyagaidhoz, s lesz joga módosítani is. Ha ezt szeretnéd elkerülni, akkor túrd át azt a start szkriptet, s a root-ot írd át benne admin-ra! -
Mr Dini
addikt
válasz
8nemesis8
#18034
üzenetére
Szia!
A zypkg verzió más, mint a pendriveos, így nem teljesen kompatibilisek egymással. FFp-t az ebben az összefoglalóban taglalt módon érdemes feltenni (a Meta Repository segítségével). De ha feltelepíted rá a csomagos FFp-t, akkor a penról ki lehet menteni a TM mappát.
-
Mr Dini
addikt
Nem bash hiba, hanem hogy amikor az FFp elindulna, akkor az első sorában meghívja az FFp-s sh-t (
#!/ffp/bin/sh), ez viszont nem tud elindulni, mert a függőségeit nem a /ffp/lib mappából tölti be, hanem a /lib mappából (mert ezt találja első libeket tartalmazó mappának). Ez utóbbi pedig a rendszeré, s itt kevesebb/más függőségek vannak. Így nem tud elindulni rendesen az FFp, s ezért nem indul el az összes futtatható szkripted a /ffp/start mappában.A barmalej féle bash csomag viszont statikusan a /ffp/lib alatt keresi a függőségeit (ezt lehet elérni az említett RPATH változóval fordítás közben). Így Ő minden további nélkül tud működni.
És a csattanó az egészben az, hogy az FFp indítója lenne felelős az LD_LIBRARY_PATH változó állításáért, ami pont arra hivatott, hogy az függőségeket a változóban deklarált útvonalakon keresse először.
És ez a jelenség azért viszonylag újkeletű, mivel az FFp is frissül néha. S mivel nemrég telepítettél szűzen FFp-t, így egy frissebb verzió került fel, ami rendelkezik sajnos ezzel a problémával. De már jeleztük a jelenséget Mijzelfnek (Ő csinálta és azóta is karbantartja az FFp-t ZyXEL NASokra). Remélhetőleg hamarosan javítva lesz majd és nem lesz szükség a kézi beavatkozásra friss telepítésnél...
-
Mr Dini
addikt
Szia!
Tipikus FFp és ZyXEL fw bug. Az FFp indítója a saját bash binárisát akarja használni, viszont az nem tud elindulni, mert még nincs beállítva a /ffp/lib/ mappára az LD_LIBRARY_PATH változó. Ezért nem fut le az indító, ami felelős többek közt a start szkriptek boot közbeni indításáért is.
Elméletileg hamarosan javítva lesz (magában az FFp-ben), addig is gyors fixnek a bash csomag frissítését ajánlom:
slacker -UuiA br2:bash
Csak a barmalej2 féle legfrissebb bash csomagba van beleégetve, hogy a szükséges libeket a /ffp/lib mappában keresse elsődlegesen (statikus RPATH-szal lett fordítva)!
-
-
-
Mr Dini
addikt
válasz
junkpod
#17834
üzenetére
XPEnology ugyan nincs, de egy TTL kábellel, egy linuxos géppel (fontos, hogy Ubuntu/Debian OS legyen, s x86/x64), illetve egy délelőttnyi munkával lehet rá Debian-t hegeszteni. Arra meg felmegy pl az OMV. Nekem nagyon bejött. A Debian mérföldekkel jobban bánik a RAM-mal, mint a gyári firmware.
S lehet akár HDD-re/pendrivera/másik hálózati eszközre tenni, így azt eltávolítva a NAS gyári oprendszere is pillanatok alatt bootolható.
-
Mr Dini
addikt
válasz
Somatom
#17838
üzenetére
Az NFS-t lehet SSH tunnelen keresztül nyomatni, ahhoz VPN sem kell. Viszont így nem olyan gyors, s az újabb Windowsokon úgy hallottam, hogy mostohán van kezelve.
Nekem eddig az általam már sokszor említett és dicsőített webDAV vált csak be. Talán picit összetett a telepítése, de sokkal többet tud és gyorsabb, mint a többi. Plusz ezt akár melóhelyről is lehet használni, mert a HTTPS kapcsolatot (443-as port) nem szokták korlátozni.
Egyedül kliensből van csak kevés hozzá (a legtöbb csak fájlkezelő). De ez nem akadály, egy ilyen appot (tallózó, zenelejátszó) nem nehéz összedobni Androidra. Ja és hozzá kell tennem, hogy idén márciusban volt egy éve, hogy használom, azóta egyszer nem volt vele gond. -
Mr Dini
addikt
válasz
junkpod
#17816
üzenetére
Az FTP nem stramelésre lett kitalálva, hanem fájlcserére (File Transfer Protocol ugyebár).
Ezért mindenképp leszedi az egész fájlt a kliens a lejátszás előtt. Egyedül a Kodi képes az általam ismert programok közül pufferelni rajta bizonyos fájltípusoknál.
A webDAV/dir list viszont gyors, s streamingre kiválóan alkalmas megoldás.
-
Mr Dini
addikt
válasz
Somatom
#17809
üzenetére
Megjegyzem, nem kicsit vicces, hogy egy ilyen DDNS -t, vagy néhány szervert (pl. webDAV, Lighttpd) úgy kell felhekkelni a NAS -ra, miközben egy Androidos eszközön ugyanezek GUI -n, öt perc alatt beüzemelhetők.
Na ja, de melyik Android része gyárilag a duckdns frissítő program? Oda is ugyanúgy fel kell rakni.
A NAS hálózati adattárolásra lett kitalálva. Eredetileg semmilyen GUIt nem is álmodtak neki, mindent CLI kell hálózaton keresztül beállítani.
S ha így vesszük, FFp alól, a csomagkezelő segítségével pár perc alatt fel tudod tenni a duckdns frissítőt is. Ez olyan, mint a Droidon egy áruház. Csak CLI.
Ok, tudom hülyeség a kettő dolgot egymáshoz hasonlítani, de azért bőven van különbség NAS és mobil/PC közt. Miért kéne támogatnia a NASnak gyárilag egy 3rd party, ráadásul csak nemrég feltörekvő DDNS kiszolgálót?PS: a ZyXEL részéről úgy néz ki megindult valami... Még nem szeretnék elhamarkodottan állítani, de bízom benne, hogy lesz valami abból, amit nemrég kifejtettem privátban.
-
-
Mr Dini
addikt
válasz
junkpod
#17800
üzenetére
Szia!
Én két megoldást szoktam használni. Az egyik az Apache webszerver által nyújtott HTTP(S) mappa listázó, illetve a webDAV páros. Ez olyan szempontból jó, hogy gyors, és ha jól be van konfigolva, nagyon biztonságos is. Kodi is tudja kezelni, illetve tucatnyi Droidos fájlkezelő/lejátszó.
Viszont mivel nem erre lett kitalálva, mindenféle kategorizálás szerinti rendezést stb-t nem tud, tényleg csak a lényeget, a streamelést.
A másik megoldás, amit én főleg itthoni erősítőre szoktam nyomatni, az a NASról futtatott icecast2 szerver. Adok neki egy mappányi zenét, ő meg véletlenszerűen lejátsza őket egy netrádión. Van webes felülete is, így lehet skippelni számokat, illetve bemenetnek sok formátumot támogat, kimenetnek meg mp3-at, meg ogg-t (flac-ot is, de ahhoz mókolni kell picit).
Ez viszont azért nagyon kényelmes, mert az adott zene címét/adatait is kiírja a lejátszóm. Viszont nem olyan gyors, s mindkét megoldást terminál alól kell belőni.
-
#17770
Mr Dini
addikt
adnoctum18
#17769
Mr Dini
addikt
válasz
adnoctum18
#17769
üzenetére
Megpróbálhatod mégegyszer felrakni a phpMyAdmin-t külön. Ha nem megy, már tudod a megoldást alkalmazni.
Egyébként ha nagyon érdekel a dolog, FFp alól is fel lehet hegeszteni magadnak akár egy phpMyAdmint, vagy a SCt is. Persze ehhez a linuxot valamilyen szinten ismerni kell.
-
#17768
Mr Dini
addikt
adnoctum18
#17767
Mr Dini
addikt
válasz
adnoctum18
#17767
üzenetére
Szuper! Tedd be kérlek vágólapra a következő parancssort, majd egy az egyben illeszd be a terminálba:
sed -i 's/LoadModule php5_module \/usr\/local\/zy-pkgs\/lib\/libphp5\.so/\#LoadModule php5_module \/usr\/local\/zy-pkgs\/lib\/libphp5\.so/' /etc/service_conf/httpd.conf
LD_LIBRARY_PATH=/usr/local/zy-pkgs/lib /etc/init.d/httpd.sh restartEz elvileg kikommenteli Neked a hibádzó libphp modult, majd újraindítja a webszervert. Ha most nem dob hibát sehol, akkor menj fel a NAS webes felületére, s töröld a phpMyAdmin és SqueezeCenter csomagokat az adatok törlésének pipálásával! Végezetül adj neki egy rebootot, s elméletileg menni fog fixen a webszerver.
Have fun!
PS: PuTTy-ot használsz? Ha igen, ott elég kijelölni a másolandó szöveget, s bekerül vágólapra.
A jobbklikk pedig beilleszti és ha van benne enter le is futtatja a vágólap tartalmát. -
Mr Dini
addikt
válasz
Somatom
#17755
üzenetére
Én azt csináltam, hogy írtam egy IP checker szkriptet, s ezt beraktam crontabba, hogy 10 percenként fusson le. Ha van IP változás, akkor pedig a szkript küld egy e-mailt, illetve ír Pushbulleten. Ezt a Tasker elkapja az Androidos mobiljaimon, a gépemre pedig szintén írtam egy szkriptet erre.
Bár közben vettem egy domaint, s gondolkodom rajta, hogy csinálok magamnak valami DDNS szerűséget....
-
#17760
Mr Dini
addikt
adnoctum18
#17753
Mr Dini
addikt
válasz
adnoctum18
#17753
üzenetére
Bocs, előre gondolkodtam... Nem vi, hanem cat kell Neked. Az kiírja az egész fájlt egybe.
(#17754) Joshi
Ismert jelenség. Konkrétan Ő a negyedik, aki hozzám fordul ezzel a hibával. Bár eddig csak a phpMyAdmin telepítése okozott ilyesmit.
Amikor felrakta a csomagot, az valamiért nem ment teljesen fel, ezért a NAS azt hiszi, hogy telepítve van, viszont közben hiányzik pár library.
És a probléma az, hogy a NAS a webszerver konfigot csupán egy ramdiskben tárolja, s reboot után mindig újragenerálja az adott beállításoktól függően. Azaz hiába módosítassz rajta, visszaáll következő bootkor...
Egyébként a ZyXEL ezt kicsit okosabban is csinálhatta volna... Mondjuk hogy nem a fő konfigba irkál minden, hanem létrehoz egy újat a csomagoknak.
-
#17751
Mr Dini
addikt
adnoctum18
#17750
Mr Dini
addikt
válasz
adnoctum18
#17750
üzenetére
Igen, sérült a webszerver konfigja... Add ki kérlek a vi /etc/service_conf/httpd.conf parancsot, majd az egész kimenetet mondjuk pastebinre tedd fel, s linkeld be!
A többi instrukciót pedig leírom majd, ha meglesz a konfigod.
-
#17749
Mr Dini
addikt
adnoctum18
#17747
Mr Dini
addikt
válasz
adnoctum18
#17747
üzenetére
Szia!
Az NSU és a webGUI két teljesen különböző szolgáltatásként fut, így nem sok közük van egymáshoz.
Amennyiben van fent FFp, add ki ezt a parancsot:
LD_LIBRARY_PATH=/usr/local/zy-pkgs/lib /etc/init.d/httpd.sh restartAmennyiben pedig nincsen, s a gyári Busyboxos shell van fent, akkor elhanyagolható a parancs elejéről a változó felülírása:
/etc/init.d/httpd.sh restartAmennyiben a parancs dob valamilyen hibát, akkor kérlek másold be nekünk, ha pedig nem, akkor remélhetőleg újraindult a webszerver.
(#17748) Joshi
Én ezt a jelenséget kizárnám, amennyiben tényleg a SqueezeCenter telepítése idézte elő a jelenséget. Illetve feltételezem, hogy akkor a terminálos elérés sem lenne biztosított. De nem rossz ötlet!
-
#17744
Mr Dini
addikt
Oxy.kiraly
#17743
Mr Dini
addikt
válasz
Oxy.kiraly
#17743
üzenetére
Szia!
Nem sajnos, ugyanis tudtommal a DLNA szabvány jelenleg nem képes ilyesmire.
-
Mr Dini
addikt
Esetleg chown root /ffp/var/lib/sshd -R . De érdemes szólni barmalej2-nek (nas-central fórum), hogy tudjon faragni a csomagon!
Csak kíváncsiságból! Mi idézte elő a jelenséget?
Egyébként az FFp userspace része nem fog elveszni, mivel az is a HDD-re kerül (zypkg verzió esetén). Azt pedig egy soft reset nem törli, különben az adatokat is buknád. Ő csak a NAS NAND memóriájának bizonyos részeit formázza. Egyetlen megoldás a webGUI-n keresztül törölni az FFp csomagot az adatok törlésének bepipálásával.
-
Mr Dini
addikt
Transmissionból biztosan az openssl verziót tetted fel, amit @Doky1988 írása is említ?
Mert annak nincsen ilyen függősége... Az a gnutls verzió.
Viszont mivel a NASon openSSL van, így felesleges még egyet felrakni, illetve az openSSL talán gyorsabb is beágyazott eszközökön.
-
Mr Dini
addikt
válasz
Somatom
#17678
üzenetére
Hi,
Én csináltam anno egy tesztet, hogy a 320S két Reddel hogy bírja venti nélkül. Ugyanis a NAS maga nem tűnt problémásnak melegedés szempontjából, csak a HDD-ket láttam esetlegesen kitéve a tényezőnek. De azok is 39.C-nál többre soha nem melegedtek még fel.
Lassan két éve használom így, s mivel testing NAS, van használva rendesen.Barmalejnek ahogy tudom 310-e van, s ő is kikötötte, mert egy jó HDD mellett nincs sok értelme, csak zajt csinál.
De ezt ne vedd készpénznek!
-
Mr Dini
addikt
Amennyiben kap egy teljes resetet, akkor nem lesz fix IP-je, a router DHCP fog neki IP-t osztani. Szóval a router DHCP listában látszódnia kellene... Egyébként, ahogy @szjoci is írta, hosztnévvel is el lehet érni.
2. A konfigoknak csak egy kis részét tárolja a NAS a belső NAND memóriájában, a konfigok nagy része a HDD-re kerül (pl. csomagok/adataik stb.).
Szóval formázás után újra be kell állítanod...
-
#17597
Mr Dini
addikt
Oxy.kiraly
#17595
Mr Dini
addikt
válasz
Oxy.kiraly
#17595
üzenetére
Közben javítottam is a leíráson. Köszi az észrevételt! @Tonyk úr, mint mindig, most is megmondta a tutit!
Execute jogot kell a szkriptnek adni, és csak akkor lehet az sh bináris nélkül futtatni, de régen alapból volt a csomagban szereplő fájlon jog, ezért nem volt szükség erre a parancsra... -
Mr Dini
addikt
Még mielőtt resetelnél, próbáld meg ezt az fw-t kézzel feltolni rá.
2. A NAS NAND memóriája kétszer akkora, mint amekkora helyet maga az fw foglalna. Ez azért van, mert a NASodon fw frissítés esetén nem íródik fölül az eggyel régebbi verzió, hanem egy másik területre kerül az új verzió.
Van egy parancs, amivel pedig vissza tudod állítani az eggyel régebbi fw-t. Ha gondolod, megkeresem Neked...
-
-
Mr Dini
addikt
válasz
mobilizmo
#17544
üzenetére
Bocs, hogy nem reagáltam rögtön!
A miniDLNA szkennerjének van egy olyan hibája, hogy, ha helytelen/sérült fájlt talál, akkor ott megáll a szkennelés... Érdemes a logot debuggerre állítani a miniDLNA konfigban, aztán meglesni, hogy hol akad el pontosan. Aztán azt a fájlt tedd át máshova és nézd meg, hogy így megy-e.
Ennek a HDD állapotához semmi köze. Akkor mások lennének a tünetek (sok weak/bad szektor esetén), pl a CPU maxon lenne terhelve, de ettől függetlenül lassan beindexelné a médiatárad, nem akadna meg.
-
Mr Dini
addikt
válasz
mobilizmo
#17542
üzenetére
Az én miniDLNA-m (minidlna_thumb) képes bélyegképeket generálni, de ez az funkció csak opcionális, ezt a konfigban tudod bekapcsolni (alapból nincs). Viszont az art_cache nem csak a generált thumbnailek tárolására van, hanem a CD borítókat, amik már eleve léteznek (cover.jpg/png), azokat is legyártja különböző felbontásban. De ez olyan csekély erőforrást emészt fel, hogy nem érdemes kikapcsolni...
A két példány pedig nem gond, mivel két service fut alapból. Nem két minidlna. Kettő nem is tudna egy porton elindulni (8200), így el sem indul a második.
-
-
Mr Dini
addikt
válasz
feco93
#17512
üzenetére
Az a csomag sajnos nem fog működni NSA210-en, mivel egy 320S-en lett lefordítva. Próbáld meg esetleg KyLEK Transmissionját feltenni slackerből.
Nem, a létrehozott userek csak a ramba kerülnek eltárolásra. Így egy reboot után "eltűnnek" a létrehozott userek. Szóval érdemes magában a transmission start szkriptben létrehozni a usert (ahogy Te is csináltad), mert az lefut minden bootkor.
-
#17435
Mr Dini
addikt
Impair1980
#17426
Mr Dini
addikt
válasz
Impair1980
#17426
üzenetére
Szia!
Nem hittem volna, de végül csak sikerült egy teljesen statikus TM binárist összehozni!
Korábban próbálkoztam a legfrissebb TM-et portolni gyári csomagként, de bugos volt és nem volt teljesen statikus... Írtan a developernek egy bug report formájában, de nem segítettek, sőt törölték a ticketem. 
Aztán most, hogy feltetted a kérdést megpróbáltam még egyszer összehozni a cuccot, és jelentem, sikerült! 
root@NSA320S:/i-data/bf835951/build/transmission-2.92/teststatic/bin# file ./transmission-daemon
./transmission-daemon: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped
root@NSA320S:/i-data/bf835951/build/transmission-2.92/teststatic/bin# readelf -a ./transmission-daemon | grep NEEDED
root@NSA320S:/i-data/bf835951/build/transmission-2.92/teststatic/bin#Fel is raktam a zypkg-repómba, lecserélve azt a szégyenfoltot. Ha szeretnéd Te is feltenni, MetaRepóból megteheted.
Üdv!
-
#17433
Mr Dini
addikt
dexter1987
#17432
Mr Dini
addikt
válasz
dexter1987
#17432
üzenetére
A strace rendben van. Viszont nem tudom mi lehet a gond. KyLEK Transmissionjával is ezt csinálja?
-
#17430
Mr Dini
addikt
dexter1987
#17429
Mr Dini
addikt
válasz
dexter1987
#17429
üzenetére
Uh, ez nem a shell szkript hibája. A segfault a binárisoknál jellemző...
Ez segít valamit?:
slacker -UuiA br2:{uClibc,uClibc-solibs,bash}Hanyas TM van fent?
Egy
strace /ffp/bin/transmission-remote 12345 -askimentre kíváncsi lennék...Ui.: a konfig elérési útvonalát add meg a tm daemonnak!
-
Mr Dini
addikt
-
#17423
Mr Dini
addikt
dexter1987
#17422
Mr Dini
addikt
válasz
dexter1987
#17422
üzenetére
Szia!
Uwcronból a szkripteket ffp PATH hozzáadásával szokás. Mert sajnos egyik elérhető cron csomag sem tartalmazza az FFp-s pathokat.
Tehát:
/ffp/bin/env PATH="/ffp/bin:/ffp/sbin:$PATH" sh /szkript/elérési/útja.sh
Szerk.: alternatív megoldás, hogy a szkriptben teljes elérési utakat használsz az FFp-s binárisok meghívásakor.
-
#17418
Mr Dini
addikt
Impair1980
#17417
Mr Dini
addikt
válasz
Impair1980
#17417
üzenetére
Szia!
Nem módosítottad a cache (gyorsítótár) méretet?
-
Mr Dini
addikt
válasz
s3toraph
#17411
üzenetére
Pontosan, jól érted.
Ami a HDD-t illeti. Én mindenképp javaslom a dd-t, akár egy pendriveról futtatott GParted is meg tudja csinálni ezt a műveletet. És nekem egy 1 terás WD Red HDD formázása volt kevesebb, mint 6 óra. Egy estére berakod és kész.
De ha tényleg nincs rajta/nem is volt rajta olyan adat, amit féltenél, akkor cselekedj, ahogy szeretnél!
-
Mr Dini
addikt
válasz
s3toraph
#17408
üzenetére
Ha csupán a NAS-t szeretnéd eladni, elég kivenni a HDD-t, majd boot után három csippanásig nyomni a hátsó reset gombot folyamatosan.
Amennyiben pedig a merevlemezt is eladnád, érdemes azt is leformázni mondjuk egy linuxszal. Ezt pedig dd-vel ajánlott megtenni, ami kitölti 0-val az egész HDD-t. Ez egy hosszú folyamat, de így lehetetlen lesz visszaállítani a HDD-n tárolt korábbi anyagot.
-
-
Mr Dini
addikt
-
Mr Dini
addikt
válasz
MammoUTh
#17386
üzenetére
Szia!
Igen, így működik a dolog. A torrent nevéből keresi ki a borítót a cucc, de sokszor nem egyezik a film neve a torrent nevével...
Szerintem az FFmpeges megoldás, amikor kivág egy képkockát a filmből, sokkal járhatóbb út.
Ha érdekel, nemrég gyártottam egy thumb generálós miniDLNA-t.
-
-
Mr Dini
addikt
Szia!
Ezt add hozzá:
http://users.atw.hu/mrdini-zypkg/NSA310/ mrdini-backupMajd Apply-t neki, aztán mehet a csomaglista frissítés és megjelennek a csomagok.
Az egy dolog, hogy meglátogatva böngészőből ezt a linket, nem fog dobni semmit, csak egy 403-at (hozzáférés megtagadva), de a NASok le tudják tölteni, amire szükségük van.
A directory lister, ami a böngészős látogatók kedvéért van felrakva, az érhető el a http://users.atw.hu/mrdini-zypkg/ oldalon. Illetve a ?dir=<valami> az sem a fizikai útvonal, csak a dirlisteremnek mondja meg, hogy miket listázzon...(#17363) Tonyk
A link után meg lehet adni a repónak egy nevet is. Ezzel a névvel fogja megjeleníteni majd a csomagolistában a csomagokat az MR.
-
Mr Dini
addikt
-
Mr Dini
addikt
válasz
ssid3956
#17330
üzenetére
Szia!
Ha csinálsz egy DDNS-t, azt össze tudod kapcsolni a domaineddel.
A NASra pedig legbiztosabb, ha teszel egy második webszervert FFp alól, megfelelően felkonfigolod, majd a portját kiforwardolod a külső 80-as (esetleg 443-as, ha HTTPS) portra és minden menni fog frankón. Webszervernek meg az apache httpd csomagja vált nálam be, de a lighttpd és az nginx is jó alternatíva lehet...
-
Mr Dini
addikt
válasz
kmarci25
#17325
üzenetére
Na, most ha innen letöltöm a 4.70-est és az admin felületen betallózom, mert van ilyen lehetőség, úgy frissülne az fw, nem?
Persze, ennek így kéne a gyakorlatban működnie. Csakhogy a gyártó azt szerette volna, hogy ne lehessen semmiképp downgradelni a NAS-t (plusz custom fw-t se lehessen a NAS hardveres felnyitása nélkül csinálni --> mert, ha ez sikerülne, akkor garival lehetne pl debian-t tenni a NASra), ezért mikor feltöltessz oda egy fw binárist, az összeszed pár infót egy szerverről, majd összeegyezteti a NAS egy binárisa által generált kimenettel. És ha nem egyezik valami, akkor nem fogja engedni a frissítést. A gond csak az, hogy valószínűleg ezt a szervert is megszűntették... Az egyetlen remény talán az lehet, ha a NAS valami cache-ben is tárolná a legutóbbi szerverről leszedett adatokat. Viszont, ahogy a csatolásokat elnézem, szinte minden csak ramdiskeken, vagy read-onlynak a NAND memóriából van csatolva... Ilyen körülmények között nehéz cachelni reboot utáni adatvesztés nélkül. De próba szerencse!
Igen, a beállításaidnak semmi baja nem lesz.
-
Mr Dini
addikt
válasz
kmarci25
#17322
üzenetére
Szia!
Igen, az a gond, hogy a fw verziódhoz nincsen MetaRepository gyártva. Két lehetőséged van...
A.) Ha gondolod szólhatsz Mijzelfnek, hogy készítse fel a repóját erre az fw-re.
B.) FW frissítés. Nos, ez egy kicsi nehézséget fog okozni, hiszen az fw fájlt is eltávolították már a hivatalos szerverről. A NAS meg csak és kizárólag onnan hajlandó frissíteni. Viszont találtam egy megoldást, amivel megkerülhető a dolog, és ha adsz egy pontos NAS típust, akkor összedobok egy pár parancsos leírást. Viszont akkor majd össze kell gyorsan spórolnom egy új tárhelyre valót, már úgyis régóta tervezem!
Szerk.: ahogy szjoci is mondja, minden adat megmarad, csak maga az fw íródik felül, amit a NAS egy erre kialakított partíción tárol. Tehát a csomagok, NAs beállítások, egyszóval minden megmarad.
Viszont elég egy refresh egyébként, a disable/enable során is a refresh miatt jelennek meg a csomagok. Bár sajnos ez az fw verzió miatt kicsit bonyolultabb megoldást eredményez a sima csomaglista refreshnél... -
-
Mr Dini
addikt
válasz
Clark78
#17295
üzenetére
Szia!
Igen, semmi nem fog történni az első HDDvel (hacsak nem formáztatod le azt is a NAS webGUIján véletlenül), minden a régi marad, annyi kivétellel, hogy ugye felcsatolódik még egy diszk.
Persze, simán lehet nagyobb. Méretbeli max korlátok max az adott fájlrendszeri típusból adódhatnak. De ismerek olyat, aki egy 8 terás vincsivel használja a NAS-t. Sok swap mellett még azzal is megdolgozik. Az más kérdés, hogy ekkora vinyót én nem vennék, max két terásat. Mert ha ennyi adatom egyszer csak röpülne egyszerre az ablakon, én minimum hülyét kapnék!
-
Mr Dini
addikt
Szia!
Persze, segítek, ha tudok.
No, a nulladik lépés, hogy feltedd az uwsiteloader-t. Ehhez használd a fórum keresőt, párszor már le van itt írva. Na, ezzel add hozzá a slackerhez az összes repót a KyLEK kivételével.
Majd add ki ezt:
slacker -uiA br2:python/
Végül, ha kiadod ezt:
pip install -r /i-data/b63e1673/.PKG/ffp/ffproot/ffp/opt/sickrage/requirements.txt
És elméletileg elindul a program.
-
Egyedül kliensből van csak kevés hozzá (a legtöbb csak fájlkezelő). De ez nem akadály, egy ilyen appot (tallózó, zenelejátszó) nem nehéz összedobni Androidra. Ja és hozzá kell tennem, hogy idén márciusban volt egy éve, hogy használom, azóta egyszer nem volt vele gond.
Aztán most, hogy feltetted a kérdést megpróbáltam még egyszer összehozni a cuccot, és jelentem, sikerült! 
Új hozzászólás Aktív témák
- Erős Gamer / Munka PC i7-14700, RTX 3070 Ti, 32GB RAM, 1TB SSD
- Brutál ERŐMŰ! Lenovo P710 / 2x Xeon E5 (44 mag!) / 384GB DDR4 / 2x 512 SSD / 8TB HDD, ASUS 1660 6GB
- Asus ROG X13 Flow 2in1 Touch WUXGA 120Hz Ryzen9 5900HS 16GB 1TB SSD Nvidia RTX 3050Ti Win11 Garancia
- Samsung Galaxy A33 5G / 128GB / 6GB RAM / Üzleti széria / Független / 49.990 Ft / Sopron
- Lenovo Legion Go 512GB.SSD. MAKULÁTLAN/KARCMENTES,GARANCIÁS. CSERE IS,OLVASS.
- DELL PowerEdge R740 rack szerver - 2xGold 6130 (16c/32t, 2.1/3.7GHz), 64GB RAM, 10Gbit HBA330, áfás
- Fujitsu LIFEBOOK E449 i5-8250U 12GB 512GB 14" FHD 1 év garancia
- iPhone 13 128GB Starlight -1 ÉV GARANCIA - Kártyafüggetlen, MS3057, 95% Akkumulátor
- Bomba Ár! Lenovo ThinkPad L14 - Ryzen 5 I 16GB I 256SSD I 14" FHD Touch I HDMI I Cam I W11 I Gari!
- Bezámítás! Lenovo IdaPad Gaming 3 Gamer notebook - R5 7535HS 16GB DDR5 512GB SSD RTX 3050 6GBB WIN11
Állásajánlatok
Cég: FOTC
Város: Budapest