{Switched On} RPM creation and installation

[Richard Newbould]

Hi Peter T!

Really glad you can make the dev weekend!

The current RPM requirements, which I hope we can tackle this weekend:

* Ed Buckley - needs to produce an RPM for installing Moodle together with Switched On configs.  He has some technique for writing custom stuff into the database to save a lengthy manual setup

* Petri Jarvinen needs to create RPMs to install Dansguardian with and the Squid proxy that will do odd networking stuff to make all web traffic route thro the proxy.  This will thus be existing RPMs as dependencies and added stuff that may just be a script.

* In like manner a number of projects are going to come to fruition that will involve installing dependency RPMs, some of our custom files and config scripts that need to execute.  The RPMs we produce may also become dependencies for others to be installed on top.

As discussed, it would be great to develop a "Super Switched On RPM" that installs the rest of the Switched On RPMs.

Petri was going to produce a "poor-man's" autoyast/kick-start so we could test out our package installation from a OpenSUSE base-install.  However, given this "SuperRPM" you mentioned Pete, I'm not sure it's needed.  Please discuss and decide what value there may/may not be in the "poor man's RPM."

It would be really fab to have some structured and easy process to create RPMs from our code.

Re setting up a Switched On YUM Repository - As discussed, we have an apache server that you can install a YUM repository on.

The wiki and subversion code can be accessed via:  http://code.google.com/p/so-class2/

Please wiki practical instructions on how to do the things you're setting up: http://code.google.com/p/so-class2/wiki/Workpackage_RPMs

I have added requirements to this page, and it can be extended by you as per: http://code.google.com/p/so-class2/wiki/WorkpackageDocumentationInstructions

Instructions for finding the Dev Weekend... http://code.google.com/p/so-class2/wiki/SODW1005 (bottom)

Cheers,

Richard

--
You received this message because you are subscribed to the Google Groups "so-class2" group.
To post to this group, send email to so-c...@googlegroups.com.
To unsubscribe from this group, send email to so-class2+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/so-class2?hl=en.

[Petri Järvinen]

Hi all.

Unfortunately I cannot be physically present for the weekend but I
have some questions, challenges and maybe even proposals
regarding way of packaging, delivering and installing switchedon sw content.

I was building the transparent proxying & dansguardian setup for web
content filtering purposes and needed a way to pack it together.
It consist of following different things:

a) rpms: squid, dansguardian, libpcreposix0. Out of these dansguardian
is not found from standard SuSe repositories and none of them is
installed automatically with the standard distro setup.
b) customized configuration files for squid & dansguardian that needs
to be copied into place AFTER installing squid & dansguardian
respectively
c) tar.gz arcive containing blacklisted sites/urls. that need to be
copied into place after dansguardia is installed.

=> As a summary: Standard unmodified rpm's & customized content.
=> Need to automate all the steps from rpm-installation to service
startup & configuration.

I decided to do it as follows:

0. Deliver all needed content as tar.gz archive - containing (rpms,
customized copies of config files)
1. Create a local zypper repository (/opt/switchedon) with those 3
needed rpm's (I prefer zypper over yum in SuSe)
2. Install dansguardian with zypper and let zypper install dependency
packages automatically
3. Copy customized versions of squid & dansguardiang config files from
/opt/switchedon to respecitive correct places
4. Start & enable needed services

The way how I automated steps 1 - 4 was with my poor mans installation
framework. (framework is attached)

Framework is based on tasklist-file that contains all commands to be
executed. Framework executes then 1-by-1 and
keeps track of which commands are succesfully executed. If failure is
encountered the execution of tasklist can be
redone and it automatically skips the already succesful steps -
effectively continuing from the failed step.

So in practise I need to do:

0. mkdir /opt/switchedon (if not already present)
1. extract installation framework to /opt/switchedon (if not already present)
2. Extract the delivered stuff into /opt/switchedon
3. Execute switchedon_installer.sh -t setup_dansguardian
4. collect the profit ;)

Based on this my initial proposal for way of delivering SW to
switchedon would be.

1. Use & deliver only official RPMs - no modifications to then (no
custom %pre or %post scripts)
2. rpms and conf files etc content delivered as tar.gz archives
3. tar.gz archives extracted to one directory that is turned into
zypper repository
4. %post scripts implemented as swichedon_installer tasklists that
contain all things from rpm-installation to starting of services.

Then installing certain feature is as simple as:
- copy sw to system
- execute correct tasklist with switchedon installer.


I believe this was really messy description regarding my way of doing
things - and by no means this is the
way the things need to be done. This is just one proposal and opening
of discussion.

I'm happy to share more about the switchedon_installer.sh.

[Richard Newbould]

Hi Petri,

What a great start for the weekend!

I can see advantages in your "poor man's installer" for config scripts/copying .tars etc, perhaps in addition to the Switched On RPM approach, as putting config scripts in RPMs is a little like setting them in concrete.  Will be useful to debate the "pros and cons."

 

Richard