Kobliha's blog

Adding Several Repositories with a Single Installation URL

2011-09-02T11:52:00.001+02:00

This is a simple but quite powerful feature of installation. By using a modified installation repository you can add several other repositories automatically (or let user decide which repositories to add). The only thing you need to do is to create an add_on_products.xml file describing all the additional repositories and add it either to root of the installation repository or root of the installation system.

Installation repository can be easily modified just by adding the file there, installation system (inst-sys) can be easily extended by Linuxrc DriverUpdate.

Let's see the add_on_products.xml file format:

<?xml version="1.0"?>
<add_on_products xmlns="http://www.suse.com/1.0/yast2ns"
    xmlns:config="http://www.suse.com/1.0/configns">
    <product_items config:type="list">
        <product_item>
            <!-- Mandatory -->
            <url>http://download.opensuse.org/repositories/devel:/languages:/ruby/openSUSE_11.4/</url>
            <!-- Mandatory, use "/" if you don't know -->
            <path>/</path>
            <!-- Optional, default => empty list -->
            <install_products config:type="list">
                <product>Product-ID-From-Repository</product>
            </install_products>
            <!-- Optional, default => do not ask -->
            <ask_user config:type="boolean">true</ask_user>
            <!-- Optional, recommended if ask_user == true -->
            <name>Add-on Name to Display</name>
            <!-- Optional, default => selected -->
            <selected config:type="boolean">true</selected>
            <!-- Optional, default => none, set by packager -->
            <priority config:type="integer">20</priority>
        </product_item>
        <product_item>
            ...
        </product_item>
    </product_items>
</add_on_products>

Items Description:

url - Definitely mandatory ;) Defines the URL of additional repository to add.
path - Mandatory by design, defines additional relative path to a product at URL. Use "/" if you don't know.
install_products / product - Optionally defines which products should be selected for installation from that URL.
ask_user - Should be user asked whether to add this repository? Default is false and repository is just automatically added.
name - Name of the repository used in dialog while asking user whether to add that repository.
selected - Defines the default status of repository while asking user...
priority - Optional item defining the priority of repository to add (an integer value between 0 - the highest priority; and 200 - the lowest priority), since yast2-packager-2.21.12

Although this feature works only during [auto]installation, I believe YaST could be enhanced to provide the same functionality while managing repositories on a running system too if needed.

No Sound in Flash?

2009-11-23T15:39:00.002+01:00

I've upgraded my openSUSE 11.1 64bit using esound to 11.2 64bit recently and the result was no sound in flash (e.g., YouTube and other streamed video) but everywhere else it worked. I've googled around a bit but didn't find anything that would work for me. So I tried to switch to pulseaudio but the result was still the same.

It took me some time but finally I found out that flash-player was installed in 32bit version but there were no 32bit libraries for pulseaudio installed. After I installed them and did the windows-like reboot, sound in flash suddenly started working.

The Easiest Way How to Modify Installation System

2009-10-14T16:15:00.002+02:00

Motivation
Sometimes, there is a need to check some patch in the installation system. Of course, we have an article that describe how to Create a Modified Installation System but this one takes a lot of time to prepare, you need a remote server and several things can break.

You can also use Driver Update, but that expects you are able to build RPM with the changes you want to test.

Here you can see the simplest way...

Starting-Up
Start installation from media by adding startshell=1 to the Linuxrc commandline. This will make installation open a shell window before starting YaST/Installer.

You can also boot directly to the installation without adding startshell=1 to the command line but it that case you can't change files that are loaded when the installer starts. Your choice :)

Preparing Installation System
By default, the installation system is read-only but we can cheat it ;)! Let's assume we want to change some YaST script in /usr/share/YaST/clients/ directory in this example.

