tux

W tym wypadku tak, ale zrobi się bo jest do poprawki OpenSSH i OpenSSL. EDIT tux: Zaktualizowane obrazy są już na serwerze.

@j00zek → wychodzi na to, że opisywany efekt występuje, ale tylko wtedy gdy mamy ikonkę X i napisz "BŁAD połączenia z OPKG. Wyłączyłem sieć w ustawieniach i mam ten efekt, który jest opisywany. Po uruchomieniu sieci błędu nie ma.

Ale jest GOS Mgr.

Na pen nie powinno być tylko jednego pliku. Poszukaj na forum - jest opis krok po kroku. Jeden z użytkowników opisywał procedurę.

Za około 15 minut będzie w repozytorium GOS.

Hasła to jest logiczne, że muszą nie być słownikowe. Jednak patrzenie jak ktoś toś Ci się na porcie 22 dobija pół dnia szukając hasła to już fajne nie jest. Dlatego na usługach, gdzie w logach widzę systematycznie powtarzające się schematy zmieniam porty, przy okazji zachowując resztę polityki bezpieczeństwa tak jak to @mickey opisał. Jakbym się uparł to odnajdę logi sprzed kilku lat jak wygląda takie szukanie haseł i notoryczne próby logowania się. Poza tym preferuję wystawienie ssh na porcie XYZ na routerze/serwerze z porządnym hasłem i nowym softem i dalej logowanie się po sieci lokalnej. Unikajmy wystawiania na zewnątrz naszej sieci lokalnej.

Wcale nie musi to byc blad. Wystarczy haslo slownikowe lub podobne do slownikowego. Jakbys popatrzyl w logi na routerach to bys sie przerazil ile razy ktos potrafi z jednego ip logowac do ssh, ftp czy scp. Oczywiscie proby robione sa na standardowych portach. Jak zgadnie haslo a nie ma zabezpieczenia na ilos prob logowania to...

No bo na zewnątrz nie wystawia się portu 22. To od dawna jest samobójstwo.

Mało prawdopodobne by winny był OpenSSH, ale leci właśnie poprawka do wersji 6.8p1

Jak najszybciej te wtyczki zacisnąć poprawnie!

Pewnie wpadł na pomysł, że ułoży kolorami we wtyczce a nie jak stanowi standard.

Jeżeli wypakowałeś archiwum i masz na PEN pliki *.ipk dla Twojego tunera (sprawdź) to musi działać. Jeżeli jednak coś nie tak i masz kabel debug to w GOS masz dostępny w pełni działający terminal pod DEBUG a nie jak w innych obrazach wyjście E2 przekierowane na DEBUG. Możesz zatem zamontować pen z palca i poinstalować też z palca paczki.

+------------------------------------------------------------------------------- | OSCam ver: 1.20-unstable_svn rev: 10572 target: i686-pld-linux-ssl | Reverts: 10380, 9972, 9971, 9963, 9962, 9957, 9949 | Patches: conax_rsa2.patch, buffsize500k.patch, z-maxservices.patch | Tools: | CROSS = | CC = gcc | Settings: | CONF_DIR = /etc/oscam | CC_OPTS = -O2 -ggdb -pipe -ffunction-sections -fdata-sections | CC_WARN = -W -Wall -Wshadow -Wredundant-decls -Wstrict-prototypes -Wold-style-definition | CFLAGS = -DWITH_SSL=1 -DWITH_LIBCRYPTO=1 | LDFLAGS = -Wl,--gc-sections -DWITH_SSL=1 -DWITH_LIBCRYPTO=1 | LIBS = -lssl -lcrypto -lpthread -ldl -lrt | UseFlags = USE_SSL=1 USE_LIBCRYPTO=1 | Config: | Addons : WEBIF WEBIF_LIVELOG WEBIF_JQUERY TOUCH WITH_SSL IRDETO_GUESSING CS_ANTICASC | WITH_DEBUGMODULE_MONITOR WITH_LB CS_CACHEEX CW_CYCLE_CHECK LCDSUPPORT LEDSUPPORT | Protocols: CAMD35 CAMD35_TCP NEWCAMD CCCAM CCCSHARE GBOX | Readers : NAGRA IRDETO CONAX CRYPTOWORKS SECA VIACCESS VIDEOGUARD BULCRYPT | CardRdrs : PHOENIX | Compiler : gcc (PLD-Linux) 4.9.2 20141216 (release) | Config : build/i686-pld-linux-ssl/config.mak | Binary : Distribution/oscam-1.20-unstable_svn10572-i686-pld-linux-ssl +------------------------------------------------------------------------------- Poprzednia wersja pracowała ponad 120 dni. Niestety zakład energetyczny odciął mnie na ponad 6h od energii w Niedzielę Wielkanocną i nawet zasilacz buforowy nie dał rady. Dlatego korzystając z okazji skompilowałem nową wersję i zrobiłem upgrade na serwerze. oscam-1.20.server-svn10572.i686.rpm

