Re: Debian on non-Linux systems
Greetings! Personally, I think the debian-beowulf list should suit
fine. There isn't much traffic on this list in general, and I don't
see why mpi et. al. related questions need be cross-posted to
infrastructures.
As one reader of this list, my primary interest in this discussion
would be in making maintenance of Debian clusters easier. Long
discussions about Solaris and other OS's would not be of interest to
me personally.
Thanks for your work on this!
"Bud P. Bruegger" <bud@sistema.it> writes:
> [I'm not on this list, please cc to <bud@sistema.it>]
>
> This is a copy of a discussion I had with Nils Lohner, the author of
> "debian-scala HOWTO: Debian on non-Linux systems". I thought this may be
> of interest.
>
> I again take up his suggestion to move away from debian-devel to a more
> quiet, specialized list. The options I see are (ordered by my preference):
>
> 1 set up a debian-infrastructures (I'm not a debian developer, so I don't
> know what that would take)
>
> 2 we use the existing list of www.infrastructures.org. I already cleared
> with them that this is ok.
>
> 3 I set up an inofficial debian-infrastructure list on my machine
>
> 4 we use the existing debian-beowulf list--but there may be too many
> non-cluster issues coming up and cross-posting to the infrastructure.org
> list becomes difficult since they may not like messages about PVM/MPI,etc.
>
> How do you Debian people decide on such issues?
>
> --bud
>
>
> >Delivered-To: bud@sistema.it
> >X-Mailer: exmh version 2.1.1 10/15/1999
> >To: "Bud P. Bruegger" <bud@sistema.it>
> >Subject: Re: Debian on non-Linux systems
> >Date: Fri, 11 Feb 2000 09:27:26 +0100
> >From: Nils Lohner <lohner@hew.ecf.teradyne.com>
> >Sender: uucp@sistema.it
> >
> >
> >I'm swamped with real work for a week or two... my sugestion is to post this
> >to debian-devel and let others jump in, and then perhaps find a more quiet
> >list for discussion.
> >
> >Re: the technical isues you addressed, they sound very reasonable to me, but
> >I haven't worked with this enough to really say how easy/hard it would be to
> >implement- comments from debian-devel would help IMO...
> >
> >A lot of what needs to be done is laying the groundwork for this system, and
> >documenting what is done and why... then people will use, understand, and
> >want to enhance it.
> >
> >Regards, Nils.
> >
> >
> >In message <3.0.6.32.20000208134549.009f8c60@mail.sistema.it>, "Bud P.
> >Bruegger
> >" writes:
> >>Hi Nils,
> >>
> >>I just write down some of my thoughts as they flow. Apologies if I repeat
> >>something of the last mail...
> >>
> >>* I'm probably more ambitious in my ideas than you :
> >>>I think we should go the 'apt-get source and compile' road for a while
> >>>until at least that works, and then possibly consider binary dists for
> other
> >>>systems/arches.
> >>But it may be helpful to see the goal to reach even to make small steps.
> >>
> >>* One of the great things of Debian source packages is that they kind of
> >>standardize the source layout and build/install process--even if done
> >>manually (and not with binary packages). Installing from a debian source
> >>(diff applied) is surely easier and less error-prone than doing from the
> >>original source where you have much more variation.
> >>
> >>* In this line of thought, debianization can be seen as two things:
> >>(i) standardization of the source (e.g., consistent strategy of where to
> >>put what kinds of files)
> >>(ii) automation of the building and installation process in a debian
> >>specific way.
> >>I believe that (i) is directly useful for any platform/OS. And in (ii) the
> >>debian specific solution can be hidden behind an API. This makes it
> >>possible to plug in either a debian specific "backend" to the API or
> >>Solaris-, AIX-, etc. specific one.
> >>
> >>* Some examples shall illustrate this:
> >>- Installation of files on Debian follows the file hierarchy standard--but
> >>other platforms don't conform with it. But having the source package
> >>standardized means that the debian installation can copy 1:1 and the OS foo
> >>installation can install all files in the /bin branch to /opt/bin or
> >>similar...
> >>- One of the debian specific things is to add cron entries. If this could
> >>be hidden behind an API similar to "add_cron_daily (<entry>)". On a debian
> >>system, the debian backend (here the library routine add_cron_daily) put's
> >>the "entry" in a file of its own and copies it in /etc/cron.daily; on some
> >>other system it may edit /etc/crontab or anything else.
> >>- Similar things are possible for starting and stopping daemons, for init
> >>scipts (/etc/init.d/) and runlevel management, for entries in
> >>/etc/inetd.conf, for entries in the package database, etc.
> >>- debconf is already going in this direction
> >>
> >>* I was wondering some time ago if it wasn't possible to largely (80-90%
> >>automate a translation from current to API-conformant source packages).
> >>Some reasonably simple perl script that finds things such as "echo" and
> >>"read" and converts them to the corresponding API call ("debconf" in this
> >>case). I imagine that this would reduce the effort of a transition
> >>enourmously.
> >>
> >>* I believe that the effort for doing this is not enormous. Particularly,
> >>if you believe that debian source packages will be used quite routinely on
> >>multiple non-debian platforms, the overall effort for {changing the
> >>sourepackage once and writing backends for each platform} is smaller than
> >>changing each sourcepackage (incl. scripts, etc.) for each platform.
> >>
> >>* The biggest benefit of this approach is evident when looking beyond the
> >>scope of your howto: Using this method, it seems to me that from a single
> >>(modified debian) source, it is possible to (directly or indirectly) not
> >>only build debian binary packages for other platforms, but also AIX, or
> >>Solaris packages and, why not, RPMs and other Linux packages.
> >>
> >>* If what I outline above is a reasonable approach for what you have in
> >>mind, it would provide a great boost to Debian if it came out with the
> >>first kind of universal source package. This would mean that a large
> >>number of people would package their software as debian source packages
> >>since with a single effort, the software could be packaged for multiple
> >>distributions and platforms. Debian would be the great beneficiary since
> >>it would largely increase the availability and up-to-dateness of debian
> >>packages.
> >>
> >>* I believe that Debian would be ideally suited for such a thing since it
> >>possibly has the cleanest and best thought through approach to
> packaging...
> >>
> >>Sorry, I got carried away going way beyond technical issues.
> >>
> >>I'd be interested in your opinion on how feasible my vision is, whether you
> >>think my judgement of "social benefit" is realistic, and whether a critical
> >>mass of debian developers could be interested in such an approach...
> >>
> >>---
> >>
> >>> let me know what you end up doing.
> >>
> >>For cluster administration, my initial idea was to use apt/dpkg on every
> >>single machine, controlled from a central host (the "gold server") by GNU
> >>cfengine or similar. The big problem that I see is that apt/dpkg attempts
> >>to change the configuration of the local machine and this is in big
> >>conflict with the goal of keeping the configuration for the whole cluster
> >>(everything that is "stateful") on the gold server. To bridge the gap
> >>between local machine and gold-server-based configuration management seems
> >>quite impossilbe with the current package approach. Actually, a universal
> >>source package that converts to debian-cluster binary packages may be one
> >>solution.
> >>
> >>In the meantime I'm exploring possibilities of using apt/dpkg only on the
> >>gold server and using file copy and/or network filesystem techniques to
> >>"propagate installation" to all other machines in the cluster. Coda looks
> >>like the most eligant and easiest solution at the moment (but it may not be
> >>stable enough...). But even in this case, I intend to manage multi-host
> >>sources for configuration files from which the actual configuration files
> >>are produced for every host by some preprocessor. This requires a
> >>modification of the configuration management aspects of the package tools.
> >>
> >>Debian on clusters and infrastructure is probably another good example for
> >>how the "universal source package" approach is very useful even within the
> >>debian domain...
> >>
> >>I searched for "cluster" on the debian-devel archive today and there was
> >>some talk about the need for a cluster list but I saw no evidence that this
> >>was ever done. The beowulf list has some cluster-related issues... I
> >>suppose I'll have to post the question on devel as you suggested...
> >>
> >>cheers
> >>
> >>--bud
> >>
> >>/------------------------------------------------------------------------\
> >>| Bud P. Bruegger, Ph.D. | mailto:bud@sistema.it |
> >>| Sistema | http://www.sistema.it |
> >>| Information Systems | voice general: +39-0564-418667 |
> >>| Via U. Bassi, 54 | voice direct: +39-0564-418667 (internal 41)|
> >>| 58100 Grosseto | fax: +39-0564-426104 |
> >>| Italy | P.Iva: 01116600535 |
> >>\------------------------------------------------------------------------/
> >>
> >
> >
> >
> >
> >
> /------------------------------------------------------------------------\
> | Bud P. Bruegger, Ph.D. | mailto:bud@sistema.it |
> | Sistema | http://www.sistema.it |
> | Information Systems | voice general: +39-0564-418667 |
> | Via U. Bassi, 54 | voice direct: +39-0564-418667 (internal 41)|
> | 58100 Grosseto | fax: +39-0564-426104 |
> | Italy | P.Iva: 01116600535 |
> \------------------------------------------------------------------------/
>
>
> --
> To UNSUBSCRIBE, email to debian-beowulf-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: