Forum Debian Users Gang

A na PLD cpan nie działa?

Bo u mnie na localhoście (ejabberd) coś tam działa:

jab2gg-cli.pl -c duch:pass@localhost
error: not-authorized at /usr/local/bin/jab2gg-common.pl line 290.

hasło poprawne, w pidginie działa.
Dla innego usera chyba się zalogował:

jab2gg-cli.pl -c portage:ZatllNQ3vSPYr2m8@localhost
Use of uninitialized value $gg_contact_list in concatenation (.) or string at /usr/local/bin/jab2gg-common.pl line 435.
GG70ExportString,;<Pozostałe>,;

Parametry konta prawidłowe, tutaj działa:

grep -v '#' /etc/make.conf | grep -i jabber
PORTAGE_ELOG_SYSTEM="echo save jabber"
PORTAGE_ELOG_JABBERFROM="portage:ZatllNQ3vSPYr2m8@localhost"
PORTAGE_ELOG_JABBERTO="duch@localhost"

W każdym razie o żadne moduły nie woła, pewnie dlatego, że mam też np sendxmpp, który korzysta z podobnych modułów.
Perl u mnie: http://pastebin.com/gaXHP5MV

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2011-02-18 21:20:19)

Minio właśnie odpalilem ten skrypt i wyglada, że działa, wypluł liste użytkonikow gg jaką mam na tym koncie.
rpm -qa G perl |sort
http://wklej.fluxboxpl.org/18616
używam i686, jakby jeszcze jakies info bylo potrzebne to pisz

Minio napisał(-a):

Jacekalex: pewnie działa, ale instalując moduły z CPAN (znaczy przez ten ichni menedżer modułów) lądujemy z systemem gdzie nad częścią pakietów kontrolę ma zwykły menedżer pakietów (poldek) a nad częścią jakieś inne narzędzie (cpan). To najlepsza droga do rozpieprzenia sobie tego systemu ;) .......

To prawda, Gentoo, ale nie cpan - na Gentusiu nie jest potrzebny.
Problem funkcjonowania modułów z cpan w  zależnościach systemu, w Gentusiu rozwiązano tak.

I dlatego część modułów perla u mnie pochodzi z takiej dziwnej gałęzi portage:

perl-gcpan/Bot-JabberBot-0.02

Czy w PLD jest jakiś mechanizm budowania paczek z modułów cpan? Pojęcia nie mam, w Debianie o ile wiem, jest coś podobnego.


Poza tym nie demonizowałbym CPAN, używałem go w Ubuntu, i jak coś nie działało po aktualizacji perla, to wystarczało przeinstalowanie modułów (przez cpan) i było ok.
I nigdy w ten sposób nie uszkodziłem systemu.
Wystarczy używać CPAN do tych modułów, które nie istnieją w paczkach dostępnych dla dystrybucji.

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2011-02-18 23:23:37)

Jacekalex napisał(-a):

Problem funkcjonowania modułów z cpan w  zależnościach systemu, w Gentusiu rozwiązano tak.

Wiem, sam z tego korzystałem te prawie 5 lat temu (jak ten czas szybko leci) gdy używałem Gentoo ;) .
No ale Gentoo to nie PLD, więc niestety rozwiązanie z Gentoo niewiele nam w rozwiązaniu obecnego problemu pomoże.

Jacekalex napisał(-a):

Czy w PLD jest jakiś mechanizm budowania paczek z modułów cpan? Pojęcia nie mam, w Debianie o ile wiem, jest coś podobnego.

Dla Debiana to w Cpanie sami budują pakiety i udostępniają w swoim repo ;) -> http://debian.pkgs.cpan.org/ . Chociaż sądząc po datach, chyba bardziej na miejscu jest powiedzieć „budowali”.
No ale jednak zdecydowana większość pakietów z CPAN jest w repozytoriach Debiana.

Jacekalex napisał(-a):

Poza tym nie demonizowałbym CPAN, używałem go w Ubuntu, i jak coś nie działało po aktualizacji perla, to wystarczało przeinstalowanie modułów (przez cpan) i było ok.

No i to jest argument za tym, żeby CPAN-a na maszynie produkcyjnej nie używać :) . Przy każdej aktualizacji perl-a administrator musi pamiętać żeby przeinstalować moduły przy pomocy CPAN-a. Jeśli tak admin ma pod opieką jeden serwer, to może jeszcze na to pójdzie, ale jak ma ich kilkanaście, to już nie — właśnie po to są menedżery pakietów, żeby miał proste zadanie.

Zresztą — nie ja jestem tam administratorem, więc nawet gdybym się z Tobą w pełni zgadzał, to niewiele by z tego wynikało.

winnetou: możesz podać listę modułów perl-a wraz z wersjami które masz na tym Gentoo?