Meldują to, ale soft potrzebny do analizy tego (jako daemon) jest za duży na boxa. Dlatego jak nie złapie to musi ponownie zainicjować sieć. Nie jest to kwestia klienta DHCP a całej obsługi sieci - ta jest z busybox.

GraterliaOS:~# ls -l /usr/lib/librtmp.so* lrwxrwxrwx 1 root root 12 Mar 20 21:31 /usr/lib/librtmp.so -> librtmp.so.1 lrwxrwxrwx 1 root root 12 Mar 20 21:31 /usr/lib/librtmp.so.0 -> librtmp.so.1 -rwxr-xr-x 1 root root 110052 Mar 20 21:31 /usr/lib/librtmp.so.1 GraterliaOS:~# EDIT tux: Namierzyłem. Synchronizacja serwerów leżała (DNSy częściowo leżą). Wrzuciłem synchro po IP. Za około 15 minut powinno być OK. Zróbcice wtedy reinstalację paczki.

Ale widzisz, że u mnie działa? Binarka ta co pokazałem + liby co pokazałem. Dlaczego u mnie działa?

Wniosek → używasz repo, które samo się generuje na podstawie tego co tworzy @samsamsam. Na http://openpli.xunil.pl/iptvplayer/ jest: Czyli używając tego repo nie używasz plików czysto z GOS. Ja na DSI-87 (mój Devel) mam tylko pliki GOS i po tym co podałeś mam: GraterliaOS:~# rtmpdump --rtmp="rtmp://stream.smcloud.net/live2/eska_party/eska_party_720p" --realtime > dd RTMPDump v2.4, GIT-2014-07-07, KSV patch 2014-10-28, (Compiled by samsamsam@o2.pl 2015-01-11) (c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL WARNING: You haven't specified an output file (-o filename), using stdout Connecting ... INFO: Connected... Starting download at: 0.000 kB in approximately realtime (disabled BUFX speedup hack) INFO: Metadata: INFO: duration 0.00 INFO: width 1280.00 INFO: height 720.00 INFO: videodatarate 2441.41 INFO: framerate 25.00 INFO: videocodecid 7.00 INFO: audiodatarate 156.25 INFO: audiosamplerate 44100.00 INFO: audiosamplesize 16.00 INFO: stereo TRUE INFO: audiocodecid 10.00 INFO: frameWidth 1280 INFO: frameHeight 720 INFO: displayWidth 1280 INFO: displayHeight 720 INFO: encoder Lavf54.59.102 INFO: filesize 0.00 459.896 kB / 2.11 sec^C Caught signal: 2, cleaning up, just a second... 494.090 kB / 2.31 sec Download may be incomplete (downloaded about 0.00%), try resuming GraterliaOS:~# Stąd wniosek - rtmpdump z repo iptvplayer (1:1 z repo iptvplayer) jest kompilowane pod inną bibliotekę. Nie ja to kompilowałem i nie ja będę to naprawiał. A już na 100% nie będe szukał gdzie są źródła. Szczególnie, że GOS (i ja osobiście również) zostaliśmy potraktowanie, lekko pisząc, niestosownie. IPTVPlayer nie jest częścią GOS i należy go traktować jako dodatek. Nie jest również supportowany przez nas.

Ale nadal nie mam tego błędu co ty. Dlatego pytam jak mam go wygenerować i czy do tego muszę mieć plik do odtwarzania. Jak tak to go nie mam.

Otóż ma :) librtmpdup mamy nasz z kompilacji GOS. Jest on inny niż ten, z którym kompilował @samsamsam. Z resztą @samsamsam na jednym z forum pisał, że tworzy coś pod - cytuję - najlepszy IMAGE na literkę "H". Tam mają OpenPli chyba z maja zeszłego roku o bibliotekach nawet nie wspomnę. Na chwilę obecną mam tak (na DSI devel): GraterliaOS:~# opkg list-installed | grep tmp librtmp - 2.4.3 rtmpdump - 2.4.5 GraterliaOS:~# rtmpdump RTMPDump v2.4, GIT-2014-07-07, KSV patch 2014-10-28, (Compiled by samsamsam@o2.pl 2015-01-11) (c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL ERROR: You must specify a hostname (--host) or url (-r "rtmp://host[:port]/playpath") containing a hostname GraterliaOS:~# Gdzie są źródła tego rtmpdump? Nie wiem. Jak ktoś je poda to przekompiluję do nas. Z drugiej strony - cała operacja wymaga pracy pod jeden plugin, gdzie osoba ma duże problemy ze współpracą ;(

