From version yast2-network-2.17.14 YaST has support for creating tunnels. This is good for virtual networking, VPN and virtualization.
But theory you can read on many places (including wikipedia), so here is practical example of configuration:

My previous "usual" configuration

urchin:/home/mzugec/svn/trunk/network # ip a
1: lo: <loopback,up,lower_up> mtu 16436 qdisc noqueue
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
   inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo
2: eth0: <broadcast,multicast,promisc,up,lower_up> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:11:d8:39:4e:d0 brd ff:ff:ff:ff:ff:ff
   inet 10.20.1.28/21 brd 10.20.7.255 scope global eth0
3: eth1: <broadcast,multicast> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:11:d8:39:5c:e4 brd ff:ff:ff:ff:ff:ff

In YaST, remove configuration from eth0 (because this configuration belongs to bridge - see later)


Create new TAP device, click Next


Leave default "Persistent Tunnel" and set owner and/or group to access this device from user account



Configuration overview


Create new network interface type bridge


Put eth0 and tap0 into bridge and configure bridge with DHCP (as eth0 before)


Configuration overview

urchin:/home/mzugec/svn/trunk/network/src # ip a
1: lo: <loopback,up,lower_up> mtu 16436 qdisc noqueue
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
   inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo
2: eth0: <broadcast,multicast,promisc,up,lower_up> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:11:d8:39:4e:d0 brd ff:ff:ff:ff:ff:ff
3: eth1: <broadcast,multicast> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:11:d8:39:5c:e4 brd ff:ff:ff:ff:ff:ff
24: tap0: <broadcast,multicast,up,lower_up> mtu 1500 qdisc pfifo_fast qlen 500
   link/ether 00:ff:1c:00:23:8b brd ff:ff:ff:ff:ff:ff
25: br0: <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue
   link/ether 00:11:d8:39:4e:d0 brd ff:ff:ff:ff:ff:ff
   inet 10.20.1.28/21 brd 10.20.7.255 scope global br0

urchin:/home/mzugec/svn/trunk/network/src # brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0011d8394ed0       no              eth0
                                                        tap0

Using TAP device with VirtualBox.

Virtualized machine through tunnel connected into bridge is accessible from outside network!

I have been reading since openSUSE 11.0 GM release a lot of comments posted in many forums and blogs about the "lake" of KDE3 CDs. This big noise around got my attention specially because I was one of the KDE users that shared people's preferences of using a very stable KDE version - KDE 3.5 - for daily use instead of the bleeding edge KDE 4.0.

The process of installing KDE3 on openSUSE no matter what desktop environment users were using was quite simple to follow:

# zypper install -t pattern kde3

or if you just want a clean KDE 3 base:

# zypper install --no-recommends -t pattern kde3

or even by selecting "KDE3 Base System" pattern on YaST. Easy, isn't it?

Well, for those lazy people who don't want to install openSUSE with KDE4, GNOME, XFCE or any other and then install KDE3 I have a gorgeous news: openSUSE 11.0 KDE3 Live CDs are now available!

• openSUSE 11.0 KDE3 LiveCD (i686)


• openSUSE 11.0 KDE3 LiveCD (x86_64)


• MD5SUM and SHA1UM


• Kiwi config (32bit) and Kiwi config (64bit)

These Live CDs are also installable CDs and were creating using the openSUSE KIWI Image System. They contain the latest official updates as also the latest packages from KDE:KDE3, KDE:Backports, KDE:KDE4:Factory:Desktop, and KDE:KDE4:Factory:Extra-Apps repositories as of this time of writing.

Big thanks to the KDE Team and Kiwi Team that supported me since the beginning encouraging and helping me in this adventure ;-)


Note: these ISOs are not officially supported by openSUSE nor Novell. If you want to report any bug found use Novell's Bugzilla for better tracking. Feedback or for any other purpose please contact me via email (cgoncalves [at] opensuse [dot] org).

Replying to "OpenSuse adopta estratégia da Canonical para promover o projecto" (aka "openSUSE adopts Canonical's strategy to promote the project") posted by Bruno Miguel:

