PLD-doc: PLD_2.0_ftp_administration - ok, here's how it works
mmazur
mmazur at pld-linux.org
Mon Jul 18 01:03:47 CEST 2005
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
-[mmazur at home mmazur]$ ssh pldac at ep09
-Last login: Mon Jan 19 11:18:04 2004 from crossfire.kamp.pl
-prosze przygotować bilety do kontroli...
-
-[pldac at ep09(pld) ac]$ cd ftp/ready/SRPMS/
-[pldac at ep09(pld) SRPMS]$ index-packages
-Generating package indexes: SRPMS alpha amd64 athlon i386 i586 i686 ppc sparc
-[pldac at ep09(pld) SRPMS]$ chkbuild
- 2 DFBPoint
- 2 DirectFB-examples
- 2 Glide_V5-DRI
- 2 SoundStudio
- 2 XFree86
- 2 XaoS
- 2 audacity
- 2 avifile
-[pldac at ep09(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.
-
-[pldac at ep09(pld) SRPMS]$ chkbuild
-[pldac at ep09(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.
-
-[pldac at ep09(pld) SRPMS]$ cd ../.tmp/
-[pldac at ep09(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.
-
-[pldac at ep09(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:
-
-[pldac at ep09(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:
-
-[pldac at ep09(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.
+[pldac at ep09-pld 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')).
+
+[pldac at ep09-pld ac]$ cd ftp/.tree/
+[pldac at ep09-pld .tree]$ ls
+PLD ready supported test updates-general updates-security
+[pldac at ep09-pld .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.
+
+[pldac at ep09-pld .tree]$ cd ready/SRPMS/.metadata/
+[pldac at ep09-pld .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
+[pldac at ep09-pld .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:unknown at pld-linux.org
+
+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.
+
+[pldac at ep09-pld .metadata]$ testmvpkg ready PLD vino-2.10.0-4.src.rpm.info
+arj-3.10.22-1.src.rpm.info
+[pldac at ep09-pld .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.
+
+[pldac at ep09-pld .metadata]$ mvpkg ready PLD vino-2.10.0-4.src.rpm.info
+arj-3.10.22-1.src.rpm.info
+[pldac at ep09-pld .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.
+
+[pldac at ep09-pld 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="pld-logs-builder at lists.pld-linux.org"
+from_field="PLD ac-ftp AI <pldac at ep09.pld-linux.org>"
+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:
+
+[pldac at ep09-pld ac]$ cd ~/pld-ftp-admin/modules/
+[pldac at ep09-pld 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
More information about the pld-cvs-commit
mailing list