Nie wiem jak działa wtyczka. Wiem jak działa plik auto.network. Mam w nim:: # automatically generated by enigma 2 public -fstype=nfs,rw,nolock,soft 192.168.1.1:/media/public Oba montują się bez najmniejszego ALE. Na serwerze zainstalowane: [root@xunil ~]# rpm -qa | grep nfs libnfsidmap-0.25-4.i686 nfs-utils-common-1.3.1-1.i686 nfs-utils-1.3.1-1.i686 libnfs-1.9.6-1.i686 Zawartość exports: [root@xunil ~]# cat /etc/exports #local share #tux #/media/public 192.168.1.12(rw,all_squash,anonuid=1000,anongid=100) 192.168.1.14(rw,all_squash,anonuid=1000,anongid=100) 192.168.1.9(rw,all_squash,anonuid=1000,anongid=100) /media/mymusic 192.168.1.12(rw,all_squash,anonuid=1000,anongid=100) 192.168.1.14(rw,all_squash,anonuid=1000,anongid=100) 192.168.1.13(rw,all_squash,anonuid=1000,anongid=100) 192.168.1.3(rw,all_squash,anonuid=1000,anongid=100) 192.168.1.16(rw,all_squash,anonuid=1000,anongid=100) 192.168.1.20(rw,all_squash,anonuid=1000,anongid=100) 192.168.1.24(rw,all_squash,anonuid=1000,anongid=100) 192.168.1.25(rw,all_squash,anonuid=1000,anongid=100) /media/public 192.168.1.0/255.255.255.0(rw,all_squash,anonuid=1000,anongid=100) /media/public/records 192.168.1.0/255.255.255.0(rw,all_squash,anonuid=1000,anongid=100) #/media/public/videos/ 192.168.1.0/255.255.255.0(rw,all_squash,anonuid=1000,anongid=100) #/media/videos 192.168.1.12(rw,all_squash,anonuid=1000,anongid=100) 192.168.1.14(rw,all_squash,anonuid=1000,anongid=100) 192.168.1.9(rw,all_squash,anonuid=1000,anongid=100) #/media/public 192.168.1.20(rw,all_squash,anonuid=1000,anongid=100) # nBox ##/media/satbox/tuxish 192.168.1.9(no_root_squash,rw) ##/media/satbox/esi88 192.168.1.9(no_root_squash,rw) ##/media/satbox/BSKA 192.168.1.29(no_root_squash,rw) #/media/nBox/2850 192.168.1.*(no_root_squash,rw) #/media/nBox/test_1 192.168.1.6(no_root_squash,rw) #/media/nBox/test_2 192.168.1.6(no_root_squash,rw) #/media/nBox/freebox 192.168.1.6(no_root_squash,rw) [root@xunil ~]# Jak działa sama wtyczka nie wiem bo jak coś mogę zrobić z palca to robię.

GraterliaOS:~# rtmpdump RTMPDump v2.4, GIT-2014-07-07, KSV patch 2014-10-28, (Compiled by samsamsam@o2.pl 2015-01-11) (c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL ERROR: You must specify a hostname (--host) or url (-r "rtmp://host[:port]/playpath") containing a hostname GraterliaOS:~# Powyższe na release bez repo ITPV. Nie wiem co się dzieje na repo IPTV bo to jest tworzone na podstawie tego co robi @samsamsam. Jeżeli skompiluje coś z inną wersją biblioteki niż nasza to może być tak jak napisałeś wyżej.

Czy do wygenerowania tego błędu potrzeba próby odtworzenia pliku czy wystarczy uruchomić samo rtmpdump? Pytam się bo nie mam pliku FLY a w GOS mamy zazwyczaj nowsze biblioteki niż inne IMAGE.

Czas startu na szybszym odbiorniku z GOS (np. ESI czy SPAKR) do czasu zapytania DHCP to około 40sec (pomijam sprawdzanie błędów dysku, zakładam, że ich nie ma). Dodając do tego powiedzmy 20 sec zapytań DHCP (celowo piszę 20 a nie 30) to mamy MINUTĘ. Nie znam Routera, który by wstawał MINUTĘ, nawet na alternatywnym sofcie. Oczywiście pomijam przypadki, gdy router robi za całą choinkę od routera, przez torrenty, NAS po serwer dźwięku. W takich przypadkach może wstawać dłużej. Jednak wtedy trzeba o tym wiedzieć. U mnie np. wstanie serwerowni to około 6minut. Jedak wiem dlaczego tak jest i nie narzekam jak po DHCP tuner nie dostanie adresu. Poskładanie macierzy HDD + test spójności (standardowy) musi potrwać i nic z tym nie zrobię. Jednak wiem, że wszystko mam na zasilaczu buforowym (UPS byłby za drogi) i cała serwerownia domowa może pracować bez prądu ponad 6h. Reasumując - przy choince to ja nie zaryzykuje braku UPSa/zasilacza buforowego. Przy zwykłych konfiguracjach jak tuner nie dostaje IP na czas to radzę jak najszybciej doprowadzić sieć do standardów. Im nowszy sprzęt tym większe ma wymagania.

Oczywiście z posta powyżej dowiemy się: TEST czy release? aktualizacje z kiedy? gdzie był wykonany restart sieci - wiemy tylko, że z pilota.

Być może zupełnie nic. Ale co lepsze routery/modemy na oficjalnym sofcie sprawdzają czy MAC należy do tych co znajdują się na liście dostawców sprzętu sieciowego.