openSUSE Lizards

Authors
Adam Jurkiewicz
Adrian Schröter (5)
Agustin Chavarria (1)
Akhil Laddha
Alex Barrios
Alex Minton
Alexander Naumov
Alexander Orlovskyy (3)
Alexey Eromenko
Alin M Elena (4)
Andrea Florio (14)
Andreas Jaeger (44)
Andreas Stieger (1)
Andreas van dem Helge
Andrej Semen
Andrew Wafaa (25)
Arvin Schnell (6)
Beineri2
Bernhard Wiedemann
Bharath Acharya
Bonnie Kurniawan
Brian G. Merrell
Bruno Friedmann
Carl Fletcher
Casual Programmer
Chang ChiaChin
Christoph Thiel
Christopher Hobbs (15)
Ciaran Farrell (2)
Claes Backstrom
Coly Li
Cristian Rodríguez
Daniel Bornkessel
David Bailey
David C. Rankin
Dean Hilkewich
Dinar Valeev (5)
Dirk Müller (1)
Dmitry Serpokryl (7)
Duncan Mac-Vicar
Enrique Herrera Noya
Eugene Pivnev
FabioMux (1)
Federico Lucifredi
Frank Lee
Gabriele Mohr
Gerrit Beine
Helman Rene Taleno Martinez
Helmut Schaa
Henne (6)
Herbert Graeber
Holgi (2)
Hubert Mantel (1)
Ioan Vancea
J. Daniel Schmidt (1)
Jaime Andrés Vélez Osorio
James Tremblay (7)
Jan Blunck (4)
Jan Loeser (1)
Jan Madsen (1)
Jan Nieuwenhuizen
Jan-Christoph Bornschlegel (3)
Jan-Simon Möller (19)
Javier Llorente (2)
Jigish Gohil (22)
Jiri Srain (1)
Jiří Suchomel (1)
Johan Kotze (5)
John Terpstra
Joop Boonen
José Oramas
Josef Reidinger (8)
Juergen Weigert (1)
Julio Vannini (7)
Justin Haygood
Kálmán Kéménczy
Kayo Hamid
Kevin Yeaux (10)
Klaas Freitag (21)
Klara Cihlarova
Klaus Kämpf
Klaus Singvogel
kl_eisbaer (10)
Lars Marowsky-Bree
Li Bin
Ludwig Nussel (6)
M. Edward (Ed) Borasky
M. Edwin Zakaria
M. Hill
Manuel Trujillo
Marcos David
Marcus Hüwe (8)
Marcus Meissner (1)
Marcus Moeller (1)
Marcus Schaefer (3)
Martin Lasarsch (8)
Martin Mohring (8)
Martin Schmiderer
Martin Schmidkunz
Masim "Vavai" Sugianto (20)
Matt Sealey
Mauro Parra-Miranda
Michael Andres (1)
Michael Löffler (3)
Michael Skiba
Michal Marek (3)
Michal Vyskocil (9)
Michal Zugec
Miguel Angel Barajas Hernandez
Mingxi Wu
mrdocs
Nikanth Karthikesan (2)
Oprea Lucian
Oswin Zulu
Peter Nixon
Peter Pöml (4)
Petr Mladek (32)
Petr Uzel (2)
Philipp Thomas
Pragnesh Radadiya
Raul Libório
Ravi Kumar
Ray Chen
Ray Wang (1)
Renato de Pontes Pereira
Ricardo Chung
Ricardo Varas Santana (6)
Richard Bos (5)
Robert Lihm
Roland Haidl
Roman Drahtmueller
Rossana Motta (1)
Rupert Horstkötter (10)
Sascha Manns (45)
Savin Alex V.
Sebastian Schöbinger (4)
Stanislav Visnovsky (7)
Stefan Haas (1)
Stefan Hundhammer (5)
Stefan Schubert (3)
Steffen Winterfeldt (4)
Stephan Kulow (10)
Suman Manjunath
Suresh Jayaraman (1)
Susanne Oberhauser (2)
Syamsul Qamar Ngabito
Thomas Göttlicher (4)
Thomas Jones
Thomas Schraitle (15)
Thruth Wang
Tuukka (11)
Ulrich Hecht
Vincenzo Barranco
Wilken Gottwalt
Will Stephenson (1)
Xin Wei Hu
Yuri Tsarev





 