# The only writable directory is /tmp (and /var...)
cd /tmp
# Copy all clients to /tmp
mkdir clients
cp -ar /usr/share/YaST/clients/* /tmp/clients/
# Bind the writable directory to the original location
mount --bind /tmp/clients /usr/share/YaST/clients

Now you can edit, extend, remove, compile ... etc. the writable clients directory. Hint: If you want to start network (and your network supports DHCP) to copy the patched sources using network, just simply enter dhcpcd eth0 (or similarly according to your current setup).

And ... that's all folks!

Continuing with the Installation
If you have used startshell=1, just simply enter exit command or press Ctrl+d.

openSUSE Community Week

2009-05-11T16:56:00.005+02:00

Are you interested in openSUSE? Would you like to discus openSUSE 11.2 or anything else with developers? Do you need a helping hand for your project? Are you looking for any piece of information about openSUSE?

You can find this and much more on IRC at freenode.org right now because the openSUSE Community Week has already started. It runs for May 11 through 17th.

There are several IRC channels already (#opensuse-project, #opensuse-kde, #opensuse-gnome, ...). Find out more:

YaST Has New Icons / Mascot ... Finally :)

2009-04-27T14:27:00.004+02:00

Finally, we have new YaST icons created by Jimmac based on Klara's idea for the YaST Mascot Contest. Thanks to both :)

The abbrev YaST means Yet another Setup Tool, however it is also used to install or upgrade your system. To find out which YaST modules are installed in your system, write /sbin/yast2 as root in terminal and press the [Tab] key three times - YaST already supports command-line completion.

SLE 11: New YaST Documentation Available

2009-04-14T18:18:00.003+02:00

I've just uploaded a brand new YaST documentation for SUSE Linux Enterprise Server/Client 11. You can find it at here: http://forgeftp.novell.com/yast/doc/SLES11/.

If you would like to modify or create some YaST module for SLE 11, you can find the most recent sources in our subversion repository.

Installation: Enough Space for Every Dialog

2009-03-19T15:32:00.003+01:00

Some installation dialogs of openSUSE 11.1 suffer from having not enough space in lower resolutions, e.g. 800x600. As a work around, Bubli has implemented a movable QSplitter that allows you to hide the installation steps which makes dialog space wider. You can check it out in openSUSE 11.2 Alpha0.

The first screenshot shows a YaST Partitioner in 800x600 resolution during installation. Buttons are not displayed correctly, the menu-tree (System View) hides endings of some entries.

Here you can see the same dialog after moving the splitter to the left side. There is enough space for nearly everything.

This actually means that we can use 133% of your monitor :) ;)

Geeko Wants You!

2009-03-12T12:10:00.003+01:00

Alberto Passalacqua has recently created a new wiki page for community-driven initiative Geeko Wants You! This page is for both 'those who are asking for help' and 'those who would like to help'.

Do you think you can't help making openSUSE better because you don't have enough programming skills? You don't have to code anything: you can, for instance, help improving the Wiki, SDB articles, or just write your opinions on the current solutions or document them for the others.

Although the page is still being heavily developed there are already several areas you can help with (Art and Branding, Communication, Packaging, Testing, Translation, Wiki). Thanks in advance :)

Google Summer of Code 2009 - openSUSE is Looking for Mentors and Students

2009-03-04T12:22:00.001+01:00

Last year, openSUSE participated in Google Summer of Code 2008 and we'd like to participate this year as well.

We (Stanislav Visnovsky, Jiri Srain and I) have already proposed some GSoC Ideas (partly based on the BrainStorming Prague feedback) and now we are looking for projects mentors and students. Of course, the list of ideas is not fixed and it is still in progress...

It's a great opportunity to get in touch with Google-driven stipended open source software development during this summer. Use your talent with mentors help, use what you have learned in school, get some more work experience. Enjoy your work and find new friends. Think about your future.

Are you a student? Would you like to pick strawberries or tomatoes this summer? Would you like to work as desk clerk, shop assistant, or dishwasher in some restaurant? Why? Apply to some of the openSUSE Google Summer of Code Ideas. Extend the ideas.

You should know that Google can still turn down your project, however, it depends also on you whether the project is good and can have a reasonable output.

CJK Languages Support in ncurses Installation

2009-03-02T14:51:00.011+01:00

It's easy to install openSUSE in CJK (Chinese, Japanese, Korean) languages using a graphical interface but when you have to use a text-based interface, you can easily end up in dialogs showing just a question mark for each CJK character. This short howto can help you to set the installation options correctly.
Step #1 Here you can see available Video Mode options. Important: Choosing Text Mode would switch it to 80x25 and because of the CJK characters requirements (2 columns per char) dialogs would be broken. Press [F3] and choose from one of the other modes available.	Step #2 All available languages can be listed by pressing [F2]. Select the language you want to use during installation. Important: You can also select the language later in the first dialog of installation but than you would get a pop-up saying: CJK cannot be used, switching to English as a fallback.
Step #3 Now, we can finally tell the installation we want to use a text-based installation. This is done by writing textmode=1 to a bootloader command-line. See all available bootloader (Linuxrc) options. Now press [Enter] to proceed.	Step #4 Finally, we have booted to the text-based installation with Korean language preselected. N-joy! :)

All You Wanted to Know About Installation Info File But Were Afraid to Ask

2009-02-25T21:09:00.006+01:00

Every time you install or upgrade your system using the installation media (Mini ISO, CD/DVD, ...), the installation application is loaded by Linuxrc. But what you maybe didn't know, Linuxrc writes a special file /etc/install.inf that contains all the settings adjusted before calling YaST. This file is later copied to the installed system and we can use it for, e.g., debugging the installation issues.

These settings are also used, for instance, in second stage (after rebooting or kexec-ing) while setting up the network before the network proposal. Sometimes the file content is changed later by running YaST in first stage, for instance, when adjusting the network for Remote Repositories.

I've create a new reference page at http://en.opensuse.org/Linuxrc/install.inf with entries you can find in that file. This is another log file worth checking if something in Linuxrc/Installation doesn't work as expected.

How Can Community Influence openSUSE

2009-02-20T12:43:00.002+01:00

You have probably seen Stano's blog post How developers see openSUSE. That post gives some details about our BrainStorming in Prague and points to the result of it - Lots of pluses and minuses of openSUSE which are open for extension, discussions, and contribution.

What does this opportunity offer to you? Right here, righ now, you can involve where openSUSE might point to, which features will it have. You can do something for yourself. Yes, you can - openSUSE developers want to discuss our next steps with you.

Interested? So, what could you do now?

Read the pluses and minuses and think about which pieces of information are missing in the listed ones. Is it some link to a reported bug? To an openFATE (feature) entry? Is it a duplicate of some openSUSE Wishlist entry? Or are there missing any tags? Add what's missing.
Are you interested in discussing this with the others (e.g., developers) or even implementing/fixing? Add yourself as Interested and/or write to the already listed ones.
Is the current description/solution proposals/etc. too talkative, too long...? Move it to a separate page, e.g. BrainStorming_Prague#Issue_33 to BrainStorming_Prague/Issue_33, and try to minimize the current description in the BrainStorming_Prague list. It should be as simple (but complete) as possible.
Do you have a proposal, solution, patch? We want to hear from you: contact those people listed as Interested in a particular issue. Use openSUSE mailings lists to discuss that.
Have a lot of fun! :)

Installation Bug-Reporting Extension

2009-02-05T17:32:00.004+01:00

YaST Installation module that everybody uses for installing or upgrading their openSUSE system is often only a framework that calls other YaST modules as plug-ins (such as Users, Partitioner, Software...). If such a plug-in fails, user might not even find that out.

That's why I've created a new InstError YCP module that not only reports that an error occurred, but also in which client (plug-in), reports what to do, where to find logs, and it also tries to find errors in a YaST log. Additionally, user can directly save YaST logs from that error message pop-up dialog.

See an example of Installation Error pop-up:

You can save YaST logs directly from that dialog by clicking on Save YaST Logs... button:

This feature will hopefully help find and fix most of YaST bugs in time. It will be included in the next openSUSE release.

Extending YaST Backup: Uploading Resulting Archive to Your Grandma's Server

2009-01-15T17:23:00.006+01:00

About

You may have seen my previous entry about new YaST Backup feature User-Defined Scripts. Using this feature, you can basically extend your backup profile to call a script before and/or after the system is searched and the archive is created. This blog entry wants to show you an example of usage - uploading the archive to a server using scp.

The Plan

At first, we need to know what we want to achieve. So, let's define it:

Backup archive will be created by YaST (we'll backup some system directories only)
Archive will be uploaded to the grandma's server using scp (grandma@seven)
Backup will be called automatically every day

SCP / SSH Configuration

SCP is a common Linux tool for copying files over network using SSH for authentication. Because scp doesn't support reading the password from stdin, we'll have to use an empty-passphrase SSH key.

Creating an empty-passphrase RSA key:

me@backup:~> su -
Password:
backup:~ # ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/id_rsa_empty_password
Enter passphrase (empty for no passphrase): (just hit Enter)
Enter same passphrase again: (just hit Enter again)
Your identification has been saved in /root/.ssh/id_rsa_empty_password.
Your public key has been saved in /root/.ssh/id_rsa_empty_password.pub.

We have just created a new id_rsa_empty_password RSA key. Its public key part has to be added into the authorized_keys at grandma's account, we'll use the secret part for authorization later:

backup:~ # scp /root/.ssh/id_rsa_empty_password.pub grandma@seven:
Password: (enter grandma's password)
id_rsa_empty_password.pub                      100%  392     0.4KB/s   00:00
backup:~ # ssh grandma@seven
Password: (enter grandma's password)
Have a lot of fun...
grandma@seven:~> cat id_rsa_empty_password.pub >> /home/grandma/.ssh/authorized_keys
grandma@seven:~> rm id_rsa_empty_password.pub
grandma@seven:~> logout
Connection to seven closed.

Now, let's check whether the RSA key works as expected:

backup:~ # ssh -i /root/.ssh/id_rsa_empty_password grandma@seven
Have a lot of fun...
grandma@seven:~> logout
Connection to seven closed.
backup:~ #

Yes, it works. Which means that we have prepared the client (root@backup) and server (grandma@seven) for passphrase-less communication.

Editing a Backup Profile

Start YaST Backup using the YaST Control Center -> System -> System Backup
Create a new (Profile Management... -> Add...) or edit (Profile Management... -> Edit...) an already existing backup profile
Define where to store the resulting archive (it's /var/backup/daily_backup.tar in this example)
Click on the [Expert...] button in the Backup Options dialog
Add a new post-backup script and return to the Backup Options (see the screenshot below)
Define which parts of the system should be backed-up in the next dialog
Finally confirm the profile

The script content for this example is:

#!/bin/bash

echo "SCPing..."
scp -v -r -B -i /root/.ssh/id_rsa_empty_password /var/backup/ grandma@seven:
echo "Backup stored at "`date` >> /var/log/backup
echo "Done"

Testing the Profile

Let's call the backup profile manually to check whether everything works:

Start YaST Backup module
Select the backup profile in the overview dialog
Press the [Create Backup] button ... and watch :)

After the backup is created, you should see something like this:

Archive files were successfully uploaded to the grandma's server.

Automatic Daily Backup

We don't want to call the backup manually but we'd rather like to have it automatically started every day. So, let's set the profile to do so:

Start YaST Backup module
Select the backup profile in the overview dialog
Use Profile Management... -> Automatic Backup...
Select the Start Backup Automatically check-box, adjust the Frequency and Backup Start Time and save the settings by pressing OK.
Leave YaST Backup by pressing OK again.

Now, you'll have to wait until the time you've selected as a backup Start Time. YaST Backup will be called automatically by cron and you should find the new archive on grandma's server later.

YaST Backup: User-Defined Scripts

2009-01-15T10:49:00.008+01:00

About

This is a new feature for YaST System Backup tool which you can find in your YaST Control Center -> System -> System Backup. I was looking for ideas how to improve YaST when I saw this one in Feature Wishlist/YAST related:

Add custom scripts to the YaST backup module
If we could add custom scripts to the YaST backup module, we could backup mysql or postgresql databases.

I've decided to implement it as an expert backup option. Although the implementation and usage are quite simple, it can be a very powerful feature. Basically, you can simply add and/or edit a script before and/or after the backup itself is proceeded. It works for both manually and automatically called backups.

Example

Run the YaST Backup tool.
Add a new or edit an existing backup profile and press the [Expert...] button in the Backup Options dialog. An Expert Backup Options dialog will open.

Add one or more helper scripts in that dialog by pressing the [Add...] button. You can choose from Before and After Backup options, [Browse...] the available scripts or create a brand new one and edit the selected script itself.

Here you can see an example listing two scripts for creating the MySQL database dump before and removing that dump after the backup.

The output of the helper scripts can be seen while running the backup.

I can imagine a lot of possibilities how to use this new feature, for instance, another idea from the YaST Wishlist: In a post-backup script, the resulting backup archive can be copied via scp, ftp, or rsync to server or archived to a tape, burned to a prepared DVD, etc.

System Ugrade: Previously Used Repositories

2009-01-13T13:09:00.005+01:00

This feature has been added in openSUSE 10.3 after being requested this way: Distribution upgrade should offer existing extra installation sources as Add-Ons.

The implementation looks rather simple. When upgrading a system using the installation media (network-based as well) the currently enabled system repositories are offered to be reused during the upgrade itself possibly with modifying the URL (e.g., 11.0 to 11.1) using the [Change...] button.

It's been a while since the basic feature implementation. Several additional (and often hidden) features were also added in openSUSE 11.0 and 11.1. Now it's time to completely rewrite this part of installation to better meet the user expectations.

This is the newly proposed functionality:

Initially, all repositories are proposed to be re-added to the new system but in a disabled state.
User can change the new status to enabled or deleted state.
User can change the repository URL, Name and Priority.
User can be offered an automatic rewriting of the URL if possible, e.g., /10.3/ to /11.1/ if detected (default behavior).
All other repository settings are kept (alias, refresh, ...)
If any of the repositories is remote, the network setup is be checked for existence and user is allowed to set it up if not yet configured.
Simple to understand ...

If you have any additional ideas or requests, please, comment this blog entry or write them to opensuse-factory mailing-list.

Yippee! New YaST Documentation Available!

2008-12-11T14:49:00.003+01:00

I've just uploaded the newest (final) YaST-Development documentation for openSUSE 11.1 to the official documentation repository. You can find it at http://forgeftp.novell.com/yast/doc/SL11.1/

Enjoy!

Say Goodbye

2008-12-11T12:55:00.001+01:00

YaST Mascot Contest - How to submit your ideas

2008-11-03T11:49:00.006+01:00

Current Progress
We have finally reached 24 ideas submitted to the YaST Mascot Contest. Nevertheless, we've got a feedback that it might be quite uneasy to submit an idea, e.g. because it requires editing a wiki page. So, we've decided to extend the possibilities...

How to Submit Your Idea
Either you can upload the picture of your idea to openSUSE wiki and link it from the Ideas Gallery or you can newly send it via e-mail to yast-mascot@opensuse.org.

YaST Mascot Contest

2008-10-23T07:00:00.001+02:00

The YaST Mascot Contest is still running...

YaST Can List Not-Yet Installed Modules

2008-08-29T13:45:00.000+02:00

About

I've seen some requests on openSUSE FACTORY mailing-list recently to show also YaST modules that are not yet installed on the system but available for installation. People sometimes don't know that not all YaST modules are installed by default and thus some of them are not visible in YaST Control Center.

I've created a new package yast2-desktop-files-openSUSE that is built from all know (but slightly modified) YaST desktop files that are listed under new Not Yet Installed tab. Frankly, you can actually see all YaST modules listed there (not only those not-yet-installed ones), I'd have to change the Control Center not to list the already installed ones.

Modified desktop files are stored in the same directory as common YaST desktop files /usr/share/applications/YaST2/ by pattern: $NAME.desktop -> $NAME~install.desktop.

If you click on an icon of a not-yet-installed module, a special YaST module is called to install the required package(s) and run the module if installation is successful.

It's so easy...

This example show how easy is to install YaST DNS-Server Configuration module. Just click on the DNS Server icon in YaST Control Center and click on the Install button later.

YaST automatically installs required packages with dependencies. After the packages are installed, SuSEconfig (and friends) scripts are called.

A newly installed YaST module is started right after the successful installation.

This solution is currently Work In Progress just as a proof of (wrong?) concept.

Links

New YaST Package: http://download.opensuse.org/repositories/home:/locilka/SUSE_Factory/noarch/yast2-desktop-files-openSUSE.rpm
Request on FACTORY mailing list: http://lists.opensuse.org/opensuse-factory/2008-08/msg00316.html

Brand New Features in YaST DNS Server

2008-07-23T17:30:00.004+02:00

New Features

I've recently added several new features into the YaST DNS Server module. Just to list them briefly:

Added new directly supported resource records: TXT, SRV, AAAA
Added support for IPv6 reverse zones
Added support for automatically generated reverse zones (from forward ones).

Automatically Generated Reverse Zones

Because the last mentioned feature is a revolution in managing DNS zones in YaST DNS Server, I'd like present it to you using some screenshots.

Once upon a time, there was a DNS server administrator that had to manage several DNS zones and also keep the reverse zones in order. Every time he changed something in any forward zone, he had to change a reverse record in an appropriate reverse zone. But alas, then IPv6 came and took his TIME! :) ;)

In these days, we don't have to manage three different zones - we can create these three zones (forward, reverse IPv4, and reverse IPv6) and connect them together. After changing some records in the forward zones, the reverse ones are automatically regenerated.

Example: Creating Automatically Generated Reverse Zones

Start the YaST DNS Server, click on the DNS Zones menu item. We start with an empty list of managed DNS zones ...

Add forward zone example.com ...
Add reverse IPv6 zone. Here you have three options how to add it:

Standard form: 4.5.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
Forward form: 2001:db8:0:54::/64
Forward without netmask bits expressed: 2001:db8:0:54:: (defaults to 64 bits)

... another pain solved :)

Add reverse IPv4 zone.

Select the IPv6 reverse zone and enter the zone editor by clicking on the [Edit] button. Select the Automatically Generate Records From checkbox and select example.com zone. This will mark the reverse zone dependent on the example.com zone. Anyway, you will have to add a NS Records (Name Servers for the zone) manually.

Do the same for the IPv4 reverse zone.

Select and edit the example.com zone. All connected reverse zones will be listed in the Basics tab.

Add NS Records for the zone (you have entered the very same records for IPv4 and IPv6 reverse zones already).

Add A records (A translates name to IPv4).

Add AAAA records (AAAA translates name to IPv6).

Close the dialog with [OK] button and finish the YaST DNS Server module. You have just configured your DNS Server providing example.com zone also with automatically generated reverse zones. Every time you change a any record in example.com, the other zones are automatically generated again.

... and they all lived happily ever after ;)

Appendix A - Zone example.com:

example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
ns1 IN A 192.168.0.1
ns2 IN A 192.168.0.2
dhcp001 IN A 192.168.0.101
dhcp002 IN A 192.168.0.102
ns1 IN AAAA 2001:db8:0:54::1
ns2 IN AAAA 2001:db8:0:54::2
dhcp001 IN AAAA 2001:db8:0:54::101
dhcp002 IN AAAA 2001:db8:0:54::102

Appendix B - IPv4 zone:

0.168.192.in-addr.arpa. IN NS ns1.example.com.
0.168.192.in-addr.arpa. IN NS ns2.example.com.
1.0.168.192.in-addr.arpa. IN PTR ns1.example.com.
2.0.168.192.in-addr.arpa. IN PTR ns2.example.com.
101.0.168.192.in-addr.arpa. IN PTR dhcp001.example.com.
102.0.168.192.in-addr.arpa. IN PTR dhcp002.example.com.

Appendix C - IPv6 zone:

4.5.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN NS ns1.example.com.
4.5.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN NS ns2.example.com.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.5.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR ns1.example.com.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.5.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR ns2.example.com.
1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.4.5.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR dhcp001.example.com.
2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.4.5.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR dhcp002.example.com.

Package Search and One Click Install in YaST

2008-07-03T09:50:00.002+02:00

You probably already know that YaST Team has a Workshop/Hackshop in Nürnberg, Germany this week. We are working on several projects. Here you can see the output of one of them...

We (Bubli and I) are working on YaST Interface for Webpin. What is it good for? I'm sure you know the original Webpin written by Benjamin Weber. Once you find a package you want to install, you can click on a One Click Installation icon that would start a special YaST module and install that package.

Our new module connects these features together and adds some more:

YaST module provides the very same searching as Webpin does but using the Webpin XML interface
After some packages are found you can select one or more packages to be installed (from one or more repositories at once)
YaST module creates a XML file describing what will be done and calls the OneClickInstallUI module
OneClickInstallUI module adds the repositories, solves dependencies, and installs the packages
You should be able to run this module directly from the YaST Package Manager

Let's see some screen-shots :)

Package Search module starts with this dialog...

...searching for "apache2"...
...selecting some packages for installation...

...clicking [Next] to get to the "One Click Installation" dialog...

...installation summary...

...successfully installed...

...and that's all ;)

The Very First openSUSE-Only Mirror in China

2008-06-13T10:30:00.003+02:00

A friend of mine, the (famous) developer Coly Li has recently started the very first openSUSE-only mirror at http://www.openSUSE.org.cn/ (DNS still points to the old IP adress, use http://211.166.8.67/ for now).

Frankly, there have been some other openSUSE mirrors in China already, but this is the first one that is going to offer openSUSE exclusively. Moreover, according to Coly, it'll be mirroring FACTORY too. Keep up the good work, Coly! :) ;)

Firewall Services Defined by Packages

2008-06-11T13:53:00.007+02:00

About

Have you ever configured firewall on openSUSE?
Are you maintainer of a package including some service/daemon that listens on ports which need to be open in firewall?
Are you a curious user?

You'd better read this post if you've answered yes to at least one of the questions mentioned above :) ;)

A Bit of History
In the very beginning, we had a iptables-based SuSEfirewall2 and YaST Firewall package to configure it. SuSEfirewall2 itself didn't have any set of services (e.g., HTTP Server, Samba Server), so these services were hard-coded into YaST Firewall.

After some time, we found out that it isn't easy to add and remove services that use the very same ports (e.g., NIS Server, NFS Server) and that we might want to allow other YaST modules (or even other tools) to dynamically open ports for their services as they are configured. For instance, HTTP Server can listen not only on port 80 (the default one) but also on 8080, 443 (for SSL), ...

We've decided that these ports-to-open required by services should be defined and maintained by respective packages in separate files. The feature Firewall Services Defined by Packages has been implemented by Ludwig Nussel in openSUSE 10.2 and YaST has been adjusted to use these services in openSUSE 10.3. Service definitions have been already added into several packages.

"I want to create my own firewall service definition"
That's easy! :) All definitions are stored in /etc/sysconfig/SuSEfirewall2.d/services directory.

There is a TEMPLATE file that you can simply copy to a new service definition (we recommend to name that file according to your package name to avoid conflicts with another packages). Let's assume we have a lightening-server package that contains lighteningd daemon. Copy the TEMPLATE file to a new lightening-server file and edit it.

Example:

## Name: Lightening Server
## Description: Opens ports for the famous Lightening server

# space separated list of allowed TCP ports
TCP="http pump 756"

# space separated list of allowed UDP ports
UDP="756"

# space separated list of allowed RPC services
RPC=""

# space separated list of allowed IP protocols
IP=""

# space separated list of allowed UDP broadcast ports
BROADCAST=""

That's all for creating the definition.

"How can I enable that service in firewall?"
There are two possibilities: manually and by YaST.

If you want to enable it manually, edit the /etc/sysconfig/SuSEfirewall2 configuration file and add lightening-server into FW_CONFIGURATIONS_EXT, FW_CONFIGURATIONS_INT or FW_CONFIGURATIONS_DMZ depending on your current firewall configuration (e.g., if your network interface is in the External zone, you should use FW_CONFIGURATIONS_EXT). Save the modified file and don't forget to restart the firewall service (rcSuSEfirewall2 restart).

To check the configuration, you can still use YaST without starting any UI:

Command: yast2 firewall services show zone=EXT
Returns:

Allowed Services in Zones:
--------------------------

   Zone  Service ID                  Service Name      
   -----------------------------------------------------
   EXT   service:apache2             Apache 2          
   EXT   service:iceccd              icecream daemon   
   EXT   service:icecream-scheduler  icecream scheduler
   EXT   service:lightening-server   Lightening Server 
   EXT   service:sshd                Secure Shell Server

   ...

Using a YaST interface is even simpler. Start YaST -> Security and Users -> Firewall (or just call yast2 firewall as root). Check into which firewall zone is your network interface assigned (see Interfaces). Switch to Allowed Services, change the selected zone accordingly, select Lightening Service from list and click on the Add button. The service will be added into table of already allowed services.

Click on the Next button to see a firewall summary. To save the settings click on the Finish button.

Links

Original WIKI article about Service Definitions Added via Packages for package maintainers

YaST Documentation for openSUSE 11.0 Available

2008-06-10T18:56:00.004+02:00

I've just finished building the YaST documentation for openSUSE 11.0.
You can find it at http://forgeftp.novell.com/yast/doc/SL11.0/

Some pieces might be still missing as the documentation is built from sources and there were huge changes in 11.0 concerning core and UI sources (package splits, moving stuff, etc.).

Scripts and others thingies for building the documentation can be found at http://svn.opensuse.org/svn/yast/trunk/doc/

VirtualBox OSE Has Increased My Productivity

2008-06-03T22:13:00.004+02:00

The title might sound like a business guff but it's actually true ;)

What is VirtualBox?
VirtualBox belongs to a family of system-virtualization applications such as XEN, VMWare or Qemu.

What is it actually good for?
Fully virtualized system can be used for testing system-performance, its memory requirements, trying new distributions or system types ... all without any need to buy another computer, without any need to reinstall your current system. It also makes possible to test several hardware configurations, especially disk layouts (RAID, for instance).

Why VirtualBox?
I've got a brand new company dual-core PC with lots of RAM and I'm currently able to run two different installations at once without being disturbed from my usual work with any notable slowdown. I already had some experience with VMWare (which is too proprietary), Qemu (which is too slow), and XEN (which just didn't fit my needs ;)). VirtualBox was just the best-choice for me, you might try the other ones, it mostly depends on your needs and your personal taste.

Here is a list of features I often use:

One or more network cards with possibility to have a cable connected or disconnected
Host-based CD-ROM or ISO image used as CD-ROM
Up to three hard disks with dynamically expanding of fixed-size images
System snapshots (have you ever wished: if I only had a chance to save the current state and return back if something fails?)
Configurable memory size (of course, this is ordinary but still nice to have)
And one of the most important features ... Wizard-like clickable user interface :) ;)

It has recently helped me a lot with testing the openSUSE 11.0 installation (iSCSI-based systems, bootloader issues, automatic configuration, deploying installation images, ... and finally users configuration in second stage). I also tried some other distributions without any need to reinstall any of my PCs.

Where to get VirtualBox?
There is a Community Repositories YaST module in openSUSE 10.3 where you can select VirtualBox repository to be added to your system repositories (or via YaST Repositories, Add, Community Repositories since openSUSE 11.0) add a FACTORY repository. After that you will need to install at least these packages: virtualbox-ose-kmp-* (* = default at my workstation, depends on the installed kernel) and virtualbox-ose. Then run /usr/bin/VirtualBox, configure new system and see additional instructions (For details, check the VirtualBox Installation in Links).

Links

Function Keys in YaST ncurses Frontend

2008-05-21T18:05:00.008+02:00

As you already know, YaST can run in three different front-ends: Qt, GTK, and ncurses. Textual ncurses front-end is widely used in the server area, for remote configuration and also as a fall-back if graphical front-end fails.

There are many new shiny ;) features in openSUSE 11.0. One of them, implemented by Katarina Machalkova AKA Bubli is displaying function keys assigned to dialog buttons on a YaST ncurses status line.

See the YaST ncurses package selector:

Available function keys: F1 = Help, F9 = Cancel, F10 = Accept.

This feature can even fix some dialog-layout issues, for instance if buttons are not visible when a dialogs content doesn't fit the available screen space.

Available function keys: F1 = Help, F8 = Back, F9 = Abort, F10 = Finish.

Even though this dialog exceeds the window size, you can still use function keys for invisible buttons. In this example, pressing the F10 key would write the configuration. I'm sure you will find this feature useful :)

openSUSE 11.0 Beta3 Installation on 128 MB RAM

2008-05-16T16:28:00.005+02:00

I've just managed to install Beta3 in VirtualBox with 128 MB RAM in GUI!

Well, Linuxrc complained about low-memory system and wanted me to create a swap partition or swap file which I failed to do as pressing the create swap partition/file menu entry did not bring any more dialogs to set it (a bug probably - of course, if you already have a swap partition, Linuxrc will offer you to use it).

Anyway, there is a workaround:

When the installation media is booted, do not select Installation but Rescue System.
Login as root when it asks for Rescue Login
Run hwinfo --disk to get the current disk/device name (my was /dev/sda)
Create new swap partition:
fdisk /dev/sda (most of the systems will have sda but your might be different)
h (to get help for the fdisk command)
n (to create a new partition)
p (for primary partition)
1 (first primary partition)
1 (first cylinder is 1)
+128M (to create a 128 MB partition, it worked for me with 94MB as well)
w (to write the partition table to disk)
Format swap partition with mkswap /dev/sda1
Call reboot to reboot to the installation menu again
When the installation media is booted again, append addswap=/dev/sda1 (your just-created swap partition) to the command-line options and run the Installation
There are no special steps you have to do any further but I'd recommend you to select some low-weight desktop such as Xfce on such system.

Even though installation doesn't work without adding the swap, it can be installed on low-memory systems quite easily.

Have a lot of fun!

Image-based Installation

2008-04-22T21:11:00.007+02:00

About

As it has been already published by Coolo, we've added a new feature Installation from Images to openSUSE 11.0 Beta1. After today's discussion on openSUSE-FACTORY mailing-list I've decided to write a short blog to make it clear.

Reasons for Image-based Installation

We've found out that the Live-CD installation is a way faster than the common installation using RPMs. There are several reasons for that. Let me list some of them:

Libzypp installs RPM packages one by one which in turn opens, writes and closes the RPM database for every single package. This adds a huge overload.
Libzypp also doesn't support downloading and installing packages in multiple queues. That's why installation of package blocks downloading of another one and vice versa.
Depending on how the image has been created, copying might produce less disk-seeking as extracting an archive is a linear operation.

How Does It All Work

Short story: After installation proposal is accepted by a user, YaST checks which patterns have been selected for installation and tries to find a best-matching set of images. If it succeeds, images are extracted one by one to the system. After that, packages that were not part of those images are installed by the normal way - from RPMs.

Currently in a default KDE4 installation images contain roughly 1.5 GB and about another 1 GB is installed from RPMs. This works for new installation only, update process is still RPM-based.

What Do Images Contain

We generate several installation images that can be combined with some other ones into image-sets. Every image set defines list of patterns that must be selected in the software proposal in installation overview. Image-sets also define architectures for which they are useful. See small example of configuration file:

<image_set>
  <patterns>enhanced_base,kde4,multimedia,sw_management,x11</patterns>
  <archs>i386</archs>
  <image>
      <name>KDE [base]</name>
      <type>tar</type>
      <file>common-base-i386.tar.lzma</file>
  </image>
  <image>
      <name>KDE</name>
      <type>tar</type>
      <file>kde-i386.tar.lzma</file>
  </image>
  ...
</image_set>

In this example image common-base-i386.tar.lzma contains the base system image which can be shared among other image-sets. Image kde-i386.tar.lzma is specific for KDE pattern. Images don't exactly have to match one or more patterns. Every image set has one special image with package-management metadata.

More Detailed Information on Images

Images are currently compressed with LZMA algorithm as the decompression is often faster than if bzip2 was used.
Images might be downloaded before they are extracted to the system. It depends on the installation media type: HTTP and FTP-based have to be downloaded, NFS/CD/DVD/Samba/... support direct access to files and thus they don't need to be downloaded that makes it faster and the memory consumption is lower.
Images are downloaded to a temporary directory on your hard-disk. This makes it possible to use that feature on low-memory systems too.
Installation DVDs contain these images as well as all RPM packages in them. See /images/ directory in the root of the media.
Since Beta1+ you can control whether images will be used or turn the feature completely off. A new option has been added to the installation overview. See also bug 381234.

Some Numbers

I hope I'll add them soon :)))

Automatic Configuration in openSUSE 11.0

2008-04-12T12:48:00.005+02:00

There and Back Again

My previous blog about Getting Rid of Second Stage Installation was mostly about moving all the system-configuration to the first stage installation using a separate YaST process. You can find an almost-working version ;) in openSUSE 11.0 Alpha3. Despite the fact we've succeeded to implement it, testing the Alpha has revealed some possible issues:

Higher memory consumptions (Yet another YaST process /YaYP/)
No user-feedback at all (possible with inter-process communication, but a bit tricky)
Exceptions handling (missing packages, error recovery, ...)
Almost impossible to debug errors in called configuration clients as they were invisible

Less Clicking, Less Waiting

After reconsidering all the pros and cons, we've decided to move the automatic configuration to a non-interactive second stage. What did it bring comparing to the previous solution:

Faster configuration (only one YaST process)
User-feedback with progress
Configuration modules can deal with exceptions and let user decide (if really needed)
Possibility to rerun the configuration if it fails.

If you don't want this automatic configuration to proceed we still support the old way - Click&Wait^TM configuration - you just have to chose you want to do so in an Installation Method dialog.

I Want to See That!

And where can you try it? In openSUSE 11.0 Alpha3+ (internal snapshot, sorry) and later - hopefully we'll have a public Beta1 soon. If you don't want to wait and want to see that now, try installation from FACTORY.

Getting Rid of 2nd Stage of Installation

2008-03-07T16:02:00.008+01:00

Intro

As you probably already know, Stano has published in his blog that we would like to get rid of the configuration phase of the openSUSE installation process. The idea was to simplify the installation as possible and make the installation process faster.

The current (openSUSE 11.0) installation uses two stages:

First stage with the installation settings, e.g., system language, keyboard, timezone, partitioning, software selection...
Second stage (after you reboot to the just installed system) where you can configure the installed system, e.g., root password, network setup, system users, X11 configuration, printers, sound and TV cards...

Our users keep complaining why should they configure how the system will be installed (even with several system settings), hit the Install button and then wait tens of minutes (or sometimes hours with slower installation repository/network) until it is installed. After that, YaST starts again and it again takes quite a long time after the system is configured and usable.

What seems to take most of the time if downloading and applying the security and recommended updates. Of course, there might be some security issues if we remove the Apply Updates dialog from the second stage. We are well aware of that and we are still looking for the best solution.

Plan of the Battle

We have done some research about the second stage and the output was:

Everything that can be configured automatically, move to the end of the first stage without possibility to change the automatically proposed values (everything can be changed on a running system if needed).
Move tasks, that can't be done automatically, to the first stage configuration dialog or drop if possible.
Offer the possibility to enable the second stage on request. A reasonable place is the Installation Mode dialog.

The Preview

Last week I've created a simple script partly similar to AutoYaST architecture. It uses the current functionality and configuration scripts by calling them first with "MakeProposal" and then "Write" commands. This keeps everything backward compatible and we could use these configuration scripts in re-enabled second stage (on user's request).

Of course, there were some issues to solve:

We are constantly making the installation system smaller, these configuration scripts (and their dependencies) can't be part of it. We have to call them directly on the just installed system.
YaST doesn't support calling scripts and loading libraries from another systems (chroots) thus we had to start another chroot-ed YaST process (y2base).
Another YaST process needs to run in background without any user interface not to break ncurses (text-mode installation).
If YaST runs without UI, some scripts/modules might identify it as they were called in testsuite (special YaST mode for testing). That's why all scripts are called with parameter "AutomaticConfiguration":true.
Some services want to re/start in that chroot-ed environment which could make the system unstable or temporarily unavailable, e.g., if the installation-system is on NFS and YaST tries to restart the network. That's why all scripts are called also with parameter "WriteOnly":true.
YaST has to take care about saving and closing all libzypp-relations before starting another process that would try to acquire the libzypp lock.
The root password has to be filed in the first stage as well as we have to create the first user there otherwise we would have to run the second stage installation (to call these two steps).

Because of adding some new parameters (AutomaticConfiguration, WriteOnly) some configuration scripts will have to be adapted but it should be very easy.

These services were automatically configured by the script:

Network-related modules: lan, general, dsl, isdn, modem, remote (administration), firewall
Hardware modules: x11, printer, sound, tv

Some additional helper (e.g., SuSEconfig) scripts had to be called too to make the system usable. Users can be written too.

Test Result

This test was really worth trying because it reveled some YaST pros and cons that we can use later. After a successful installation without second stage I'm not afraid to say that we can really get rid of the second stage very soon.

Links

opensuse-factory mailing list (discussing this theme)