The openSUSE project does this for quite long, even maybe before Ubuntu exists.
The news here is that now we have a specific page to users request them easily instead of emailing.

Just to clarify to avoid wrong conclusions about openSUSE/Novell... :-)

I arrived in Mexico City, to live, four years ago to the day. These four years have been a lot better than the preceding four were, and, the occasional grumble notwithstanding, I would be lying if I said that this place hasn't treated me pretty well overall.

Everybody probably knows YaST. You should use it, at least for installation. And what about AutoYaST? AutoYaST is a great tool for automatic installation and configuration. I did some work regarding automatic installation & network setup during installation. Documented here
I did 4 tests:

1 - When installation starts, udev will create configuration file for persistent naming (based on MAC address). At the end of 1st stage (before first reboot) YaST will copy this file into installed system, so after reboot all network devices will have same device names.

2 - Same as 1, but during AutoYaST installation. That means when no rule in AutoYaST profile about this file, keep it, not replace by empty file.

3 - Use AutoYaST profile. When there is defined some rule about this file, use it and replace the original one. This example from networking section creates corresponded udev rule to keep eth0 name for interface with 08:00:27:07:a2:2d MAC address (and replaces udev rule file from 1):

part of AY.xml

<networking>
...
 <net-udev type=list>
  <rule>
   <rule>ATTR{address}</rule>
   <value>08:00:27:07:a2:2d</value>
   <name>eth0</name>
  </rule>
 </net-udev>
...
</networking>

/etc/udev/rules.d/70-persistent-net.rules file as a result:

# Generated by autoyast
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:07:a2:2d", NAME="eth0"

4 - Migration from SLES10-style syntax. When you use your old profile (from <=SLES10x), it's something like:

<networking>
...
 <interfaces config:type=list>
   <interface>
     <bootproto>dhcp</bootproto>
     <device>eth-id-08:00:27:07:a2:2d</device>
     <name>79c970 [PCnet32 LANCE]</name>
     <startmode>auto</startmode>
     <usercontrol>no</usercontrol>
   </interface>
 </interfaces>
...
</networking>

YaST will convert device name eth-id-08:00:27:07:a2:2d into rule for udev:

# Generated by autoyast
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:07:a2:2d", NAME="eth0"

and rename configuration name into eth0

And that's all for now ...
... have a lot of fun
Bye,
Michal

$ reboot
-bash: reboot: command not found
$ /sbin/reboot
reboot: must be superuser.

In KDE / GNOME, you can just click reboot in the menu and your session sends a message to display manager, which runs as root and does the dirty job of rebooting or shutting down your machine. Unfortunately, things are not that easy if you are using a simpler window manager or want to shutdown from a script. Sure, there is sudo, but that has to be configured first to work without password. Luckily, after a couple of hours of googling (only to find helpful advice as “this can be done easily with ConsoleKit or hal”), reading documentation of dbus, {Console,Policy}Kit and hal and clicking in qdbusviewer, I finally found a way with hal+dbus:

$ dbus-send --system --dest=org.freedesktop.Hal \
  --type=method_call --print-reply \
  /org/freedesktop/Hal/devices/computer \
  org.freedesktop.Hal.Device.SystemPowerManagement.Reboot

To shutdown, just replace Reboot with Shutdown. I’m going to add this to the default icewm configuration, so that the logout menu finally works.

During the last years of university I spent some time wondering about my future job. After the degree I received  lot of offers (fortunately also good ones), but none of them matched with my “dream job” . There was always something missing/different. I was just trying to convince myself that the “perfect job” can exist only in our dreams when my feed reader pointed me here.

After reading these lines:

” We are exploring new technologies, creating prototypes of future systems, and trying to find and shape some of the features that will be part of upcoming SUSE products and the ecosystem around that. It’s a fascinating job, challenging, fun, and always exciting. For somebody like me who loves to create new things and enjoys working with an awesome team of innovative people this is a dream job.”

I realized the description matched with all my wishes!

I immediately applied for the position and now, after more than a month, I’m looking at a signed proposal.

