This might not be that useful, but it’s fun.
If you look at the openSUSE installer during the time it’s busy, you can see at least 4 types of progress bars shown:
My goal for this hackweek is to unify them as much as possible. So, now I have something to show. The prototype works on openSUSE 11.0 Alpha2 and unifies steps 1-3. Here is a screenshot:
For some days now I’m working on a GUI written in python. I needed X and konsole, so I gave python-yui (python-binding of libyui) a try.
Libyui is the YaST2 User Interface library and python-yui is part of openSUSE 11.0.
If you want to have a quick look you can try my (demo-) widgets.py. It shows some, but not all widgets available. Klaus Kaempf uploaded it to the svn (tnx!).
Dependency:
zypper in python-yui
wget -nd "http://svn.opensuse.org/svn/yast/trunk/libyui-bindings/swig/python/examples/widgets.py"
a) with GTK/QT GUI:
python widget.py
b) with ncurses/konsole GUI:
export DISPLAY2 = $DISPLAY; unset DISPLAY; python widget.py ; export DISPLAY=$DISPLAY2 ; unset DISPLAY2
Have Phun!
Edit:
Here’s a screenshot,
There has been a report (with further information at this page and at the FAQ) looking at package management security on various distributions that IMO was rather condensed in its summary report and therefore raised some false alarms for various distributions including openSUSE.
Ludwig, one of our security experts, sent out a mail with a reaction to the report and I’d like to point out some of the things from the report and how it’s handled in the openSUSE 11.0 distribution.
Let me state first the major lines of defense that openSUSE uses:
The described attacks are:
Note that when I speak about YaST I mean everything that uses the openSUSE package management library libzypp which includes YaST, zypper and the updater applets.
Note also that the FAQ has a question about the download redirector: “Q: What about OpenSUSE’s download redirector? Does it increase or decrease my security? A: OpenSUSE’s download redirector increases the user’s security…”. I’d like to thank Christoph Thiel, Marcus Rückert and Peter Pöml for their work over the years on the redirector. Peter is the current maintainer and did the last rewrite including the serving of metadata.
Note: if you use SUSE Linux enterprise products, then only servers owned by Novell are used via secure https connections which avoid all these attacks.
Our package management and security experts have been reviewing and improving the security aspects of the package management stack continuously – and the report shows that they were successfull.
From May 30th to July 4th we had a YaST workshop in Nuremberg. The workshop was basically a hackshop as we wanted to work on cool and new things for YaST during this week.
There is one big change in YaST in openSUSE 11.0 – yea, we found out that there are even more colors than gray, ok – but there is one that is not really visible to the end-user. Stefan Hundhammer, maintainer our YaST UI, completely separated the UI from the rest of the YaST infrastructure. This now makes it possible to use the UI directly, from anywhere, independent from our YaST-own-language YCP. So with a team of four hackers we wanted to prove that we can write a YaST module in plain C++ using the new modularized UI directly. And here is the outcome:
We went for rewriting the registration module (well, we chose it because I know it well, as I am the maintainer, and it will change anyhow for the next release). This module is not that integrated in the overall YCP world, so it should be feasible. First we had to find an alternative way to access system configuration files, as this is done by so-called SCR agents in YCP. To make life easier (and future development faster) we had to look for a replacement of our YCP Wizard Seqencer. And of course we redesigned all dialogs to make them more intuitive.
We solved all the issues and now have
And as everybody wants to see screenshots, here they are:
The code is just a proof of concept and not yet reusable for new YaST modules but everything we wanted to show works great. We will continue to work on such kind of modules and in that process move the generic parts out into single libraries so that they can be reused and even may be exposed to scripting languages.
Writing YaST module this way has lots of advantages
If you are interested in the source code, have a look at my svn repo and if you want to help join the team and contact us on our mailinglist.
In order to give an answer about “Why this package will be installed and who needs it?” I have added a new Dialog in the QT single package selector:
Select one item (pattern, package) in the single selection frame, use the right mouse button and select “Show solver information”. A solverrun will be made for this item and the result will be shown with this dialog.
You can navigate through the tree via the overview frame:
After you have selected one item in the tree you can see more information about:
e.G. this item will install two further patterns due to the shown dependencies.
In order to decrease the complexity of the tree you can blind out:
So you will get a shrinked tree:
Technical Background:
This is a simple Qt Dialog widget which can be used in other programs too. ( Package libqdialogsolver1)
YaST uses this widget as a YaST plugin. So if this package is not available you will get a popup in single selection only.
You run Linux already but want to install 11.0? DVD image takes too long to download? Don’t want to waste a CD for the mini iso? A router connects you to the internet?
Check out setupgrubfornfsinstall. It’s a dialog based shell script to prepare remote network installations. It was primarily made for use in LANs but now also supports direct installation from opensuse.org. Just run the script, select 11.0 and it will download the kernel and initrd used for installation. After that it adds an entry to your boot loaders’ config file with proper parameters. Reboot, select the new entry and the installation starts.
[PS. I coudn’t resist. I just had to name the package ‘*Kit’. 😉 ]
Need to do a firmware update with a DOS program?
Can get tricky if you don’t have a DOS system around. We used to provide a bootable floppy image for that in the past (package dosbootdisk). But who has a floppy drive anyway?
So, here comes the new
FirmwareUpdateKit package. Install it and run run, e.g. fuk --grub foobar.exe That’s it. The next reboot gives you the option to start DOS and run foobar.exe.
fuk can also create bootable ISOs and, of course, even floppy images.
It would be nice if libzypp had some framework that allowed to implement extensions like e.g. a history of installed and removed packages easily.
I’m currently looking into the boost signals library to see if we could use it to provide hooks for such extensions.
A future ZYpp::commit would then emit signals e.g. before and after installation/deletion of packages. Some extension code could then connect to those signals to create e.g. such a history.
Another candidate would be the repository management emitting signals as repositories are added removed refreshed.
There is some work going on to put installation source creation functionality into kiwi.
At the moment kiwi can use prepared installation sources such as:
But what if you have a local Build Service building some binary only packages and you wish tp make a installable media set from, say, “SLES + binary only drivers”?
You can use the inter-BS-Connectivity feature to only build the drivers (and not the whole distribution) in your BS and then create an installation source from your main BS project.
This is possible since release of the package kiwi-instsource which extends the functionality of the config.xmlfile to allow the compilation of an installation source from scratch.
Hereby “scratch” means directories containing .rpm and .spm files. Of course some information must be provided for the metadata creation — but this is also all in the config file (with one known exception — the PDB data).
The rest is figuring out which packages must be on the installation source.
Since it is perfectly ok to have conflicting packages in instsources, there is no dependency check or package resolving in this stage. The information must come from the user.
Therefore the package list may become rather long and I already plan to implement some simplification.
These plans include:
Quite often I get bugreports that the hardware detection doesn’t find the monitor. Well, what should I do? We run a Video BIOS function for it, and if the BIOS can’t see the monitor, we’re out of luck.
But maybe not? It can well be that running BIOS code in Linux is not the best idea either.
To shed some light I wrote a small (6.5k if you must know) DOS-program and put it on a bootable CD. If that can’t detect the monitor it’s probably the BIOS’s fault, if it works blame, well, someone else. 😉
On a side note, the program was created with the usual gcc. It’s really surprising what you can do with a nice include file and a linker script.
Adrian Schröter (12)
Agustin Chavarria (6)
Alessandro de Oliveira Faria (13)
Alex Barrios (12)
Alexander Naumov (10)
Alexander Orlovskyy (3)
Alin M Elena (5)
Andrea Florio (27)
Andreas Jaeger (70)
Andreas Stieger (12)
Andrew Wafaa (31)
Arvin Schnell (9)
Atri Bhattacharya (3)
Bernhard Wiedemann (31)
Bonnie Kurniawan (1)
Bruno Friedmann (98)
Calumma Brevicorne (29)
Carl Fletcher (1)
Christopher Hobbs (17)
Ciaran Farrell (3)
Stephan Kulow (17)
craig gardner (2)
Stephan Barth (2)
Thomas Schmidt (2)
Dinar Valeev (1)
Dirk Mueller (2)
Dmitry Serpokryl (7)
Efstathios Iosifidis (21)
Fabio Mucciante (5)
Federico Lucifredi (9)
Greg Freemyer (1)
Holger Sickenberg (2)
Hubert Mantel (1)
Ilya Chernykh (5)
Ismail Donmez (1)
J. Daniel Schmidt (2)
James Tremblay (7)
Jan Blunck (4)
Jan Loeser (3)
Jan Madsen (1)
Jan-Christoph Bornschlegel (3)
Jan-Simon Möller (20)
Javier Llorente (12)
Jigish Gohil (85)
Jiri Srain (1)
Jiří Suchomel (3)
Johan Kotze (5)
José Oramas M. (6)
Josef Reidinger (16)
Juergen Weigert (1)
Julio Vannini (9)
Dinar Valeev (5)
Kevin "Yeaux" Dupuy (11)
Klaas Freitag (55)
Lars Vogdt (11)
Ludwig Nussel (13)
M. Edwin Zakaria (4)
Marcus Hüwe (39)
Marcus Meissner (2)
Marcus Moeller (3)
Marcus Schaefer (4)
Martin Lasarsch (8)
Martin Mohring (11)
Masim "Vavai" Sugianto (20)
Michael Andres (1)
Michael Löffler (7)
Michal Marek (7)
Michal Vyskocil (12)
Miguel Angel Barajas Hernandez (2)
P Linnell (2)
Nelson Marques (55)
Nenad Latinović (1)
Nikanth Karthikesan (2)
Przemyslaw Bojczuk (1)
Peter Pöml (4)
Petr Gajdos (2)
Petr Mladek (60)
Petr Uzel (5)
Ray Wang (1)
Raymond Wooninck (1)
Ricardo Chung (7)
Ricardo Varas Santana (7)
Richard Bos (11)
Robert Schweikert (16)
Rossana Motta (1)
Rupert Horstkötter (10)
Sascha Manns (66)
saydul akram (3)
Sebastian Siebert (6)
Shawn Dunn (2)
Stanislav Visnovsky (7)
Stefan Haas (1)
Stefan Hundhammer (5)
Stefan Schubert (7)
Steffen Winterfeldt (8)
Suresh Jayaraman (3)
Susanne Oberhauser (3)
Thomas Göttlicher (6)
Thomas Schraitle (26)
Togan Muftuoglu (3)
Tuukka Pasanen (36)
Will Stephenson (22)
YaST Team (90)