setting up our own YaST repository for our customers

geeky2 · February 7, 2011, 11:03pm

hello all,

environment: openSuSE 11.3

Are there advantages to setting up our own YaST repository for use by our customers as well as converting our installation to rpm’s?

Background:

We have a PHP, Flex and JBoss based application stack, that we ship as a large tar ball to our customers. we distribute the application stack either on a thumb drive or CD.

the installation/upgrade process is invoked from the command line and basically un-archives the tar file (in to a large directory structure) and runs a few perl scripts - pretty simple stuff.

we want to shift our distribution paradigm from CD’s and thumb drives to allowing our customers to download the tar file from the internet (say an ftp server).

it has been suggested that if we switch to rpm’s and set up a YaST repository - this will afford us more security (above and beyond what ftp will give us) and provide more flexibility overall.

the YaST / rpm approach seems like overkill for what we need - but maybe i am missing something.

i would appreciate any input or experiences people have in this area.

thank you,
mark

malcolmlewis · February 7, 2011, 11:20pm

Hi
You would be better of looking at setting up your own local instance of OBS, with this tool you can build/distribute your rpms.
Portal:Build Service - openSUSE
openSUSE:Build Service Appliance - openSUSE

geeky2 · February 7, 2011, 11:38pm

hello malcolmlewis,

i REALLY appreciate the feedback.

thank you for the reference to OBS, i will take a look at it.

you know - maybe a more fundamental way to examine or evaluate our options (as a development team) - is to ask the question, “do we need to have an rpm based distribution?”

to date (starting about three years ago we have NOT needed an rpm based distribution for our application stack. our tar based approach has proven to be very effective and efficient. our build process, builds the tar ball. the archive is then placed on a CD or thumb drive.

maybe people could comment on what are the criteria for moving to an rpm based distribution ???

i want to be cautious against “connecting the dots” too soon, in other words, just because we want to allow a customer to pull our distribution down from the internet does not “automatically” mean that the distribution needs to be an rpm and therefore needs to be installed via YaST, rpm or YUM.

again - any spirited dialog i can get from this group (or references to other information sources) would be greatly appreciated.

i have to believe that other development teams have been down this road before

lenwolf · February 8, 2011, 8:22am

Hi,

if you DO decide to go the YAST repository route, this will help you:

SDB:Creating YaST installation sources - openSUSE

HTH

Lenwolf

djh-novell · February 8, 2011, 2:35pm

geeky2 wrote:
> you know - maybe a more fundamental way to examine or evaluate our
> options (as a development team) - is to ask the question, “do we need to
> have an rpm based distribution?”

If your tarball just installs to one place (/opt or /usr/local or home
or whatever) with maybe the odd link or script elsewhere, then I’d say
rpm is technically overkill. Whether people might perceive it as more
‘professional’ or something, I don’t know. If you do make an rpm, then
you’ll probably also want to make a deb for Debian/Ubuntu.

> i want to be cautious against “connecting the dots” too soon, in other
> words, just because we want to allow a customer to pull our distribution
> down from the internet does not “automatically” mean that the
> distribution needs to be an rpm and therefore needs to be installed via
> YaST, rpm or YUM.

If you make your tarball available via ftp, you should also publish its
md5sum so people can check its integrity.

DenverD · February 8, 2011, 3:18pm

On 02/08/2011 12:06 AM, geeky2 wrote:
>
> i REALLY appreciate the feedback.

have you yet discovered the possibility to build you own distribution
here: http://susestudio.com/

you can even strip out the openSUSE branding and replace it with
“Geeky2’s JBoss Enterprise Professional Supreme Ultimate To-Die-For
Linux 2011” [or just add a modest splash for your company]

and turn it into an .iso which can be downloaded by your customers,
burned to CD/DVD and used as install media, or mounted as an iso and
run in a VM…

cool huh?

hmmmmm…don’t forget to have your lawyer talk to their lawyer
(another way to say that is: i can’t really tell you much about the
legal and license requirements)

–
DenverD
CAVEAT: http://is.gd/bpoMD
[NNTP posted w/openSUSE 11.3, KDE4.5.5, Thunderbird3.0.11, nVidia
173.14.28 3D, Athlon 64 3000+]
“It is far easier to read, understand and follow the instructions than
to undo the problems caused by not.” DD 23 Jan 11

lslezak · February 8, 2011, 6:47pm

I would mention these advantages for going the RPM way:

dependency handling - rpm will handle the dependencies for you, if your application needs many libraries in specific version RPM will ensure that they are in the system (and stay there)
delta RPMs - you can distribute updates as delta RPMs (binary diff), this saves a lot of download bandwidth if do a trivial change in a huge package
checksums - RPMs and repository metadata are digitally signed, that ensures consistency (proper/complete downloads), prevents from man-in-the-middle attack (changing data during tranfer) and allows to use mirrors of your repo (ensures that the mirror is a verbatim, unmodified copy of the original repo)
OBS (as mentioned before) - also allows you to build packager for different versions/distributions from the same sources, it will rebuild your application automatically whenever any used library is changed

geeky2 · February 8, 2011, 7:04pm

hello djh-novell,

>>
If your tarball just installs to one place (/opt or /usr/local or home
or whatever) with maybe the odd link or script elsewhere, then I’d say
rpm is technically overkill. Whether people might perceive it as more
‘professional’ or something, I don’t know. If you do make an rpm, then
you’ll probably also want to make a deb for Debian/Ubuntu.
<<

yes - the application stack “tar ball” has EVERYTHING in it. we even distrbute our JDK, JBoss, apache config files, pear files and more in the tar.

we also maintain our own “tweaked” openSuSE 11.3 distribution. i use makeSUSEDVD for this.

we have the customer install the “tweaked” OS, then they install our application stack on top.

essentially - we manage all of the dependencies and KNOW that everything is going to work.

>>
If you make your tarball available via ftp, you should also publish its
md5sum so people can check its integrity.
<<

agreed - this is one of the requirements for the new “Upgrade Facility” that we are building.

thank you
mark

geeky2 · February 8, 2011, 7:17pm

hello denverd

LOL at your reply - very humorous.

>>
have you yet discovered the possibility to build you own distribution
here: Welcome – SUSE Studio

you can even strip out the openSUSE branding and replace it with
“Geeky2’s JBoss Enterprise Professional Supreme Ultimate To-Die-For
Linux 2011” [or just add a modest splash for your company]
<<

yes - i build a “tweaked” version of openSuSE 11.3 that we ship (along with our application stack).

>>
and turn it into an .iso which can be downloaded by your customers,
burned to CD/DVD and used as install media, or mounted as an iso and
run in a VM…
<<

yes - we do this currently.

the “tweaked” OS is shipped on a DVD or can be downloaded from our ftp site.

the application stack can / is turned in to an .iso file and burned to a CD. we can also distribute on a thumb drive or allow
the customer to download from our ftp site.

for the record -

the entire process is working.

we were planning on maintaining the existing build and packaging scheme (tar / zip files) along with adding new flex and php pages to our application so that the user could review and pull updates down from a site in a more user friendly manner.

the impetus for my postings on this forum was the need to “justify” our current packaging scheme, eg why aren’t we using rpm’s to distribute and install our application stack and updates.

i am hoping that this dialog forces me to be honest with myself about the way we are doing things now.

at the same time, i don’t want to shift our packaging and deployment paradigm if there is no significant gain in doing so.

thank you,
mark

cool huh?

DenverD · February 8, 2011, 8:25pm

On 02/08/2011 07:36 PM, geeky2 wrote:

> for the record -
> the entire process is working.

Rule 1: if it ain’t broke don’t fix it

however, keep reading…(if you wish)

> we were planning on maintaining the existing build and packaging scheme
> (tar / zip files) along with adding new flex and php pages to our
> application so that the user could review and pull updates down from a
> site in a more user friendly manner.

well, what could be more friendly than

putting the entire ball of wax (tweaked OS + JBoss whatever) on a
DVD (or twelve) and
building a repo and making it available to your customers…

that way (if your JBoss RPMs are made right, for YaST) they can use
YaST to update both their tweaked OS (as security packages roll out)
and the JBozz…

> the impetus for my postings on this forum was the need to “justify” our
> current packaging scheme, eg why aren’t we using rpm’s to distribute and
> install our application stack and updates. ?

because it is easier to not switch?
(i don’t know, is this a test? do i get a prize?)

> i am hoping that this dialog forces me to be honest with myself about
> the way we are doing things now.

so, get real!

> at the same time, i don’t want to shift our packaging and deployment
> paradigm if there is no significant gain in doing so.

well, as far as i can see (from here) if your customers are happy with
tars, and you are happy with tars…and by not switching you don’t
have to build a repo OR build RPMs to support your extra software OR
teach the old customers how to use YaST OR change your current support
documentation OR technical support help text OR etc etc etc

then . . . the question becomes:

How much does it cost (time/wages/etc) to change vs not change
and
are the benefits of change sufficient to offset the cost
plus
what are the risks of change
and
is the company willing to take the risk for the benefits expected?

i mean, this is simple second year MBA stuff at Harvard…get real!

ymmv

–
DenverD
CAVEAT: http://is.gd/bpoMD
[NNTP posted w/openSUSE 11.3, KDE4.5.5, Thunderbird3.0.11, nVidia
173.14.28 3D, Athlon 64 3000+]
“It is far easier to read, understand and follow the instructions than
to undo the problems caused by not.” DD 23 Jan 11

speculatrix · May 11, 2011, 1:01pm

it’s not actually too hard to create an RPM which is really just a fancy tarball.

in fact, I am doing this at the moment with a bunch of php5 add-ons that you can only normally get through PEAR and PECL.

as people have said, the nice thing is that you have dependencies, signing, checksums etc.

robin_listas · May 12, 2011, 11:33am

On 2011-02-07 23:06, geeky2 wrote:
>
> hello all,
>
> environment: openSuSE 11.3
>
> Are there advantages to setting up our own YaST repository for use by
> our customers as well as converting our installation to rpm’s?

There is a packaging mail list, where you could get more technical answers,
I think.

IMO, the main advantage would be dependency checks, and that rpm database
knows about your application. It would not be “hidden”.

The advantage of a tar is that it can be non distribution specific.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)