[Fedora-livecd-list] Welcome Pilgrims, please don't take our land...

[Jane Dogalt]

> > - Regarding Jasper's thread about anaconda rootpath installs being
> > closer to "real" installs than your yum 'hack', ACK!!!  One of my
> > biggest complaints all along has been the utter dangerousness of
> doing
> > the install as root on a particular host system, and having faith
> that
> > your rootpath install is not pulling in dependencies on the host
> build
> > hardware config.  
> 
> I don't buy this. First of all, installing Fedora nowadays simply
> amounts to
> 
>  1. Prepare target file systems
>  2. installing packages to target file systems
>  3. write out some configuration files
>  4. potentially do some boot loader stuff (maybe do a new initramfs)
> (5. potentially relabel the OS)
> 
> and you can inspect this by looking at all the RPM's and how the OS
> in
> general work. If anaconda is doing other magic, we simple have to fix
> the OS to make anaconda not do that. That's my stance anyway, not
> everyone may like it.
> 
> Btw, ideally we'd didn't have 3., I note that we're doing pretty good
> here, most of the OS works without nasty configuration files
> nowadays.
> Sure, some things you can never get away with but my suggestion is to
> move that to a firstboot / selectable at run-time scheme (examples
> are
> keyboard configuration / language selection etc.)
>  
> Anyway, I think the bottom line is that if the package set yum/rpm
> pulls
> in depends on your hardware configuration or anything else, then it's
> a
> bug we need to fix in yum/rpm. One such bug actually exists, I just
> filed it
> 
>  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207600
> 
> Maybe it's just me doing it wrong though.

No, I suspect you're just running into bugs under the rug.  I agree
that it seems like much progress is being made on this front (meaning
the right goals are in place).

Here's another one I don't think I bothered to file-  Does libselinux's
%pre/post still do an /sbin/init invocation?  Honestly after I realized
that selinux isn't transparent (I.e. I can't move around my apache
docroot without knowing some selinux crap), I stopped using it and
caring about it.  (I'll just wait for you smart redhat folks to fix it
and make it truly transparent so that I can enable it and not worry
about it.  Till then I'll live without it)

Anyway, tieing into what you said about shell versus python, I almost
want to send an email like this to anaconda-devel and other lists-

Subject: Is anaconda "the installer"?

I.e. it seems like python (especially after my recent pygtk/glade
project I did for school) is in fact great for event driven GUIs.  But
bash/sh should be the language IMO for "the installer".  And anaconda
should be the GUI interface to "the installer".  From my perusing of
anaconda code, I don't think thats how things are.

It's very interesting that you basically wrote your own installer.  I
probably did as much or more work getting qemu to be my install engine.
 What I would *like* to see, would be a (almost surely non-python
based) installer that is seperate from anaconda, which could be used by
livecd generators.  (which you would have used, rather than doing it
yourself.  I like your implementation choice, but I also still feel
pretty comfortable with my process which involves doing the completely
normal anaconda path under qemu).

> 
> > My solution is to do the install under qemu, which
> > also buys you a pure non-root system, which I don't know about you,
> but
> > running kadischi on any system other than a dedicated build system
> > scares the crap out of me (even after jkatz fixed the bugs where
> > kadischi via anaconda would nuke the host build systems timezone
> and
> > network configuration)
> 
> Well, running things in virtualized containers is always a safe bet,
> but, really, I aim for pilgrim to be robust enough to not have to do
> this. Reality is that you just have to be extremely careful when
> doing
> things as root. It seems to work pretty well so far.

Certainly your writing your own installer seperate from anaconda can
give you a better feeling that tons of code isn't being run as root in
a way that it wasn't really designed (well) from the ground up to do. 

But the other major thing is general security.  If it wasn't code that
you had written yourself, how comfortable would you feel trying to use
your main workstation to generate a custom livecd (when it's churning
away in root-mode for hour/s)?

If my project is successful, I forsee people feeling much more
comfortable doing a -

(as root) yum install vsys (or local per user root-less install)
(as user) vsys generate liveiso \
   --config=mediacenter_appliance.xml \
   --addpackages=myfavoriteeditor,meld \
   mylivedvd.iso

> 
> Btw, do qemu support x86_64 and ppc these days?

If you do a yum install qemu, you'll have qemu-x86_64 and qemu-ppc in
your path.  I haven't actually used them though.

> 
> > - I did like the conversation about stateless.  They are different
> > projects, but the idea of hardware agnostic physically portable
> system
> > disks, is very interesting.  Dare I bring up an idea that an alan
> cox
> > post a while back made me think of...  (store a qemu system state
> file
> > on the liveiso, boot it, display it into a vnc window that (all
> > autostart), then when you shut down, save the qemu state, do an
> xdelta
> > diff on orig sysstate, upload data diff to usb-stick or
> gmailfs/ftp,
> > such that on next boot, you get your hibernated virtual desktop
> back
> > exactly as you left it...)
> 
> Again, I'm not sure why this is useful. 

This was me going completely off-list-topic.  Total tangent. 
Persistant (network) virtual desktops (different implementation than
youos, or whatever).  I might be just a little ADD :)

-dmc/jdog


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com