I’ve waited a long time before spreading my joy to the rest of the world… but now I just want to say that starting from 1st August I’ll be part of Suse’s Incubation team! :D

I’m really happy, excited and honoured for this awesome opportunity.

I wish you’ll be able to realize your dreams too!
Just a funny note… While Cornelius was writing about the job offer on his blog, I was having a dinner with another Novell employee: Massimiliano Mantione. I was listening to his personal story, wishing to find a dream job like his one. I have to admit I was a bit jealous :)

openSUSE is great for the desktop, great for the server, and now it’s ready to take on appliances — and we don’t mean toasters and blenders. No, we’re talking about software appliances — virtual machine images that come pre-configured with the application you want to use, without any of the hassle normally associated with installing an application.

If you’re interested in building a virtual appliance, or have another use for a minimal operating system, read on to learn about openSUSE LimeJeOS.

What is LimeJeOS?

LimeJeOS is the openSUSE version of JeOS. The term JeOS (“Just enough Operating System”) refers to a customized operating system that precisely fits the needs of a particular application. LimeJeOS includes only the pieces of an operating system required to support a particular application and any other third-party components contained in the appliance. This makes the appliance smaller, more efficient, more secure, and offers better performance than an application running under a full, general-purpose operating system.

As the name suggests, “LimeJeOS” itself is not an appliance or an operating system; it is just the base for various possible appliances. LimeJeOS contains just the very basic parts of an operating system. The major goal is to make the system as small as possible while providing the possibility to install additional software. A LimeJeOS system itself is not very useful without additional packages. Besides an editor (a stripped version of vi) it just contains a package manager that allows the actual applications to be installed. Of course all the usual repositories can be used for that purpose; just with a regular, full-size Linux distribution.

What is the difference between SLE JeOS and LimeJeOS?

SUSE Linux Enterprise JeOS relates to LimeJeOS just like openSUSE relates to SLES. In fact, SLE JeOS is built from the latest version of SLES while LimeJeOS is built from the latest version of openSUSE. While LimeJeOS provides the latest state of the openSUSE distribution, SLE JeOS will offer all the services and support that is also available for SLES.

Which one should you use? If you’re working on a virtual appliance for a project that won’t require commercial support, and you want to track the latest in open source, openSUSE is the version for you.

If you’re working on a project that’s likely to need support, then you probably want to go with SUSE Linux Enterprise JeOS.

Where can I get LimeJeOS?

LimeJeOS is built using kiwi. The configuration files are managed via Subversion and are available at: https://forgesvn1.novell.com/svn/opensuse/trunk/distribution/images/LimeJeOS/

In the future we plan to create a regular package (RPM) and add it to the openSUSE build service, so that the latest version is always created automatically with the latest software versions in openSuSE.

How to build LimeJeOS?

Check out the current version of LimeJeOS using the following commands:

svn co https://forgesvn1.novell.com/svn/opensuse/trunk/distribution/images/LimeJeOS

Make sure you have the needed kiwi packages installed. You will need at least: kiwi, kiwi-tools and kiwi-desc-vmxboot and/or kiwi-desc-xenboot from http://download.opensuse.org/repositories/openSUSE:/Tools/. When those conditions are met, building the openJeOS images is accomplished by just running the “./build.sh” script from the LimeJeOS repository.

./build.sh

Please note that the build process will need at least twice as much diskspace as the final images, so you’ll need around 2 GB of free disk space at this time to build Lime JeOS.

After you have booted the virtual system, log in as user “root” with password “linux”.

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

• a wrapper class for accessing different configuration files (currently only ini files)
• an automatic wizard sequencer equivalent (using the advantages of an object oriented language, btw YCP is not)
• three clear and intuitive dialogs, every user should understand

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

• YaST modules evolved into the object oriented world and can make use of it (the automatic sequencer is the first benefit)
• the code is reusable
• a huge bunch of documentation and lots of tools exist for C++
• its a compiled language and has a better performance than an interpreted one
• we can bind automatically to the most important scripting languages and give them access to the modules logic

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.