Minio napisał(-a):

No i to jest argument za tym, żeby CPAN-a na maszynie produkcyjnej nie używać :) . Przy każdej aktualizacji perl-a administrator musi pamiętać żeby przeinstalować moduły przy pomocy CPAN-a. Jeśli tak admin ma pod opieką jeden serwer, to może jeszcze na to pójdzie, ale jak ma ich kilkanaście, to już nie — właśnie po to są menedżery pakietów, żeby miał proste zadanie.

Czy ten Poldek nie działa przypadkiem na rpm?
może to pomoże.

Bo moduly cpan można budować do postaci zarówno paczek deb jak i rpm, jak również tbz (w Gentoo) - i swobodnego przenoszenia między serwerami.
A co do PLD, to radziłbym zapytać admina serwera, jak się nazywa narzędzie Poldka do cpan, i jak się go używa.

Bo w mojej opinii, dystrybucja, w której problemem jest zrobienie paczki akceptowalnej przez system z operacyjny, z pakietu cpan, czy źródeł programu, średnio się do czegokolwiek nadaje, nie mówiąc o serwerze.

Więc na 99% w PLD jest do tego program, tylko trzeba go namierzyć.
Ewentualnie popytaj tutaj: http://forum.pld-linux.org/
Albo spróbował tego: http://rpm.pbone.net/index.php3/stat/4/idpl/5710752 … arch.rpm.html

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2011-02-19 00:22:29)

Minio chrome.pl
może inaczej przebiega autoryzacja na chrome?

Ostatnio edytowany przez svL (2011-02-19 00:16:06)

winnetou: a na Desktop1 połączenie z jabster.pl też Ci nie wychodzi? Bo tam masz takie same wersje pakietów jak ja u siebie na Debianie.

chociaż coraz mniej skłaniam się do zwalania winy na zdezaktualizowane pakiety na tym PLD. Zainstalowałem sobie na Debianie wszystko w dokładnie takich samych wersjach jak na tym PLD i nadal u mnie działało. Jak na złość na te moduły Debian nie nałożył własnych patchy, więc tutaj też nie mogę znaleźć przyczyny. To wygląda tak, jakby na PLD „po prostu” nie działało a u mnie „po prostu” działało. I nie rozumiem dlaczego.

Tymczasem założyłem wątek na liście pld-users-pl. Na razie bez pozytywnych odpowiedzi, ale liczę że to się zmieni.

Jak będzie mi się chciało wziąć komputer na uczelnię, to ściągnę też jakąś Fedorę albo coś. Mam nadzieję że zobaczę czy to wina Debiana że działa czy wina PLD że nie działa.

Przy okazji napiszę:
po dokładniejszej analizie logów (w pierwszym poście) zauważyłem, że na PLD chce się uwierzytelnić poprzez metodę DIGEST-MD5, zaś na Debianie — PLAIN. Oba w odpowiedzi dostają jako możliwe mechanizmy DIGEST-MD5 i PLAIN (w tej kolejności). Authen::SASL ma używać pierwszego dostępnego mechanizmu (Authen::SASL linia 127, Authen::SASL::Perl linia 33), czyli MD5. Jednak z jakiegoś powodu na Debianie wraca do PLAIN (który — jak widać — jest skuteczniejszy, a i tak samo bezpieczny, bo połączenie i tak leci po TLS), a na PLD nie. Nie potrafię zrozumieć dlaczego...

winnetou: dzięki za info, czyli być może to jednak kwestia wersji pakietów. To by nie było takie złe, przynajmniej byłby znany winny.

Ale z DUGowym jabberem dalej się nie łączy ;] Wywala błąd autoryzacji (chyba że pass jest inny niż do forum... dawno nie korzystałem ;])

winnetou: przy zakładaniu konta w profilu na forum trzeba podać nowe hasło, więc możliwe że musisz użyć innego niż to do logowania na forum. Możliwe też że faktycznie przy połączeniu z jid.dug.net.pl się wywala, ale ja już na to wpływu nie mam — w końcu korzystam z gotowych modułów ;) .

Jacekalex: nie, nie próbowałem. Zaktualizowany perl-XML-Stream już jest w ftp://master-ftp.pld-linux.org/dists/3.0/.test-builds. Poza tym wiele pakietów jest w repozytoriach PLD, tylko gorzej z ich aktualnością ;) . Zalety (lub wady) schematu rozwoju PLD, gdzie każdy developer robi akurat to, co jest mu potrzebne. Z drugiej strony myślę że jak na listę pld-devel-pl wysłać prośbę o napisanie/podbicie speca dla jakiegoś tam pakietu, to znajdzie się ktoś na tyle miły że to zrobi. W tym przypadku się znalazł, i to bez proszenia z mojej strony.