- Mi mindenre jó egy másodlagos megjelenítő?
- Mindenki Z Fold7-et akar
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Így lesz tégla a porszívódból - a Roidmi csődje
- Samsung Galaxy A54 - türelemjáték
- Google Pixel topik
- Android alkalmazások - szoftver kibeszélő topik
- Samsung Galaxy Watch7 - kötelező kör
- Azonnali mobilos kérdések órája
- Huawei P20 Pro - profit csinál minden fotósból
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
-
#20889
Mr Dini
addikt
csorike120
#20888
Mr Dini
addikt
válasz
csorike120
#20888
üzenetére
Azt egy telepített MetaRepository írja át és ez teljesen rendben van. Eredetileg a ZyXEL webguis csomagkezelőt egyetlen repository kezelésére tervezték, ezért fogad a web_prefix fájl egyetlen URL-t. Viszont ahhoz, hogy több szolgáltatós repóból, illetve harmadik féltől származó csomagokat lehessen telepíteni találta ki Mijzelf a metarepositoryt. Ez gyakorlatilag egy mini proxy, összegyűjti a különböző címekről a csomagokat és lehetővé teszi, hogy egyszerre láthasd őket. Ő fut az 59999-es porton és ezért kerül átírásra a web_prefixben. Viszont ha fent a MetaRepo, akkor annak a konfig paneljén kéne szerkeszteni a címeket, ha szükséges és utána frissíteni a csomaglistát. A web_prefixet ne piszkáld.
Egyébként mit is szeretnél elérni pontosan? Ja látom, a régi mirroromra reflektáltál. Esélyes, hogy az már nem aktuális, mert már rég nem foglalkoztam ezekkel a nasokkal és az a mirror eleve még a 310-hez volt. Mijzelf repójában, vagy archive.org-on találsz frissebb zpkg-kat, amiket ha fent van a metarepo, egy mezei drag n droppal be tudsz rakni a zy-pkgs mappába és felrakni onnan, ha amúgy nem listázódik amúgy. Meg van talán egy litván ZyXEL mirror, ahol mintha nem töröltek volna mindent még. Bár ebben nem vagyok biztos.
-
Mr Dini
addikt
válasz
Kixman
#20866
üzenetére
Még annyi, hogy én nem frissíteném az u-bootot a nason, jó a régi. Illetve meg lehet úgy csinálni a dolgot, hogy a bootloader próbáljon USB-ről bootolni, aztán ha nem megy, akkor sata-n végül pedig NAND-ról a gyári rendszert, hasonlóan ehhez: [link] Kicsit talán módosítani kell a címeken, de azt hiszem a 310S és a 320S ugyanonnan bootol. Illetve a setenv/getenv páros csak serialon érhető el, ha nincs soros kapcsolatod, az fw_getenv/fw_setenv parancsokat lehet használni SSH-n.
Ha gondolod a parancsok kiadása előtt ossz meg egy pastebines fw_getenv kimenetet a NAS-ról (mielőtt bármit módosítanál), illetve a majd kiadandó setenv parancsok listáját is és megnézem, hogy jó-e.
-
Mr Dini
addikt
Hát nézd, valóban a te döntésed, hogy mire áldozod a szabadidőd, de az tény, hogyha anno nem állsz türelemmel például esetemben a magyarázatokhoz (pedig azért jócskán voltak meredek kérdéseim
), akkor ma is ott tartanék Linux kapcsán, hogy épphogy csak az apt csomagkezelőt ismerem, de semmi mást. Anno nem értettem, hogy miért nem nyitnak sokan az FFp felé, amikor az egy hatalmas lehetőség, de utólag beláttam, hogy tanulásnak jó dolog, de lehet tényleg nem éri meg a vesződést mindenkinek. Pláne hogy az összes repó lehalt, ma már azt javasolnám, amit anno sokáig nem mertem megtenni, hogy aki teljesítményt meg friss csomagokat akar a nastól, az jobban jár egy debian telepítéssel. Talán az 5** széria kivételével az összes nas u-bootot használ, szóval még csak serial se kell a bootolásához és bár elveszti az ember a dedikált zyxeles webes felületet, de cserébe rengeteg leírást kap, egy friss glibc-t, kernelt és toolchaint, meg akár qbittorrentet is telepíthet, ami ellentétben a Transmissionnel pl többszálon is képes hashelni, ami a 326 esetén nagy előnyt jelentene.Viszont ezt a vitát szerintem a moderátorok is szívesebben látnák privátban lerendezve.
-
Mr Dini
addikt
válasz
Kixman
#20841
üzenetére
Szia!
Bár már nincs meg a nasom, úgy tudom a slapt-getes út már rég nem működik sajnos. Nagyon sok meló volt foglalkozni vele, emiatt nagyrészt a nas-centralos barmalej2 foglalkozott vele. Aztán megszűnt a nas-central és ezzel együtt a legnagyobb slapt-get képes repó is. Így, hacsak nem én vagyok lemaradva és valaki azóta csinált megint egy mirrort, nem fog menni az automatikus út. Marad a pepecselős telepítése egyesével az összes függőségnek, vagy az entware talán. De hála Tonyknak a backupokból ez sem olyan nagy falat.
-
Mr Dini
addikt
válasz
Norbika88
#20642
üzenetére
Sima IP elég a pingnek, ezek szerint megy. A samba megosztás is. Amit Tonyk írt, csak akkor menne, ha feltettél volna valami csomagot, ami szolgáltat SSH-t, pl FFp, entware. Ha ezekről hírből se hallottál, valószínűleg nincs fent és ha a webguit nem tudod elérni, necces felrakni (csak pendriveval megy). Meg elvileg felesleges, mert a nas restarttal a webgui is restartol. Ha neked nem megy, ott más gond lesz.
Amire tudok gondolni, hogy egy nas frissítés/reset miatt megváltozott a webes konfig linkje. Ezért javasoltam az inkognitó módot, hogy tuti ne legyen cache. Illetve másik böngészőt is lehetne próbálni. Már nem emlékszem, hogy van-e a nasnak egyáltalán válasza nem létező url-re.
-
#20527
Mr Dini
addikt
gabor1993052
#20526
Mr Dini
addikt
válasz
gabor1993052
#20526
üzenetére
Az, hogy a nas armv5 CPU-val rendelkezik, a Plex pedig 0.99.x óta nem támogatja az armv5 architektúrát.
-
Mr Dini
addikt
válasz
noxika72
#19982
üzenetére
Szia!
web_prefix-be írd be ezt: http://zyxel.diskstation.eu/Users/Mijzelf/zypkg-repo/
Mentsd el, töltsd újra a csomaglistát és rakd fel a legfrissebb MetaRepot. Ha volt fent korábban, frissítsd, vagy töröld&tedd fel újra. Majd telepítés után frissíts rá megint a csomaglistára és ott lesz az ffp meg a többi tool.
-
Mr Dini
addikt
válasz
vanRobert
#19939
üzenetére
Lehet, hogy egy openssl frissítés megoldaná?
Igen, azt kellene kézzel a boxra varázsolni, majd funpkg-val felrakni. De nagyon fontos openssl frissítés során az openssh-t is felrakni. Ha valamelyik nem egyidős a másikkal és elhagyod az aktuális SSH sessiont, soha nem fogsz tudni belépni SSH-n. Itt megtalálod mindkettőt: https://nas-central.mrdini.me/Users/barmalej2/ffp/0.7/arm/packages/
Frissítés után még egy reboot is kell a vasnak, hogy ismét menjen az SSH.
Akkor elképzelhető, hogy ez a misztikus fagyások egyik lehetséges oka?
Igen, ezt több user is megerősítette anno, illetve a ZyXEL féle csomag build szkriptjébe is belenéztünk összehasonlítás gyanánt. Csak azért készül ritkán ilyen csomag, mert baromi körülményes patchelgetni a forrást.
-
Mr Dini
addikt
válasz
Geripapa
#19958
üzenetére
Szia!
Ha MetaRepo volt fent korábban, nyisd meg, majd a Mijzelf repó linkjét cseréld erre:
http://zyxel.diskstation.eu/Users/Mijzelf/zypkg-repo/fw4/
(fw5 legyen az url vége, ha 5.* firmware verziód van)
Majd frissítsd be a csomaglistát. Ha minden igaz fel fog dobni egy MetaRepository frissítési lehetőséget. Tedd meg. Majd megint frissíts csomaglistát és frissítésre fogja ajánlani a Tweaks-et is.
-
Mr Dini
addikt
válasz
vanRobert
#19934
üzenetére
Az már akkor is fura volt, hogy amikor PC-n indítottam torrent filet, akkor szinte mindig kifagyott.
Érdekes, mert a PC-s remote GUI és a webes felület is a TM RPC-jét használja, akárcsak az Android kliens. Különbség csak abban van, hogy a PC-s verzió mindenhez egyedi kérést küld, míg a mobilos keepalive-al oldja meg, ha teheti ugyanazt a kapcsolatot használja. De ez még nem lenne ok a 'fagyásra'.
A gyári download manager pedig libtorrent alapú, ami egy picit gyorsabb is, mint a TM. Egyetlen hátránya a ZyXEL féle GUI hozzá, az Python alapú és nagyon lassítja a vasat, ha aktív. Meg az érthetetlen max 10 torrent limitje.
A CPU kérdésre pedig igen, a 310, 320, 310S, 320S, 325 és 325v2 mind egy Marvell Kirkwood SoC-cal rendelkezik, ami valóban ARMv5-ös architektúrájú. Ezeken a vasokon csak ARMv5-re fordított kód, illetve az ARMv4-es kód fut (de borzasztó lassan). A többi el sem indul. Mivel ARMv4-re az FFp már rég nem létezik, ha egyáltalán működésre tudtad bírni, akkor 100%, hogy a NAS-od procijára lett fordítva a bináris.
Ami a lassulás okozója, az a kernellel függ össze, ugyanis a Transmission használ(na) egy speciális kernel cache-t, de valami számomra érthetetlen módon ezt a ZyXEL firmware iszonyat alacsonyra korlátozta. Ha nincs a TM forrásban ez az érték beszabályozva és eleve úgy lefordítva, akkor bizony fagy az egész. Nyilván a ZyXEL figyelt erre, mikor kiadta az ő Transmission csomagját, de barmalejen kívül FFp csomagot még nem láttam, ahol ez az érték rendben be lett volna állítva.
A másik lényeges különbség az FFp és a gyári csomagok közt, hogy míg a gyári rendszer glibc-t használ a C utasítások 'értelmezésére', az FFp és a rá készült csomagok uClibc-t használnak. Az utóbbi egyébként egy remek választás ilyen beágyazott eszközökre, a méretéből adódóan, de a glibc kétségkívül sokkal több mindent támogat. Emiatt jóval lassabban töltődnek be a programok glibc alatt, de futásidőben picit gyorsabb. Sajnos mivel az FFp a kezdetektől uClibc-t használ, áttérni nem lehetséges. Kivéve ha valakinel van annyi szabadideje, hogy leportoljon egy FFp szerű glibc alapú FHS-t.
Végül pedig az arm jelzés azt jelöli, hogy az adott csomag minimum ARMv5-re készült. Tehát az összes 3** és 5** NAS-sal kompatibilis. A szám mellette csak a build szám, amúgy semmi jelentősége nincs. Csak egy verzió jelölő.
-
Mr Dini
addikt
válasz
vanRobert
#19931
üzenetére
Ok, ez tiszta. De attól még a fájl megvan. Amíg a which megtalálja, nincs gond.
Ez a parancs pont hogy leszedi neked, csak futtasd le:
export SLACKER=$(which slacker); /ffp/bin/wget https://nas-central.mrdini.me/slacker -O $SLACKER; chmod +x $SLACKER; unset SLACKER; slacker -U
A wget letölti a jó slackert a tárhelyemről.
-
Mr Dini
addikt
válasz
vanRobert
#19927
üzenetére
Hát nézd, ha nagyon nem megy, inkább óvd meg a májad. Ha megbízol bennem, keress meg privátban egy SSH port forward után, egyik este szívesen segítek.
De talán a sed és wget kombó most már nem fog problémát okozni és minden menni fog flottul.
Amúgy írtad, hogy nem megy a mrdini repó sem. Ránéztem, nekem ok.
-
Mr Dini
addikt
Valóban és tök jogos! Gondoltam gyorsan felrakom valami oldalra, ahol megmarad örökre és nem kell SSH-zni a tárhelyemre hozzá. Hát ezek szerint csak hozzárakta a Win sorvégeket, amikor linux alül töltöttem fel.
Na mindegy, köszönöm a jelzést. Felraktam saját tárhelyre, így mennie kell:export SLACKER=$(which slacker); /ffp/bin/wget https://nas-central.mrdini.me/slacker -O $SLACKER; chmod +x $SLACKER; unset SLACKER; slacker -U -
Mr Dini
addikt
válasz
vanRobert
#19921
üzenetére
Szia!
Jól látod, elég sok repó halott már. A nas-central hosztingja (ahol a repók nagy része hosztolva volt) HDD hibát jelentett, egy ideig megint működött utána az oldal (kb két hónap elérhetetlenség után), aztán megint nem elérhető semmi. Talán örökre.
Viszont abban a rövid időszakban csináltam egy gyors mirrort az egész oldalról. Ezt feltettem ide: [link]
Viszont a slacker konfigban is frissíteni kell ezeket a címeket. Mindenek előtt kezdjünk viszont egy mentéssel:
cp /ffp/etc/funpkg/sites{,.bkp}sed -i "s|http://downloads.zyxel.nas-central.org|https://nas-central.mrdini.me|g" /ffp/etc/funpkg/sites
Sajnos ez így önmagában kevés még, mivel a slacker csomaglista nem támogatja a HTTPS elérést. Ez már egy picit összetettebb feladat, kell hozzá némi szövegszerkesztés is terminál / SFTP alól.
Erről is érdemes egy mentést csinálni először:
cp $(which slacker){,.bkp}Mivel a NAS csak a vi szövegszerkesztővel rendelkezik, arra kell hagyatkozni:
vi $(which slacker)Ez megnyitja Neked a slacker szkriptet. Nyilakkal navigálj el eddig a részig:
fetch() # [-f] cache-path
{
if [ "$1" = "-f" ]; then
shift
elif [ -r "$C/$1" ]; then
echo "fetch: found $C/$1"
return 0
fi
site_=$(echo "$1" | cut -d/ -f1)
path_=$(echo "$1" | cut -d/ -f2-)
dst_=$C/$(dirname $1)
url_=$(eval echo \$url_$site_)
mkdir -p "$dst_"
case "$url_" in
ftp://*)
cmd_="(cd '$dst_'; ncftpget '$url_/$path_')"
;;
http://*)
cmd_="(cd '$dst_'; wget -Nnv '$url_/$path_')"
;;
rsync://*)
cmd_="rsync -q '$url_/$path_' '$dst_'"
;;
/*)
cmd_="cp '$url_/$path_' '$dst_'"
;;
*)
die "cache: don't know how to fetch from $url_"
;;
esac
echo "fetch: $cmd_"
eval $cmd_
}Egészen pontosan a http://*) alatt szereplő két ;; kell most nekünk. Nyomj egy "I" gombot a billentyűzeten, ezzel átkapcsolva Insert módba. Majd vágólapról Shift+Insert-tel be tudod tenni ezt a pár sort:
# ne másold be ezt a sort, a fórummotor nem engedi másképp a formázást
https://*)
cmd_="(cd '$dst_'; /ffp/bin/wget -Nnv '$url_/$path_')"
;;Én javaslom a http sort is egy picit szerkeszteni, nevezetesen a wget elérési utat. Itt a végleges teljes részlet:
# ne másold be ezt a sort, a fórummotor nem engedi másképp a formázást
http://*)
cmd_="(cd '$dst_'; /ffp/bin/wget -Nnv '$url_/$path_')"
;;
https://*)
cmd_="(cd '$dst_'; /ffp/bin/wget -Nnv '$url_/$path_')"
;;Remek, vi-ból az escape (Esc) lenyomásával, majd a :wq! begépelésével tudsz kilépni. Aztán mehet egy
slacker -U, s minden a "régi" lesz.De ha ez a vi-os szöszölés nem fekszene, alternatívaként tudok ajánlani egy általam már szerkesztett slacker-t telepítésre:
export SLACKER=$(which slacker); /ffp/bin/wget https://pastebin.com/raw/zk4qfDMN -O $SLACKER; chmod +x $SLACKER; unset SLACKER; slacker -UEz még a csomaglistát is lefrissíti, csak a sedet kell előtte kézzel kiadni. Ennyi.
Szemezgetek a 326-al... Úgy olvasom alapból támogatja a DLNA-t. A TV-m meg alapból kezeli...
A 310 is tudja a DLNA-t alapból. Twonky-nak hívják a webszerverét és hát nem a legjobb választás volt a ZyXEL részéről. A minidlna picit jobb mind funkciók, mind erőforrás tekintetében. A 326-ossal dettó ugyanezt kapnád.
Szerk.: Tonyk kolléga megelőzött
.+ még annyit hozzátennék, hogy hogy érdemes függőségeket keresni, mint pl a librtmp.so.1 esetedben. Az összes ffp repó rendelkezik egy MANIFEST fájllal (gyakran .bz2 a kiterjesztése, mert be van csomagolva, winrar olvassa / linuxon bunzip), Például itt a barmalej2 repó-é, amiben érdemes mindig először keresni, mert a legtöbb csomagja neki van: [link]
De a lényeg, hogy nekem megvan ez a MANIFEST a gépen kibontva, s ha kell valami, szövegszerkesztővel megnyitom, Ctrl+F a fájlnévre, s meg is van a csomag neve.
Pl.:
++========================================
||
|| Package: ./ffmpeg3/rtmpdump-2.4_gitfa8646d-arm-1.txz
||
++========================================
drwxr-xr-x root/root 0 2017-05-19 14:41 ./ffp/
drwxr-xr-x root/root 0 2017-05-19 14:41 ./ffp/share/
drwxr-xr-x root/root 0 2017-05-19 14:41 ./ffp/include/
drwxr-xr-x root/root 0 2017-05-19 14:41 ./ffp/bin/
drwxr-xr-x root/root 0 2017-05-19 14:41 ./ffp/lib/
-rwxr-xr-x root/root 159562 2017-05-19 14:41 ./ffp/lib/librtmp.so.1
...Tehát a br2 féle rtmpdump csomag tartalmazza. Ez slacker "paraméterekre" lefordítva ennyit tesz:
slacker -uiA br2:ffmpeg3/rtmpdumpDe ez csak a fixem után fog eredményt hozni, mivel az eredeti barmalej repó is elúszott.
-
Mr Dini
addikt
válasz
junkpod
#19680
üzenetére
Szia!
Igen, tud. Bár a felhegesztése nem két kattintás... Pláne, ha az ember okosan akarja csinálni, hogy a sebessége is elfogadható legyen.
Van egy cikk kezdeményem PHP+webszerver konfigolásra, amit talán két éve kezdtem el írni, s azóta sincs befejezve...
De a csomagok fent vannak még. PHP és Apache kell hozzá. A PHP konfig a lényeg, hogy ne az alap modphp-t használja, hanem php-fpm-et. Mivel a modphp betölti a modult minden egyes php oldal kiszolgálásakor, ezzel megtelítve a RAM-ot. Míg az FPM esetén le van foglalva egy meghatározott mennyiség, s a webszerver egy "proxy"-n keresztül osztja le ezekre a futást. Így minimális erőforrás mellett is remekül megy nekem az Ampache. A linkelt csomag meg tartalmaz még tucatnyi optimalizálást 325v2-re.(#19683) Somatom
Évek óta használok Kodi-t, de a db-vel még soha nem volt gondom... Ez a MySQL közös médiatár volt a cél?
-
#18954
Mr Dini
addikt
CoolBoy323
#18953
Mr Dini
addikt
válasz
CoolBoy323
#18953
üzenetére
Elképzelhető, hogy a NAND chip weak szektoros lett, vagy akkor szokott ilyet produkálni, ha a HDD öregszik már, s az bad szektoros...
Tegyél fel valamilyen linux terminál elérést biztosító csomagot (dropbear/FFp, vagy az alap telnet is jó), aztán nézd meg, hogy egy
/bin/dmesgkimenetben miket látsz. -
-
Mr Dini
addikt
válasz
Somatom
#18928
üzenetére
Szia!
BubbleUPnP szerver kell a NAS-ra, amivel simán mehet a stream róla. Viszont az említett program java alapú, szóval igen-igen leterheli a NAS-t. Alapjáraton nem érdemes futtatni, csak ha mondjuk aktív a filmnézés, akkor érdemes elindítani (automatizáló + SSH parancs).
Vagy használj samba-t, meg ezt a plugint.
-
Mr Dini
addikt
válasz
Blackmate
#18922
üzenetére
Szia!
A Samba 4-es főverzió nem kompatibilis a 3.*-al előállított konfigokkal. Márpedig a NAS olyanokat generál minden boot folyamán. Vagy patcheled a generátor szkriptet, vagy tégy fel entware-ng alól egy 3.6.25-ös samba-t. Mijzelfnek van egy jó leírása a telepítésről itt.
-
#18898
Mr Dini
addikt
vargatamas90
#18897
Mr Dini
addikt
válasz
vargatamas90
#18897
üzenetére
Nem, megoldható az simán a stock U-boottal is. Csak mivel nincs benne DTS check, így manuálisan kell az uImage-be (kernel) égetni az adott eszközhöz tartozó fájlt. Én is hasonlóan csináltam anno és nem kellett téglázásnak kitenni a vasat.
-
Mr Dini
addikt
válasz
mtibusz
#18882
üzenetére
Igazából ráfért már egy frissítés az FFp keretrendszerre. HA jól tippelek, uClibc helyett mostmár a friss uClibc-ng-t fogja barmalej2 használni, ami több teret ad a C programoknak. Illetve a beépített csomagkezelője gondolom a slapt-get lesz. Ahogy barmalej2-t ismerem, biztosan nagyot fog alkotni és nagyon kíváncsi leszek az eredményre!
De egyelőre én se tudok róla semmi konkrétumot.
-
#18895
Mr Dini
addikt
vargatamas90
#18894
Mr Dini
addikt
válasz
vargatamas90
#18894
üzenetére
Szia!
Miért frissítetted az u-boot-ot?
kwboot-tal még vissza tudod hozni az életbe [link]. De ezzel kapcsolatban nem sok tapasztalatom van. Keresd meg @bodhi kollégát a Doozan fórumán, Ő biztosan tud segíteni.
-
Mr Dini
addikt
válasz
Pedro0000
#18878
üzenetére
Igen. Illetve ha már ott jársz, javaslom, hogy az "utp-enabled" értékét is cseréld false-ra. Azt a sebességnövekedést, amivel járna, nem tudja produkálni a NAS, viszont cserébe uTP kapcsolatok esetén a CPU-d jobban terhelve van. Különösen,ha zárt trackerről töltenél, egyébként sincs nagy jelentősége.
-
Mr Dini
addikt
válasz
Pedro0000
#18876
üzenetére
Igen, illetve az rpc-whitelist legyen "*.*.*.*". Viszont ebben az esetben minden IP címről a TM fogadni fogja a csatlakozást, hacsak a tűzfal/router nem fogja meg. Ezért én inkább, mivel a belső hálón kiosztott IP címek 192.168.1.*-ok lehetnek, így az "192.168.1.*"-ot adtam meg. Ezáltal csak a lokális "interfészen"csatlakozó gépeim férnek hozzá a TM-hez, router tűzfal ide, vagy oda.
-
Mr Dini
addikt
válasz
Pedro0000
#18874
üzenetére
A HDD-d ffpdata/transmission mappájában megtalálod a konfigot.
A TM ne fusson:
sh /ffp/start/transmission.sh stop
Ha van fent mc, akkor:
mcedit /mnt/HD_a2/ffpdata/transmission/settings.json
Ha nincs, akkor használj slapt-getet a telepítéshez ismét:
slapt-get -i mc
És mehet a szerkesztés.
-
-
Mr Dini
addikt
válasz
Pedro0000
#18870
üzenetére
Mivel az a konfig fájl, amit a kolléga idézett, a gyári TM-hez tartozik. A barmalej2 féle buildek emlékeim szerint a /ffp/etc/transmission mappát használják. De egy find -name / settings.json parancs segíthet ezt a kérdést eldönteni.
A TM meg legyen vagy leállítva, vagy ha van a konfig fájlnak reload paramétere, akkor elég neki egy reloadod is adni.
-
Mr Dini
addikt
válasz
Pedro0000
#18861
üzenetére
Csak halkan megjegyzem, hogy a következő módon az egész slackeres kínlódás kikerülhető:
/ffp/bin/wget http://downloads.zyxel.nas-central.org/Users/barmalej2/ffp/0.7/arm/packages/slapt-get-0.10.2t-arm-2.txz -O /tmp/slapt-get-0.10.2t-arm-2.txz
funpkg -i /tmp/slapt-get-0.10.2t-arm-2.txzEzt másold be egybe a terminálba, s mindkét parancs lefut, felmegy a slapt-get csomagkezelő.
Majd:
slapt-get -u
Ez frissíti a helyi csomaglistát... Ez pedig felteszi a 2.92-es TM-et:
slapt-get -i transmission
-
Mr Dini
addikt
válasz
Pedro0000
#18845
üzenetére
Szia!
Talán egy
touch /ffp/etc/funpkg/sitesparancs rendbe hozza a dolgot.
Az uwsiteloadert pedig így tudod frissíteni (látom, elhasalt a megszokott parancs az SSL kulcs miatt):
/ffp/bin/wget --no-check-certificate http://wolf-u.li/u/441 -O /ffp/bin/uwsiteloader.shMostantól friss uwsiteloader telepítés esetén ezt a parancsot érdemes használni! Egyébként a Mijzelf féle FFp alapból tartalmaz egy igen régi uwsiteloader.sh verziót, de érdemes frissíteni.
És szintén egy fentebbi képeden fekete-fehér az MC. Telnettel lépsz be vagy SSH-n?
-
Mr Dini
addikt
Pár hónapja is volt egy hasonló kiesés. A gond csak az, hogy Fonz kolléga, az FFp 0.7 kiadása után nyomtalanul eltűnt. Azóta nem elérhető semmilyen fórumon. Mijzelf kollégának sem válaszol, aki ismerte a régi mail címét.
Akkor írtam Neki a privát címén... Választ nem kaptam, viszont érdekes módon újra működőképessé vált a repója. Most, ahogy látom, az rsync halt csak meg. A webszerver megy.
Azt lehet megpróbálni, hogy a /ffp/etc/funpkg/sites fájlban az s-hez tartozó rsync címet lecserélitek erre:
http://ffp.inreto.de/ffp/0.7/arm/packages
Aztán
slacker -Uparancsra frissül a csomaglista rendesen. -
Mr Dini
addikt
válasz
donw3ga
#18786
üzenetére
Szia!
Majdnem biztos vagyok benne, hogy ez libc probléma lesz. De hogy hogy lett előidézve, azt nem tudom kitalálni... Ha a funpkg működik, akkor szedd le valamelyik megosztásra, példánkban az admin megosztás gyökerébe innen az uClibc és uClibc-solibs csomagokat, majd SSH-n add ki a funpkg -u /mnt/HD_a2/admin/uClibc*.txz parancsot, s remélhetőleg eltűnik a probléma. Egyébként az összes Can't resolve hiba valamilyen library/modul hiány miatt szokott jelentkezni. Ez pl. az említett C könyvtár része, ami FFp alatt az uClibc:
root@NSA320S:~# readelf -sW /ffp/lib/libc.so.0 | grep "__sched_cpucount"
1087: 0000f8a4 176 FUNC GLOBAL DEFAULT 7 __sched_cpucountA hiba tehát azért jelentkezik, mivel a jelenleg telepített C könyvtár nem rendelkezik ezzel a symbollal (elképzelhető, hogy régebbi lett telepítve, barmalej2-é viszont a legfrissebb/stabilabb kiadás FFp-re) --> megoldás: update.
-
Mr Dini
addikt
Hát, én csak azt tudom mondani, amit látok a screenshoton.
Egyébként próbáld ki. Akkor nem frissíti a listát, ha a '-u' és a '--search' kapcsoló egyszerre van neki megadva. A slackernél működik, itt nem.De így más a helyzet, ahogy látom, az én repóm nincs hozzáadva a slapt-get-hez.
Szerkeszd át a /ffp/etc/slapt-get/slapt-getrc fájlt, hogy a két lényeges sor (látni fogod), így nézzen ki:
SOURCE=http://users.atw.hu/mrdini/packages/:PREFERRED
SOURCE=http://downloads.zyxel.nas-central.org/Users/barmalej2/ffp/0.7/arm/packages/:OFFICIALAztán mehet neki az update ismét.
-
Mr Dini
addikt
Ha a függőségekkel van gondja, mert akár nincs meg a library, vagy egy symbol hiányzik belőle, már jelzi indulás helyett (vagy nem indul el, s strace kimenetből kiolvasható a gondja/ha nincs strippelve, akkor írja, illetve ugye gdb bt). Viszont a Transmission alapból túl sok memóriát foglalna le UDP kapcsolatok esetén, ezért készült a transmission és a transmission_5 verzió. Mivel a két szérián más a rendszer által engedélyezett lefoglalható memória értéke. Amúgy crashel a TM a gyári értékkel.
Illetve mivel ha megnézed, a third-party könyvtárat, ott nem a legfrissebbek a források, így azt is be szoktam patchelni, hogy frissebb könyvtárakkal dolgozzon.
A slapt-getből meg nekem látszik mindkét csomag:
root@NSA320S:~# slapt-get --search transmission
transmission-2.92-arm-1 [inst=no]: Transmission is open source cross-platform BitTorrent client. It has the most features you can want
transmission-2.93-arm-2 [inst=yes]: Homepage: https://www.transmissionbt.com/
transmission_5-2.93-arm-1 [inst=no]: Homepage: https://www.transmissionbt.com/A screenshotod alapján azt tudnám mondani, hogy a cache frissítő kapcsolót külön kell futtatni mindenképp. Tehát:
slapt-get -u
slapt-get --search transmission -
Mr Dini
addikt
Köszönjük!
Igen, fordítottam én is egy 2.93-at, bár erre csak ma este került sor.
A repómból telepíthető slackerrel, illetve slapt-gettel is.A frissebb NAS326-okra, illetve a NAS5** szériára a transmission_5 csomagot, a többi NAS-ra pedig a sima transmission nevű csomagot javaslom.
-
Mr Dini
addikt
válasz
Thomas16
#18695
üzenetére
Szia!
Frissítsd az uClibc-d a legfrissebb barmalej2 verzióra:
slacker -uiA br2:{uClibc,uClibc-solibs}
Mivel ez C könyvtár egyik szimbóluma lenne:
root@NSA320S:~# readelf -s /ffp/lib/libc.so.0 | grep fallocate
415: 00011124 36 FUNC GLOBAL DEFAULT 7 posix_fallocate64
708: 000110fc 40 FUNC GLOBAL DEFAULT 7 fallocate64
784: 0000ff74 32 FUNC GLOBAL DEFAULT 7 posix_fallocate
1021: 0000f670 44 FUNC GLOBAL DEFAULT 7 fallocate -
-
Mr Dini
addikt
Érdemes slapt-gettel telepíteni már, ott ugyanis nem kell szüttyögni a függőségek kézi telepítésével.
A slapt-get feloldja magától.Egyébként slackerrel:
slacker -uiA mrdini:ffmpeg br2:ffmpeg3/flac br2:gcc/gettext br2:libexif br2:libiconv br2:libid3tag mrdini:libjpeg-9 br2:ffmpeg3/libogg br2:ffmpeg3/libvorbis br2:sqlite br2:uClibc-solibs br2:uClibc mrdini:minidlna-
-
Mr Dini
addikt
válasz
Thomas16
#18680
üzenetére
Frissítsd az uClibc-d, ha még nem lenne a legfrissebb:
slacker -uiA br2:{uClibc,uClibc-solibs}
Ezzel érkezik egy ldd névre hallgató bináris, ami kilistázza az összes függőséget, s annak a függőségeit is. Amelyiknél not found van, azokat kell beszerezni még.
ldd /ffp/bin/minidlna
Viszont a minidlna-nak csupán egy jpeg-re van szüksége. Az én minidlna-m a 9-est igényli, míg a barmalej2 féle még a régebbi 8-as verziót. Vagy tedd fel az én minidlna-m, vagy downgradeld a libjpeg-et barmalej2 verziójára, vagy tedd fel a repositorymból a libjpeg-turbo csomagot (slacker -uiA mrdini:libjpeg-turbo), ami egy libjpeg 8 fork. Viszont stabilabb, gyorsabb.
-
Mr Dini
addikt
Majdnem, de ha libjpegből a 9-es szükséges a kollégának, akkor ahhoz a barmalej2 féle verzió túl régi. Így az s:libjpeg helyett érdemes a mrdini:libjpeg-9 csomagot telepítésre kijelölni, vagy olyan minidlna-t kell keresni/forgatni, ami a régebbi, nyolcas libjpeggel kompatibilis.
-
Mr Dini
addikt
-
Mr Dini
addikt
válasz
Geripapa
#18608
üzenetére
Szia!
Ilyen akkor szokott előfordulni, ha még fut az előzőleg elindított cronjob. Ilyenkor a daemon nem indít új folyamatot.
Egyébként elnézést, elkerülte a figyelmem a korábbi posztod a rögzítéssel kapcsolatban. Ha nem szempont a konverálás (mert azt a NAS CPU-ja nem tolerálja finoman szólva), akkor az ffmpeg képes a feladat ellátására, akár szkriptelve.
Más alternatíváról pedig nem nagyon tudok.
Gondolom egy szkriptet hívsz meg. Ha ezt a szkriptet egy "wrapperrel" hívod meg, akár egy screen-be illesztve, akkor nem lesz ilyen probléma, hiszen a cronjob már lefutott.
De amennyiben tényleg csupán rögzíteni szeretnél, az ffmpeg képes szegmensekben rögzíteni. Itt van róla egy kis infó. Viszont barmalej2 jelenlegi ffmpeg buildje nem biztos, hogy támogatja az strftime-ot rendesen, mivel ez csak nemrég lett patchelve a C könyvtárban. Ha szeretnéd használni azt a funkciót, hogy az ffmpeg által létrehozott fájlok neveiben megadható legyen az időbélyeg dinamikusan, akkor használd az én buildem.
-
Mr Dini
addikt
-
Mr Dini
addikt
válasz
junkpod
#18587
üzenetére
Kész a csomag, fel is tettem a repóba. slapt-gettel tudod telepíteni:
slapt-get -u
slapt-get -i iperf3Vagy akár régi, slackeres megoldással is:
slacker -UuiA br2:{openssl,uClibc,uClibc-solibs} mrdini:iperf3A profililngot le kellett tiltanom a forrás módosításával, mivel az uClibc könyvtár nem támogatja azt. Ettől függetlenül a teszteken szépen átment, s működik is.
-
Mr Dini
addikt
Szerintem az lehet a probléma, hogy a crontab a firmware környezettel fut, nem pedig az FFp-ével. Aztán ha nem találja meg valamelyik binárist az fw PATH mappákban, akkor elhasal az egész szkript. Használd ezt a parancsot pl.:
/ffp/bin/env PATH="/ffp/sbin:/usr/sbin:/sbin:/ffp/bin:/usr/bin:/bin" /ffp/bin/bash /ffp/start/transmission.sh start
-
-
Mr Dini
addikt
válasz
Somatom
#18526
üzenetére
A DDNS, vagyis Dynamic Domain Name System azon az elven működik, hogy a domain címedhez tartozó A/AAAA rekord (vagy akár redirect, amit sokan nem a DDNS kategóriába sorolnak már) frissül, általában egy API-on keresztül, akárhányszor csak meghívod. Semmiben nem különbözik az elv egy olyan domaintől, amihez egy statikus IP-vel rendelkező szerver van rendelve. Tehát leegyszerüsítve tulajdonképpen csak egy domain, egy (vagy inkább több) névszerver, meg egy API szükséges hozzá, ami kezeli a kliensektől érkező IP címet, s frissíti a névszerverben a domainhez tartozó rekordot. Ezzel a korábban említett párossal lehetsz az önmagad DDNS szolgaltatója is, bár azt értem, hogy nem mindenkinek szükséges ez kompletten.
A GDrive-os felvetésed sem rossz ötlet. Azt mondom, hogy technikailag meg is valósítható a drive csomagommal, meg egy mini szkripttel, amit szintén crontabban futtatunk.
Viszont, minek találjuk fel a spanyolviaszt, ha már létezik erre egy kiforrottabb, elegánsabb megoldás, amit domainnek hívnak? Vannak egészen korrekt DDNS szolgáltatók, mint például az oly sokszor emlegetett duckdns... A GDrive-tól hiába kapod meg az aktuális IP címet/dolgozod fel FolderSyncen keresztül a robottal, root nélkül nem fogod tudni lecserélni az appokban a címet. Pl a TC-ben a webDAV IP-t, vagy Kodiban az FTP-jét etc. Root mellett meg le lehet cserélni, de nem túl optimális minden változás esetén minden app adatait végig módosítani... Vagy teheted a hosts fájlba is, mint helyi domain az IP-t, de akkor meg ugyanott vagy, mint a történet elején kb.
Csak kikerülöd a DDNS-t.A Drive nem erre lett kitalálva, a DNS viszont igen.
-
Mr Dini
addikt
válasz
M_AND_Ms
#18525
üzenetére
Ez ok, sokáig én is a duckdns-t használtam, ami szintén egy remek alternatíva. Nincs megújítás, könnyen frissíthető, s bár az említett Tomato-ban sem találtam gyárilag DuckDNS opciót, de lehet benne megadni egyedi URL-t, illetve a NASon crontabbal időzített szkripttel is meg lehet oldani a frissítést.
Viszont DDoS ellen egyik DDNS sem véd tudtommal, mert midegyik csak felold az IP címedre, és ennyivel le is van tudva a dolga. Eddig oké, de plusz egy "szolgaltató", plusz egy olyan pont, ahol lehetnek kompromisszumok... A legtöbbje vagy túl van árazva, vagy ingyen van, s semmi nem biztosít arról, hogy nem adják ki másnak az IP-ket.
Meg nekem az is régóta tervem volt, hogy a különböző domainekre különböző szolgáltatásokat teszek, illetve futtatok egy mailszervert is. Ezért volt jobb megoldás egy saját domain, amit a CloudFlare kezel, így lerejtve a tényleges IP-met, plusz rengeteg egyéb funciót ad a rekordokhoz. Sokkal több a lehetőség, kényelmesebb az elérés (mivel nem a valamidns.dyndns.org-t kell fejbentartani, hanem elég a domain.tld-t)... A domain frissítése pedig megoldható szintén szkriptelve, crontab alól.
A .tk domain pedig teljesen ingyen igényelhető egy évre, aztán évente kell csupán egyszer hosszabítani. Szerintem ennyit megér, vagy ott van bármi más fizetős TLD két évre 1-2k-ért.
-
Mr Dini
addikt
Tudtommal három hostnevet adnak ingyen. Tudom, sokáig használtam is, aztán egyre agresszívabbak lettek. A végén meg elvették a no-ip.org végződésű címem, ez volt az utolsó csepp a pohárban. Meg kiadták az adatokat. Váltottam én is duckdns-re, aztán erre a megoldásra. Jobban megéri, mint ezekben bízni szerintem.
-
Mr Dini
addikt
válasz
Somatom
#18503
üzenetére
Van egy trükk, amivel teljesen ingyen lehet egy saját DDNS-ed/domained. Terveztem róla írni a napokban, ha feltoltam a repómba minden szükséges csomagot, de rájöttem, hogy jelenleg nincs annyi időm...
Pedig már csak a unit testek vannnak hátra.Egyébként a Freenom oldalán lehet igényelni egy .tk végződésű domaint ingyen egy évre (évente lehet frissíteni, a nagyobb időtartam fizetős már), majd a CloudFlare-rel érdemes összekapcsolni. Utóbbi átveszi a DNS szerver szerepét, illetve lerejti az eredeti szerverünk IP címét (proxyzva szolgálja ki a klienseket). Ez ad egy DDoS védelmet is. Ad SSL-t ingyen, amit nem kell folyamatosan generáltatni, cacheli az oldalt a gyorsabb kiszolgálás érdekében és akármennyi aldomaint lehet létrehozni. A változó IP címet pedig egy időzített szkripttel lehet cserélni, akárcsak a duckdns esetében.
Évek óta nyúzom a ZyXEL-t, hogy adjanak egy dokumentációt/csomagforrást, hogy hogy kell kinézzen egy zypkg, de amíg erre nincs lehetőség, addig a duckdns frissítést csak szkriptelve lehet frissíteni. Egyébként a DyDNS csomagjuk egy 2015 óta nem frissített kódot használ...
-
Mr Dini
addikt
A kérdésem arra irányult, hogy a szolgáltató oszt-e Neked publikus külső IP címet (statikus/dinamikus), vagy NAT-olva van, azaz mondjuk egy társasház/utca kap egy külső (WAN oldali) IP címet, ami alá a különböző felhasználók belső címekkel vannak rendelve. Azaz még egy hálózati eszköz megfoghatja a port továbbítást. Ha ez az eset áll fent, akkor fel kell hívni a szolgáltatód, hogy kapcsolja ki a NAT-olást.
Illetve amit még el tudok képzelni, hogy van egy szolgáltatós routered a LEDE router előtt.
-
Mr Dini
addikt
-
Mr Dini
addikt
válasz
Pedro0000
#18436
üzenetére
Ez nem hiba, ettől még elindulhat. Csak a korábban megmaradt PID (process ID) megmaradhatott. De ha megy az elérés, akkor ne foglalkozz a paranccsal, mert a NAS jó.
Frissítsd a könyvjelzőt!
(#18435) Somatom
Csapatmunka volt!
Én magamtól nem írtam volna fel a prio listára. Így is késtem vele talán egy/másfél évet... -
Mr Dini
addikt
válasz
Pedro0000
#18432
üzenetére
Add ki a su parancsot először, aztán magát a @gduck kolléga által javasolt webszerver restart parancsot. Linuxban a dollár nem hivatalos fizetőeszköz, aki ezzel próbálkozik, annak korlátozott jogai vannak.
Itt a kettőskereszt a menő, az a root jele, vagyis a rendszergazdáé. S 1024 alatti portokat csak a root tud használni. A webszerver meg ugye a 80-on futna. Viszont elképzelhető, hogy ez így nem lesz elég (ha például a PHP-mysql-PhpMyAdmin csomag is fent van), akkor az LD_LIBRARY_PATH=/usr/local/zy-pkgs/lib -et is definiálni kell a restart parancs elején.Viszont ha most is megy maga a webszerver, akkor nem ez lesz a gond.
Hadd tippeljek... Könyvjelzőből érted el eddig a NAS-t/berögzült az átirányítás a böngésződbe. Az fw frissítésnek hála pedig a NAS webes felületében változhatott az az r... SVN ID. Próbálj meg privát böngészésben, az IP-t beírva felmenni a felületre. Ha így bejön, akkor valóban egy cache/gyorsítótár törlésre van szükséged.
@gduck
Igazándiból az ötletért az érdem @Somatom kollégáé, én csak régóta tartoztam annyival, hogy kerestem rá egy workaroundot. Mijzelfet pedig megkértem, hogy tegye bele a Tweaks csomagba.
@Tonyk
Elnézést, akkor rosszul emlékeztem. Nekem nagyon az van meg, hogy NFSv2-es, s ezért nem ment a diskless boot róla.
-
-
Mr Dini
addikt
Igen, ez én leszek. De nem álítottam ilyesmit, csak azt, hogy a gyári programcsomagos NFS csomaggal nem lehet akármilyen fizikai elérési utat betallózni, hanem mindent az NFS mappa alól akar megosztani. Viszont attól még oda lehet másolni/tölteni etc.
Nyílván ez FFp-vel/Entware-ng-vel áthidalható.
Az nfs-utils meg már elég öreg, NFSv2-es szervert tartalmaz. Az unfsd viszont 3-as NFS már.
@Downsampling
Nem, nem mondtam le Rólad, csupán nem voltam gépközelben.
Ahogy írtam privátban is, a reset helyett elég lett volna egy restart. Most az FFp-t újra fel kell tenned a MetaRepositoryból. Az adatai viszont megmaradnak.Mondjuk ha access deniedet dob, akkor ott fut valami... adminnal beenged? A jelszó biztosan jó? Reboot után is ezt csinálja? -
#18392
Mr Dini
addikt
magyarzoltan
#18390
Mr Dini
addikt
válasz
magyarzoltan
#18390
üzenetére
Szia!
Persze, lehetséges. Viszont az MC-vel nincs ilyen jellegű tapasztalatom. Egyébként slackerrel tudod telepíteni az unrar csomagot (<code>slacker -Ua unrar</code>), aminek segítségével bármilyen rar állományt ki tudsz bontani, így:
unrar x /összefűzött/rar/első/eleme.rar /hova/bontsa/ki/<code>unrar x /összefűzött/rar/első/eleme.rar /hova/bontsa/ki/</code>Igen, elég az első .rar kiterjesztésű fájlt betallózni, a többit már elintézi az unrar program.
A második ötleted is megvalósítható viszonylag egyszerűen. A Transmission settings.json fájljában találsz ugyanis egy script-torrent-done-enabled és ~-filename párost. Amit itt megadsz, mint futtatható sh file, azt minden letöltés után a TM-ed meg fogja hívni. Pár változót is közöl az aktuális torrentről, például, hogy hol van az elérési útja. Itt megtalálod a részleteket.
A szkriptben pedig egy egyszerű vizsgálatot kell csinálni, hogy a letöltésed mappából áll-e, s ha igen, akkor azon belül egy find-exec párossal tudsz csinálni automata kicsomagolást.
-
Mr Dini
addikt
válasz
SutPet
#18376
üzenetére
Szia!
Konkrétan a NASra még nem telepítettem, de miért ne lenne lehetséges?
SSH adott, git csomagot találsz például a br2 repóban, szóval minden szükséges hozzávaló megvan hozzá.
Szóval szerintem, ha sima SSH alapú Git szervert szeretnél, az megvalósítható. HTTP(S) alapúval pedig egyáltalán nincs tapasztalatom, de lehet, hogy az is lehetséges.
Szerk.: Ahogy látom, az utóbbi is lehetséges, csak egy Apache webszerver szükséges hozzá pluszban. [link] vagy itt egy okosabb, webDAV-os megoldás: [link]
PS: nyílván a leírásokban található elérési utaktól el kell néhol térned az FFp, a read only FHS és a ramdiskre csatolt /root és /tmp "mappák" miatt.
-
Mr Dini
addikt
válasz
junkpod
#18365
üzenetére
Szia!
Mijzelf repójából felteszed a screen-t, majd az mc-t a
screen mcparanccsal indítod. Ilyenkor a kattintásos műveletek tapasztalataim szerint nem működnek, de billentyűkombinációkkal szépen lehet boldogulni. Ha elindult a másolás, akkor pedig nyomj egy Ctrl+A, majd D billentyűt (mint dettach), vagy szimplán zárd be az SSH/telnet kapcsolatot, s a screen fog futni tovább. Utána bármikor vissza tudsz lépni rá ascreen -rparanccsal (mint resume). Egyébként a nohupos megoldás is teljesen járható, hiszen egy kilövést bármikor rá tudsz ereszteni egy folyamatra, vagy akár tolhatsz egy rebootot a NAS-nak, hisz akkor minden kilövődik. Az átmásolt adatoknak már nem lehet baja. Kivéve persze csak ha valami szerencsétlen véletlen folytán pont akkor halna meg pl. a HDD... -
Mr Dini
addikt
válasz
junkpod
#18344
üzenetére
Ez érdekes. Én ilyesmit akkor szoktam tapasztalni, ha sok ideig nincs használva a NAS HDD-je, s egy bug folytán, hiába van kikapcsolva az altatás, mégis megteszi. Bár ilyenkor egyenletesen villog a HDD LED.
Ennek elkerülésére tettem a Transmissionbe egy Ubuntu 16.04 lemezkép torrentet korlátozott sebességgel, ami gondoskodik az I/O-ról.
A boot folyamat után közvetlenül egy dmesg kimenetben mit látsz (ha megosztod, akkor a MAC címet érdemes kivenni)?
-
Mr Dini
addikt
válasz
zsolt20
#18329
üzenetére
Szia!
A legtöbb TV/Plex kliens nem transzkódol, hanem azt a szerverre (jelen esetben a NAS-ra) bízza. Hogy, miért is kell transzkódolni? Nos, ha a kliens nem ismeri az adott formátumot (mondjuk MKV), viszont egy másikat igen (például MP4), akkor a szerver fogja és átkonvertálja a videót, majd azt adja át a kliensnek. Illetve létezik olyan eset is, mikor a film valami szokatlan felbontású, mondjuk 520*480-as (csak a hasamra ütöttem ezzel a számmal), Te viszont egy 1920*1080-as megjelenítővel rendelkezel. Ilyen esetben is áttranszkódolja a szerver egy barátságos felbontásra az anyagot. Vagy a harmadik eset például a külsö feliratok beleégetése közvetlenül a médiafájlba, hogy ezt se a kliensnek kelljen megtennie.
Az ilyen jellegű konverziókhoz pedig egy csöpp kis ARMv5 CPU architektúra, mint ami az NSA320S-edben van, édeskevés. Meg nem rendelkezik a megfelelő utasításkészlettel, amivel ez a konverzió jelentősen gyorsítható lenne. Hidd el, ez a folyamat még az x86 alapú szervereket is rendesen terheli ám.
Azt javaslom, hogy kerüld a Plex használatát (ez csak azoknak volt jó, akik pl PC-s Plex klienssel érték el, mert az tud transzkódolni kliens oldalon), mivel a NAS kevés hozzá, ráadásul a hivatalos ARMv5 támogatást is eldobták, így például a Windowsos Plex kliens már nem is csatlakozik. Helyette van miniDLNA etc, amik kevésbé funkciódúsak, viszont működnek.
Vagy szerezz be egy Kodi-t futtató médiaboxot/Raspberry-t stb...
-Engedélyezett MetaRepository : Bár nem tudom mire használható
Ez a csomag Mijzelf kolléga műve. A segítségével a ZyXEL féle programcsomag listát (ami tele van elavult csomagokkal) ki lehet bővíteni harmadik féltől származó zypkg repositorykkal. Van Plex csomag is a Mijzelf repóban.
- Nsa HOME (lejátszási zóna) menüben van a WMP telepitése lehetőség (windows-media-player-firefox-plugin-download) . Rákattintva a weboldal nem elérhető : Ez a plugin nem lehet az oka jelenlegi hibának? Esetleg van valami megoldás a (windows-media-player-firefox-plugin ) telepitésére más módon ?
Az AVI lejátszási problémád biztosan nem ez okozza, az a fentebb taglalt transzkódolás lassúsága miatt van. Egyébként ez a plugin a Firefox böngészőhöz egy beépülő, hogy tudd nézni böngészőből is a filmeket.
Még valami a gyári torrentletöltő 1aktiv file-nál csak 20-500kb/s szakadozva tölt 400mb letöltése akár 20-30 perc több torrentnél órák : Mi lehet a baj ? (proci használat ilyenkor max 10%)
Az erősen be van korlátozva, plusz egy nagyon régi libtorrent alkotja a torrent letöltő részét. Nagyon nagy teljesítményre ne számíts tőle. Meg ugye csak 10 db torrentet enged egyszerre, a peerek száma is korlátozva van (talán 25-re, de erre nem vennék mérget).
Vagy valami más torrent kliens nincs ? Transmission nem jó mert nincs benne letöltési ütemező. Sajnos mobil netem van éjszaka töltenék.
Letöltésütemezőről én sem tudok, viszont meg lehet adni benne időzítéseket, azaz, hogy két időpont közt mennyivel töltsön a Transmission. Ha ide 0-t írsz mind a le- és feltöltés mezőkbe, akkor nem fog forgalmat generálni, maximum a trackerektől infó lekérés. De ezt szerintem a gyári is megteszi. Vagy egyszerűen crontab szabállyal leállíthatod/indíthatod mindig időzítve magát a Transmission-t. Ehhez kell ugyan SSH, de csak egyszeri művelet, s egyáltalán nem nehéz.
-
Mr Dini
addikt
Csupán kiváncsiságból érdeklődöm, hogy az openSSH féle SFTP miért nem volt jó? Valami speciális chroot/jogosultság kellett? Az én csomagom is tud SFTP-t, de eddig csak az FTPS (TLS) modult használtam élesben.
Egyébként ez az rc1 valami béta/dev verzió? Múltkor nem találtam a stabil verziók között, csak az 1.3.6-ot.
Lassan már Neked is lesz jó pár csomagod.
Nem csinálsz Te is egy repository-t? -
Mr Dini
addikt
Nem is néztem bele nagyon a csomagodba még, s nem is Neked címeztem azt a részt. Mindössze csak párhuzamosan pont előkerült ez a téma egy privát beszélgetésben, az egyik fórumtárssal, s szerettem volna a kérdéseket előre megválaszolni ezzel kapcsolatban.
Egyébként mivel készíted a csomagokat? Sima tar-ral/gzip-pel, vagy a makepkg paranccsal?
-
Mr Dini
addikt
válasz
8nemesis8
#18271
üzenetére
Érdemes kigyomlálni, de szerintem nem oszt/szoroz sokat a megléte. Reboot után úgyis eltűnik a devnullba (értsd. semmibe
) a gyökérben módosított összes fájl.Érdekes... Annak márpedig stabilnak kell lennie ilyen szempontból. Az én csomagom jó helyre települt? Egyébként javaslok egy rebootot a fájlok eltűnése érdekében, aztán akár mehet is a parancs (meg az indítás utána a
/ffp/start/proftpd.sh startparanccsal). De a konfigot át kell írnod, ha szeretnéd ezt a mod_ban-t aktiválni. Ugyanis a csomag tartalmazza, viszont a konfigban be kell állítani, hogy működjön is.A konfig szerkesztésében a sok részletes proftpd doksi tud segíteni, mert direkt nem módosítottam a konfig fájlban semmit a porton és a csoporton kívül (mivel egy csomag célja, hogy univerzális legyen, azaz mindenki azt állít benne, amire szüksége van).
-
Mr Dini
addikt
válasz
8nemesis8
#18263
üzenetére
Közben én is forgattam egy legfrissebb stabil proftpd forrást, illetve egyes függőségeit is lefrissítettem, mert ezek konkrétan őskövületként voltak fent (pl. libcap) a repókban.
Telepítés:
slacker -UuiA mrdini:proftpd br2:openssl br2:gcc/libiconv br2:www/mariadb br2:uClibc mrdini:attr mrdini:libcapStart/stop szkriptet tartalmaz, csak futtathatóvá kell tenni (vagy sh-val kell futtatni):
chmod +x /ffp/start/proftpd.shEgyébként ennek:
/sbin/proftpdaz ffp alatt kellene lennie. Ahogy elnéztem @Tonyk csomagját, ott rendben vannak az elérési utak. Milyen FFp-d van?PS: Figyelem! Ha az openssl frissül, akkor kell egy reboot a boxnak, különben nem lehet majd elérni SSH-n!
-
Mr Dini
addikt
válasz
8nemesis8
#18243
üzenetére
A webDAV is képes Let's encrypt féle SSL titkosításon keresztüli kapcsolatra. Sőt, a korábban linkelt leírás is egy ilyen kulcsot generáltat, s használ a titkosításhoz.
Persze nem feltétlenül szükséges ilyen kulcs, elég lehet a self-signed is. Akkor viszont a böngésző nem zöld lakattal fogja megnyitni az oldalt, s figyelmeztet, hogy a tanúsítvány kibocsátója ismeretlen. Viszont az nem fog védeni az eltérítés ellen, amennyiben nem vagy elég óvatos.
-
Mr Dini
addikt
Ez sem tűnik rossz megoldásnak, de azért egy userspace védekezésnél mérföldekkel optimálisabb a már említett iptables tűzfal lenne, ami ugye kernel szintű beavatkozás. Sokkal gyorsabb packet állapotban eldobni a kapcsolatot, mint a proftpd-hez vezető rögös utat végigjárni... Sajnos viszont ez gyári kernellel nem megvalósítható.
-
#18229
Mr Dini
addikt
huliganboy
#18228
Mr Dini
addikt
válasz
huliganboy
#18228
üzenetére
& Somatom!
Beavatnátok?
-
Mr Dini
addikt
Annó tényleg kényelmesnek tűnt a pendrive FFP-re, amíg még volt gari, de mint utólag kiderült ez sem számított volna, ugyanis rá sem néznek szoftveresen, de kb. sehogyan sem, ha garanciális baja van, csak cserélik!
A programcsomagos FFp sincs kihatással a garanciára, mivel a HDD-re települ, az összes komponensével együtt. Ha eltávolítod az FFp FHS-t tartalmazó HDD-t, akkor semmi nyoma nem marad a telepítésnek.
Viszont kérdésem, hogy jó-e ez a jog, elég biztonságos-e?
Melyik jog? A 18-as umask érték?
Mert az 644-es jogokkal hozza létre a fájlokat/mappákat. Igazából Neked kell eldönteni, hogy kinek szeretnéd a letöltött fájlokat megosztani, de egyébként igen, a 18-as umask érték "biztonságos".
A Plex Un Block eldobta az ARMv5 támogatását, egyúttal a 3** szériás NASok (kivétel a 326, mert az már ARMv7-tel dolgozik) sem képesek már a friss Plex futtatására.
A régi verziókat pedig törölték a tárhelyükről.Bizony, ez nem része a hivatalos minidlna forrásnak. Az ffmpegthumbnailer csomaggal gyárt egyébként minden indexelt videófájlhoz egy bélyegképet (gyorsabb, mint a Twonky, mivel C program, s nem Python kód), s a hossz húsz százalékában vágja ki a képkockát.
Nana! Ezt a trükköt nem én fedeztem fel elsőnek, csupán megosztottam Veled.
Az érdem azé, aki felfedezte!Egyébként ezzel a user-agenttel pl. az asztali felület jön be:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101
Kérdés, hogy milyen mobilos böngésző engedi piszkálni a User-Agent fejlécet, mert én még egy ilyen böngészővel sem találkoztam... A fájlkezelő egyébként mobilos fejéccel sajnos nem fog bejönni. És trükkös a dolog, mivel a mobil felület átirányítás nem szerveroldalt történik meg (ahol esetleg konfigból lehet tweakelni a klienstől érkezett fejlécet), hanem kliensoldalt, egy JavaScript végzi. Ez a JS fájl pedig a NASon egy csak olvasható NAND területen helyezkedik el, amit ugyan fel lehet csatolni írhatóként, viszont módosítás esetén elvágtuk magunkat az sw frissítés lehetőségétől. Egyedüli megoldásként azt lehet csinálni, hogy meghagyjuk az eredeti JS-t, s átmásoljuk a HDD-re mondjuk a JS fájlt tartalmazó mappát. Majd ezt rá bindmountoljuk az eredeti útvonalra a boot folyamat után/közben. Így kapunk egy szabadon szerkeszthető webes felületet, melyben ki tudjuk könnyűszerrrel iktatni ezt a mobilos felületet. Egyszer majd talán belekerül a Tweaks-be is ez a funkció...
Mr Dininek van egy webdav féle logout írása ami használható biztonságosan streamre.
Az a leírás sajnálatos módon már egy ideje nem aktuális, mivel a startssl megszűntette a kulcsgenerálási lehetőséget DDNS-ek számára. Helyette viszont írtam egy korszerűbb megoldásról is: [link]. Ez még mindig működik. S végre ki tudtam javítani a leírásban egy sorrendbeli problémát is, így elméletileg bátran követhető a leírás. Ha nem, akkor pedig tessék nyugodtan reflektálni a problémával!
Az FTP nagy hátránya, hogy a bejelentkezési adatokat plain text formátumban küldi vissza a szervernek. Ami könnyen "lehallgatható" egy publikus wifiről például, vagy akár egy KRACK ellen "be nem foltozott" hálózaton.
De nem is csak ezzel van a gond, hanem hogy egy igen régi pureftpd-t használ alapértelmezetten a NAS, ami igen sok sebezhetőséggel rendelkezik. Létezik olyan, mellyel meg lehet kaparintani például a root shell-t is...
Ha FTP kell, én mindenképp egy FFp-s proftpd-t ajánlok. Illetve egy nem sztenderd öt számjegyű portot kintre minimum!Ami pedig a tűzfalat illeti... Szerintem nagy baklövés volt a ZyXEL részéről a NETFILTER letiltása kernel szinten. Így ugyanis iptables tűzfal futtatására a NAS-ok nem alkalmasak.
Ha lenne iptables, akkor lehetne használni fail2ban védelmet, ami figyeli a helytelen próbálkozások számát a logok alapján, s ha ez egy IP cím esetén meghalad egy meghatározott mennyiséget, akkor tiltja az iptables segítségével az az IP-t. Nyilván ez is terhelné a NAS-t, de nem annyira, mintha eljutna az adat a pureftpd-hez. A logokat pedig a routered/tűzfalad más eszközön nem fogja sajnos látni (esetleg NFS csatolással, de az sem ér fel egy fizikai eléréssel).
Nem értem miért jó az, hogy ehhez is módosítani kell a kernelt...
Ha FTP, akkor érdemes VPN-en keresztül tolni, vagy akár egy alkalmi SSH tunnelen áttolni egy aktív FTP forgalmat (Google szerintem ebben tud segíteni). De ahogy többen is ajánlották, én is a webDAV pártján állok. Az biztonságos, gyors, s sok funkciója van.
Nekem például nincs pilótavizsgám!
Azt ha jól tudom, akár meghajtóként is fel lehet csatolni, ugye?
Pontosan!
Hálózati meghajtóként. -
Mr Dini
addikt
Azért a pendriveos FFp-nek is van pár előnye... Pl. annyi FFp sticked lehet, amennyit szeretnél. Hiszen amint kihúzod, nincs nyoma. Ez például akkor hasznos, ha van egy éles konfigurációd, viszont mellette fejlesztessz/fordítgatsz is, aminek van egy külön pendriveja. Illetve egy friss telepítés sem árt csomagteszteléskor.
Illetve ha véletlenül felkerül egy "veszélyes" csomag, mint pl az eglibc (senkinek nem javaslom a telepítését
), akkor nem kell az egész NAS-t újratelepíteni, hanem elég a sticket kihúzni.A logolást pedig ki lehet kapcsolni, vagy lehet RAM-ra irányítani.
-
Mr Dini
addikt
válasz
8nemesis8
#18162
üzenetére
A TM-es kérdésedre válaszolva... Én ZyXEL NASra (amelyek még ARMv5-ös CPU-val rendelkeznek (310,320,325,325v2,310S,320S)) a barmalej féle Transmission-t ajánlom ([link]). Mert slackerből (és slapt-getből !) telepíthető, s ezekre a NASokra van optimalizálva. Második alternatívaként a KyLEK féle TM buildeket mondanám, amik szintén slacker telepítő képes, s elég kiforrott csomagok.
Az Entware-ng-s verziók pedig a méretükről, s az optimalizáltságukról híresek, mivel beágyazott eszközökre készültek általánosságban. Előnyük, hogy gyakran frissülnek, kapnak biztonsági patcheket időnként, viszont nem biztos, hogy minden NAS szempontból érdekes funkcióval rendelkeznek.
Neked ez hobbid vagy esetleg Zyxel közelben dolgozol?
A ZyXEL központja elnézve a kódokat, valahol távol keleten lehet.
Szerintem kicsi országunkban csak egy marketinges+helpdesk részlegük van. Így nem, nincs közöm a céghez. Hobbinak pedig nem nevezném, csak van egy ilyen NASom már egy jó ideje.
), akkor ma is ott tartanék Linux kapcsán, hogy épphogy csak az apt csomagkezelőt ismerem, de semmi mást. Anno nem értettem, hogy miért nem nyitnak sokan az FFp felé, amikor az egy hatalmas lehetőség, de utólag beláttam, hogy tanulásnak jó dolog, de lehet tényleg nem éri meg a vesződést mindenkinek. Pláne hogy az összes repó lehalt, ma már azt javasolnám, amit anno sokáig nem mertem megtenni, hogy aki teljesítményt meg friss csomagokat akar a nastól, az jobban jár egy debian telepítéssel. Talán az 5** széria kivételével az összes nas u-bootot használ, szóval még csak serial se kell a bootolásához és bár elveszti az ember a dedikált zyxeles webes felületet, de cserébe rengeteg leírást kap, egy friss glibc-t, kernelt és toolchaint, meg akár qbittorrentet is telepíthet, ami ellentétben a Transmissionnel pl többszálon is képes hashelni, ami a 326 esetén nagy előnyt jelentene.
.
A repómból telepíthető slackerrel, illetve slapt-gettel is.
A régi verziókat pedig törölték a tárhelyükről.
Ha FTP kell, én mindenképp egy FFp-s proftpd-t ajánlok. Illetve egy nem sztenderd öt számjegyű portot kintre minimum!
Hálózati meghajtóként.Új hozzászólás Aktív témák
- bitpork: Phautós tali a Balcsinál 2025 Augusztus 2 napján (szombat)
- Mi mindenre jó egy másodlagos megjelenítő?
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- GOG.com - Good Old Games
- Így VERNEK ÁT a KAMU webshopok!
- Mindenki Z Fold7-et akar
- OLED TV topic
- Építő/felújító topik
- gban: Ingyen kellene, de tegnapra
- Revolut
- További aktív témák...
- Bomba Ár! Dell Latitude 3190 - Intel N4120 I 4GB I 64GB SSD I 11,6" HD I Cam I W11 I Garancia!
- Bomba ár! Lenovo X1 Yoga 2nd - i7-7G I 8GB I 256SSD I 14" WQHD I HDMI I W11 I CAM I Garancia!
- Telefon felvásárlás!! iPhone 16/iPhone 16 Plus/iPhone 16 Pro/iPhone 16 Pro Max
- Telefon felvásárlás!! Honor 400 Lite, Honor 400, Honor 400 Pro
- HIBÁTLAN iPhone 12 Pro Max 256GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS3035, 100% Akkumulátor
Állásajánlatok
Cég: FOTC
Város: Budapest