Writing wrapper packages for server applications or a generic YaST module?

1 Star2 Stars3 Stars4 Stars5 Stars (5 votes, average: 4.20 out of 5)
Loading ... Loading ...
Tuesday, January 27th, 2009 by kl_eisbaer Digg!

As we get more and more PHP-, Perl- and other applications like openSIS, Koha, Moodle, … in the Education repository, the question turns up, how to package those applications “the right way”.

A normal user, who wants to use one of these apps, might just choose to install the package and has the problem how to proceed afterwards. openSUSE sadly has no “post config” scripts like Debian based distributions – even the SuSEconfig scripts are deprecated. So all a packager can currently do is:

  1. write a README.SuSE (which is already the case for many packages) and place it in /usr/share/doc/packages/<packagename>/README.SuSE explaning how to proceed
  2. sugget what the user always wants to do and do it via %post-script after the installation of the RPM
  3. combine 1&2 and point the user to a script in the README.SuSE :-)
  4. write a YaST module which can be started during installation or afterwards
  5. any other option I missed (please inform me!)

For the Education project, I’m currently thinking about two ways to make the life of the admins easier.

First: think about “wrapper packages” around the normal packages. I’ll take moodle as example. The normal moodle package installs the php-scripts, an apache configuration and some other config stuff – but will not setup the complete moodle instance. So the user has to install the mysql database himself. An additional wrapper package can do this for him. This package comes with a SQL-Dump of the current moodle version (therefore requires the exact moodle version), and uses a stored mysql-root password to create a new database and insert the database-dump. If needed (for example: the user enables the “user LDAP-Auth wherever possible” checkbox in a (to be written) yast-edu module), additional tasks can be triggered by the wrapper package.

We can also think about calling a “generic” YaST module after installation of such a “needs postconfiguring” package. If we define a place (say: /var/adm/YaST/postinstall/) where packages can place a file containing some important questions to configure the application, and someone writes a YaST module which can be started, this would perhaps be “very cool”. If the user has entered his values, the YaST module can start one or more scripts (coming with the package) and feeds it with the entered values. The biggest questions for this solution:

  1. When should this YaST module be started? IMO it could be enough to let the user start it manually and select the package he wants to configure. => No adaptions of the current workflows is needed. But perhaps there are other options (like calling it via “SuSEconfig”)?
  2. Who can write such a module?
  3. Who defines the config syntax?

Think about a file like this:

<package name=”moodle”>
<questionpack type=”string” action=”/usr/share/moodle/scripts/install_database”>
<question arg=”1″ type=”string”>What’s the database password?</question>
<question arg=”2″ type=”string”>What should be the name of the new database (suggest: moodle)?</question>
<question arg=”3″ type=”string”>What’s the username of the new database user?</question>
<question arg=”4″ type=”string”>What’s the password of the new database user?</question>
</questionpack>

<questionpack action=”/use/share/moodle/scripts/configure_auth_backend” type=”selectbox”>
<question arg=”1″>What auth-backend should be used?</question>
<answer value=”1″>ldap</answer>
<answer value=”2″>mail</answer>
<answer value=”3″>passwd</answer>
</questionpack>
</package>

I think, there’s room for many enhancements in this area – what do you think ?

Should/Could we produce something like a “Windows-Installer” for openSUSE? Or is it enough to provide special “wrapper packages”? Or is “what was hard to write, should be hard to install” still a valid answer?


1 Comment

Comment by Bubli
2009-01-27 21:09:49

Once upon a time, there was a feature in FaTE asking for making it possible to define additional workflow in a pattern. That is, a pattern could contain a definition of a workflow and by selecting it for installation, some additional steps could be added to installation (FaTE #129). It’s pretty old and dusty and seems nobody cares anymore … “Rejecting completely for now to stop evaluation of stuff nobody is interested anymore. Please, open for future products if there is a real interest.” … oh well …

 

Sorry, the comment form is closed at this time.