Author: mmazur Date: Sun Jul 17 23:03:47 2005 GMT Module: PLD-doc Tag: HEAD ---- Log message: - ok, here's how it works
---- Files affected: PLD-doc: PLD_2.0_ftp_administration (1.1 -> 1.2) ---- Diffs: ================================================================ Index: PLD-doc/PLD_2.0_ftp_administration diff -u PLD-doc/PLD_2.0_ftp_administration:1.1 PLD-doc/PLD_2.0_ftp_administration:1.2 --- PLD-doc/PLD_2.0_ftp_administration:1.1 Tue Jan 20 20:08:44 2004 +++ PLD-doc/PLD_2.0_ftp_administration Mon Jul 18 01:03:42 2005 @@ -1,155 +1,250 @@ "Example is not the main thing in influencing others. It's the only thing." - Albert Schweitzer [EMAIL PROTECTED] mmazur]$ ssh [EMAIL PROTECTED] -Last login: Mon Jan 19 11:18:04 2004 from crossfire.kamp.pl -prosze przygotować bilety do kontroli... - [EMAIL PROTECTED](pld) ac]$ cd ftp/ready/SRPMS/ [EMAIL PROTECTED](pld) SRPMS]$ index-packages -Generating package indexes: SRPMS alpha amd64 athlon i386 i586 i686 ppc sparc [EMAIL PROTECTED](pld) SRPMS]$ chkbuild - 2 DFBPoint - 2 DirectFB-examples - 2 Glide_V5-DRI - 2 SoundStudio - 2 XFree86 - 2 XaoS - 2 audacity - 2 avifile [EMAIL PROTECTED](pld) SRPMS]$ rmpkg DFBPoint-0.7.2-1.src.rpm -/home/ftp/pub/Linux/PLD/dists/ac//ready/SRPMS/DFBPoint-0.7.2-1.src.rpm -/home/ftp/pub/Linux/PLD/dists/ac//ready/alpha/DFBPoint-0.7.2-1.alpha.rpm -/home/ftp/pub/Linux/PLD/dists/ac//ready/athlon/DFBPoint-0.7.2-1.athlon.rpm -/home/ftp/pub/Linux/PLD/dists/ac//ready/i386/DFBPoint-0.7.2-1.i386.rpm -/home/ftp/pub/Linux/PLD/dists/ac//ready/i586/DFBPoint-0.7.2-1.i586.rpm -/home/ftp/pub/Linux/PLD/dists/ac//ready/i686/DFBPoint-0.7.2-1.i686.rpm -/home/ftp/pub/Linux/PLD/dists/ac//ready/ppc/DFBPoint-0.7.2-1.ppc.rpm -/home/ftp/pub/Linux/PLD/dists/ac//ready/sparc/DFBPoint-0.7.2-1.sparc.rpm - -Teraz po kolei co robią poszczególne komendy. Otóż index-packages wyciąga -z wszystkich pakietów w danym drzewku (tak to zaimplementowałem, że -domyślnie używa drzewka ready, ale jeśli wykryje, że `pwd` == test, to używa -test) metadane niezbędne do działania reszty skryptów. To jest rzecz o której -trzeba pamiętać, że skrypty nie pracują na aktualnym drzewku, ale na tym, -co akurat było w momencie odpalania index-packages. -Czasami może wypluć błąd przy jakimś pakiecie. W 99,(9)% przypadków znaczy to, -że jakiś pakiet jest w trakcie uploadowania z buildera. Przeważnie wystarczy -chwilę odczekać i puścić index-packages jeszcze raz. - -Teraz druga komenda - chkbuild. Jeśli po odpaleniu wypluje coś (tak jak w -przykładzie powyżej), to owo coś podaje wszystkie pakiety, których jest więcej -jak jeden (w różnych wersjach oczywiście). Liczba przed nazwą to ilość -różnych wersji danej paczki. -Jak łatwo się domyślić nadmiarowe paczki należałoby inhumować (zwłaszcza, że -skrypt do przenoszenia pakietów pomiędzy drzewkami pobiera tylko nazwę -pakietu, bez jego wersji, a jasnowidztwa jeszcze mu nie zaimplementowałem), co -też jest robione przy pomocy komendy rmpkg (która to pobiera dowolną ilość -src.rpmów jako argumenty i też ma autowykrywanie test/ready). - -W stwierdzeniu, czy pakiet inhumować, czy też nie pomaga -http://ep09.pld-linux.org/~buildsrc/queue.html, gdyż właściwie z miejsca -można usuwać stare releasy pakietów, jeśli nowe zbudowały się na wszystkich -architekturach. Należy pamiętać o tym, żeby nie kasować pakietu, jeśli nie -zbudował się na wszystkich architekturach (gdyż jeśli nie ma src.rpma, to -nawet jeśli gdzieś będą się plątać binarne pakiety na dane architektury, to -oskryptowanie ftpowe ich nie znajdzie i trzeba będzie je ręcznie kasować... -co nie zmienia faktu, że automat inhumujący osierocone z src.rpma pakiety -binarne nie jest zbyt trudny do napisania), ani starać się nie kasować -starszego releasu, jeśli nowy jeszcze się nie zbudował na wszystkich arch -(a nóż widelec na którejś się nie zbuduje, my skasowaliśmy starszy release -i kończy się tym, że na którejś arch pakietu nie ma, mimo, że mógł być -choćby w formie starszego releasa). - -Po wykasowaniu wszystkich nadmiarowych pakietów (specjalnym przypadkiem, gdy -jednak trzeba zostawić parę wersji danego pakietu zajmę się zaraz) odpalamy -jeszcze raz chkbuilda. - [EMAIL PROTECTED](pld) SRPMS]$ chkbuild [EMAIL PROTECTED](pld) SRPMS]$ - -O. Teraz dobrze (możemy wcześniej pro forma odpalić jeszcze raz index-packages -jeśli w międzyczasie jakieś pakiety mogły dojść, a chcielibyśmy je też -przesunąć). Następną rzeczą jaką robimy jest zaglądnięcie do pewnego -tajemnego katalogu. - [EMAIL PROTECTED](pld) SRPMS]$ cd ../.tmp/ [EMAIL PROTECTED](pld) .tmp]$ ls -all no rest - -Plik 'all' zawiera nazwy pakietów, które zbudowały się na wszystkich -architekturach i są gotowe do przeniesienia. W pliku 'no' są nazwy src.rpmów, -z których nie zbudował się żaden gotowy rpm. W pliku 'rest' są wylistowane -pakiety które zbudowały się na (1,wszystkie) architektury wraz z listą -architektur na jaki dany pakiet się zbudował. -Pierwszą rzeczą jaką robimy jest sprawdzenie zawartości pliku no. - [EMAIL PROTECTED](pld) .tmp]$ cat no -Jan 20 12:43 dosbox -Jan 19 13:40 ntp -Jan 19 15:47 rsync -Jan 20 12:59 upx - -Możemy spokojnie inhumować te src.rpmy z drzewka, *ale* najpierw jest -*konieczne*, żeby sprawdzić, czy przez przypadek pakiet nie zbudował się -na żadnej architekturze, bo albo się jeszcze mieli, albo dopiero czeka w -kolejce, ponieważ buildery mielą jeszcze coś innego. Ostrzegam przed -zakładaniem, że jeśli się nie zbudowało na siedem architektur, to na ósmą -się też nie zbuduje. Nie raz się coś takiego zdarzyło. -W naszym przypadku dwa pakiety wygenerowały z *wszystkich* builderów -status FAIL. No więc inhumujemy je: - [EMAIL PROTECTED](pld) SRPMS]$ rmpkg rsync-2.5.7-2.src.rpm ntp-4.2.0-1.src.rpm -/home/ftp/pub/Linux/PLD/dists/ac//ready/SRPMS/rsync-2.5.7-2.src.rpm -/home/ftp/pub/Linux/PLD/dists/ac//ready/SRPMS/ntp-4.2.0-1.src.rpm - -Ok. Teraz musimy sobie pooglądać plik 'rest'. To jest niestety najmniej -przyjemna część roboty, gdyż trzeba posprawdzać właściwie każdy jeden -pakiet z uwzględnieniem ręcznego zaglądnięcia do speca i sprawdzenia -ExclusiveArch (niestety nie da się tego zautomatyzować w łatwy, a zwłaszcza - -niezawodny - sposób). Generalnie jeśli pakiet nie zbudował się na wszystkich -arch, to można go zostawić jeszcze na dzień - dwa, to przeważnie ktoś -go poprawi/puści nową wersję. Jeśli już widać, że pakiet sobie poleżał długo -i nikt się poprawieniem niedziałających arch nie zainteresował, to można -(a) podesłać pakiet na listę z prośbą o poprawienie, lub (b) sprawdzić, czy -przez przypadek ilość arch na którą pakiet się buduje nie jest mniejsza od -ilości arch, na którą się poprzednia wersja zbudowała, a jeśli nie, to -przenieść. Do sprawdzania, czy nie likwidujemy jakiejś arch dla danego -pakietu przy przenoszeniu można by napisać skrypt, ale o dziwo póki co -nie było to konieczne (właściwie wszystkie pakiety były zmuszane do kompilacji -wszędzie). - -A teraz właściwa zabawa. Otwieramy sobie w $EDITOR plik all, wywalamy z niego -to, co wiemy, że jeszcze nie powinno być przeniesione, po czym dodajemy -te pakiety z rest, które chcemy przenieść. I tutaj uwaga: *nie* wolno przenosić -pakietów w przypadku których jest więcej jak jeden src.rpm, bo wynik jest -niedeterministyczny. - -Voila: - [EMAIL PROTECTED](pld) .tmp]$ move-from-ready `cat all`; gen.database - -Teraz tutaj dwie uwagi. Primo taka operacja trwa niemiłosiernie długo i -nie radziłbym ryzykować odpalania jej bez screena. Ewentualny bajzel jaki może -spowodować przerwanie w połowie właściwie nie mieści się w głowie. A secundo - -uważać na nisko latające gen.database'y (skrypt do generowania indeksów) -odpalane z crona. Tzn. zanim odpalimy przenoszenie pakietów dobrym pomysłem -jest sprawdzić, czy w najbliższej przyszłości (20 minut), lub już teraz nie -leci automatyczna generacja indeksów. Jeśli na to się zanosi, to najlepiej -odpalić crontab -e i wykomentować na chwilę wpis (obecnie indeksy są -regenerowane co dwie godziny). - -I jeszcze jedno. Skrypt przenoszący pakiety nie usuwa starych, nadmiarowych -pakietów (tzn. jeśli nowa wersja nie generuje już pakietu program-cośtam, to -owo program-cośtam nie zostanie automagicznie usunięte i będzie straszyć, -póki ktoś tego nie wykasuje ręcznie. Jest ku temu jakiś ważny powód i jak -tylko go sobie przypomnę, to commitnę updejt do tego tekstu. - - -Ostatnia uwaga - niektóre kwestie można rozwiązać w inny sposób, lub bardziej -zautomatyzować, ale dlaczego tak nie jest zrobione zostanie wytłumaczone w -pliku PLD_2.0_TODO jak tylko dopiszę do niego rzeczy konieczne do mrożenia -z punktu widzenia infrastruktury. [EMAIL PROTECTED] ac]$ alias|grep pld +alias mvpkg='~/pld-ftp-admin/scripts/move.py' +alias rmpkg='~/pld-ftp-admin/scripts/remove.py' +alias testmvpkg='~/pld-ftp-admin/scripts/test-move.py' + +You'll most likely want to add some aliases/change them a little, so that they +eg. have default arguments (since 99% of the times you'll be moving files from +'ready' to 'PLD' (aka 'main')). + [EMAIL PROTECTED] ac]$ cd ftp/.tree/ [EMAIL PROTECTED] .tree]$ ls +PLD ready supported test updates-general updates-security [EMAIL PROTECTED] .tree]$ find ready/ -name RPMS +ready/alpha/RPMS +ready/amd64/RPMS +ready/athlon/RPMS +ready/i386/RPMS +ready/i586/RPMS +ready/i686/RPMS +ready/ppc/RPMS +ready/sparc/RPMS +ready/SRPMS/RPMS + +All trees are expected to be in the same form ($treename/$arch/RPMS). In the +above case everything under '.tree' was symlinked from the original locations +so not to enforce any unnecessary user visible path changes. + [EMAIL PROTECTED] .tree]$ cd ready/SRPMS/.metadata/ [EMAIL PROTECTED] .metadata]$ ls|head +alex-2.0.1-1.src.rpm.info +alien-8.53-1.src.rpm.info +amrita-1.0.2-3.src.rpm.info +aMule-2.0.3-2.src.rpm.info +anubis-4.0-2.src.rpm.info +applnk-1.9.5-17.src.rpm.info +apt-0.5.15cnc7-3.src.rpm.info +arj-3.10.22-1.src.rpm.info +autogen-5.7-1.src.rpm.info +bakery-2.3.15-1.src.rpm.info [EMAIL PROTECTED] .metadata]$ cat arj-3.10.22-1.src.rpm.info +file:alpha:arj-3.10.22-1.alpha.rpm +file:amd64:arj-3.10.22-1.amd64.rpm +file:athlon:arj-3.10.22-1.athlon.rpm +file:i386:arj-3.10.22-1.i386.rpm +file:i586:arj-3.10.22-1.i586.rpm +file:i686:arj-3.10.22-1.i686.rpm +file:ppc:arj-3.10.22-1.ppc.rpm +file:sparc:arj-3.10.22-1.sparc.rpm +file:SRPMS:arj-3.10.22-1.src.rpm +info:build:bc9b488c-29df-4d33-a865-cd04756cc643:requester:unknown +info:build:bc9b488c-29df-4d33-a865-cd04756cc643:requester_email:[EMAIL PROTECTED] + +It's quite obvious what's the content of those files. All tools work based on +what's available under the SRPMS/.metadata directory for a given tree. Those +files are always synced with what's present on ftp and the only way to +desynchronize them is to manually tamper either with *.info files or the rpms +themselves. Do *NOT* do that. All tools expect to find all the files they're +looking for, and if they don't fine just one, they'll bail out in a rather +unfriendly manner (unhandled python exception). Ok, let's do some fun stuff. + [EMAIL PROTECTED] .metadata]$ testmvpkg ready PLD vino-2.10.0-4.src.rpm.info +arj-3.10.22-1.src.rpm.info [EMAIL PROTECTED] .metadata]$ + +Everything went fine (do remember about the aliases I've mentioned at the +beginning of this document). Now we can just go ahead with the move and run. + [EMAIL PROTECTED] .metadata]$ mvpkg ready PLD vino-2.10.0-4.src.rpm.info +arj-3.10.22-1.src.rpm.info [EMAIL PROTECTED] .metadata]$ + +Voila -- vino-2.10.0-4.src.rpm, arj-3.10.22-1.src.rpm and all rpms built from +those two src.rpms (I'll be referring to them as package sets) got moved from +tree 'ready' to tree 'PLD'. The 'move.py' tool (referenced here through the +'mvpkg' alias) also did the following things: +- performed various test I'll talk about in a moment +- checked if either 'vino' or 'arj' package sets were already present in the +'PLD' tree, and if so, removed them (yes, that means you can't have two package +sets with different versions in a tree you are moving *to* (no, not *from*, but +*to*)) +- from 'ready' tree removed all arj and vino package sets that are older (as in +version-release is lower; watch out for loose epochs, though) than respectively +vino-2.10.0-4 and arj-3.10.22 (which means you don't need to manually delete +anything, since the move.py will remove all the old stuff for you) + +Ok, now for the tests. Both testmvpkg (~/pld-ftp-admin/scripts/test-move.py) +and mvpkg (move.py) perform various tests, so that you don't have to. The +difference between the two tools is that the first one reports all the errors +and warnings it can possibly find, while the second one bails out on the first +error it encounters (and doesn't move anything around if it gets scared away by +errors). So your best bet is to use the first tool till it doesn't spill out +any errors. And then you're ready to go with the second one. + +Following tests are performed: +- Error if nothing but the src.rpm got built. +- Error if the package is still being built (it checks the src.builder's build +queue). +- Error if a package set is already present in the destination tree (obviously +most of the times with a different version) and the package set that we're +trying to move doesn't have all the archs, that the package set in the dest +tree has (in other words: you can't move a package set that supports less +architectures than the one already present). +- Warning if a package set isn't built for all available archs. + +You can ignore warnings, but to move something when an error is reported, you +need to use one of the overrides. Just run 'move.py' without arguments for a +list of available overrides (if you need one that isn't currently available, +just bug me to code it). + + +Other tools you might find interesting are: +- remove.py (rpmkg alias) -- you just give it the tree name and a list of +package sets and it will remove those sets (warning: doesn't perform the +'package still being built' test though it should, so be careful when using or +you'll end up with rpms being stuck in the ftp upload queue, since they won't +get moved to a tree unless adequate src.rpm and src.rpm.info files are present; +read further for details as to why that happens). +- gen-indexes.py -- generates poldek indexes. Just give it any number of trees +as args and wait. + + +And now, when you know how to use this stuff, it's time for some technical +details and maybe even some tips. + +First, to clear all doubts -- yes, we have proper locking, so atomicity is not +an issue. Inside ~/pld-ftp-admin/ftpiod you can find a daemon that needs to run +all the time. Currently it's only used for locking, but will most likely get +more features (caching) as time goes. I strongly suggest running it through +screen, since in case of any problems you'll get a nice dump of a python +exception that'll be a must have if I am to fix the problem. How to assure it's +always there even after reboots is entirely up to your own invention :) + +Now let's see what can we find in the config file. + [EMAIL PROTECTED] ac]$ cat .ftpadmrc + +ftp_dir="/home/pld/admins/ac/ftp/.tree" +incoming_dir=".incoming" +test_builds_dir="test" + +default_to="ready" + +ftp_archs="alpha amd64 athlon i386 i586 i686 ppc sparc" +separate_noarch="no" + +logs_list="[EMAIL PROTECTED]" +from_field="PLD ac-ftp AI <[EMAIL PROTECTED]>" +xpldbuilder="ac-ftp" + +builderqueue="http://ep09.pld-linux.org/~buildsrc/queue.txt"; + +pubsock="/home/pld/admins/ac/pld-ftp-admin/var/pubsock" + +old_poldek="yes" + + +Ok, most of this stuff is rather obvious, but to clear all doubts. +- old_poldek means we're using poldek 0.18 for index generation. +- pubsock is a unix socket used for communication with ftpio daemon. +- separate_noarch tells pld-ftp-admin whether you want to keep noarch.rpms +under a separate directory (just look at ftp.pld-linux.org/dists/th/ready to +see what I mean; it saves disk space and makes mirror maintainers happy, but +forces users to search for rpms under two directories (poldek makes it +transparent, so no need to worry, though)) + + +And as for incoming_dir, test_builds_dir and default_to, here's how it goes. + +First, builders (run by pld-builder.new scripts) have two build modes -- test +builds and normal builds. When requesting a test build, the resulting rpms get +uploaded directly into some tree (usually the one you set test_builds_dir to) +and there isn't much you can do with them, since no metadata gets generated +(SRPMS/.metadata is never used). You'll most likely just want to run +maintainer.py from time to time, which removes all files older than X days from +the test_builds_dir tree (or use plain old tmpwatch for that). + +It's different with normal builds. When a normal build gets finished, the +resulting rpms get uploaded to incoming_dir. Then from-incoming.py (usually run +from cron every minute or so) takes them and places them in the default_to tree +and updates the appropriate *.info file. + +In case you're wondering: +- from-incoming.py generates *.info files only when moving an uploaded src.rpm +(meaning that if no src.rpm gets uploaded or you delete/move it before all +arch.rpms get uploaded, those arch.rpms stay in incoming_dir for ever and ever +and ever) +- from-incoming.py won't break your files when moving them around. It can tell +if a batch of files (it doesn't move single files, but the whole batch from a +single build of a given builder) got fully uploaded. +- Yes, it's this script that can filter out noarch.rpms and place them under a +separate directory (and do some sanity checks on them, too). +- If you've sent two requests for a package to get built, it won't overwrite +any files already present in a tree. It does a simple test -- even if a single +file for a given arch (SRPMS included) is already present in default_to dir, +it discards all of the newly uploaded files for that arch. What it does though, +is add info about the second build to the *.info file (requester, requesters' +email and the build id). +- The above isn't true when handling noarch.rpms when separate_noarch is set to +'yes'. It isn't for pld2.0, so no need to worry about it. + + +And a quick round of questions and and answers: + +Q: OMG, OMG, OMG, a script blew up in my face with a python exception! What +now? + +A: Here's what you do -- first, go investigate what caused the script to fail +(a missing rpm? corrupt *.info file?). Problem solved? Ok. Now you must keep in +mind, that in case of unhandled exceptions none of the tools unlock any trees. +It makes sense, since it keeps you safe from any intervention that might +potentially do more damage, till you manage to investigate what went wrong. It +also means that all automatic ftp activity stalls till you manually unlock +those trees. Here's how you do it: + [EMAIL PROTECTED] ac]$ cd ~/pld-ftp-admin/modules/ [EMAIL PROTECTED] modules]$ python +Python 2.4.1 (#1, May 4 2005, 20:54:13) +[GCC 3.3.5 (PLD Linux)] on linux2 +Type "help", "copyright", "credits" or "license" for more information. +>>> import ftpio +>>> ftpio.connect() +>>> ftpio.unlock('treename') +>>> + +Voila. + + + +Q: Let's assume I've built package X-Y-Z (Y-Z being version and release +numbers) only for two archs. They've got built and I've moved the whole package +set to a different tree. Now I've got a third arch available, and I've built +the same X-Y-Z package on three archs. Everything went fine, and now I want to +move it to the same tree, that already stores X-Y-Z but only for those two +archs. What'll happen? + +A: Same thing, that from-incoming.py does in a similar case. It'll add some +build info metadata to the *.info file in dest tree, and then only move files +for archs that aren't already present in dest tree (yes, SRPMS included), while +discarding (removing) the rest. It means you can add a whole new arch to an +already established tree, and none of the tools should get in your way. + +-- mmazur + +# vi: formatoptions=aw, language=english ================================================================ ---- CVS-web: http://cvs.pld-linux.org/PLD-doc/PLD_2.0_ftp_administration?r1=1.1&r2=1.2&f=u _______________________________________________ pld-cvs-commit mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
