Today I spent the best part of the morning to configure a SLES 10 SP2 server as a simple router. I googled quite a lot and could not find a nice and concise post on how to configure SLES 10 as a simple router, so I thought I’ll write up my experiences in the hopes that it will help someone. Although this was done on SLES 10 I am pretty sure it will apply to openSUSE as well.

My setup is as follows: Local lan is 192.168.0.0/24 and I want a private lan on 192.168.1.0/24 so that I can run stuff like DHCP and PXE without upsetting everyone on the network. I have a SLES 10 server with 2 network cards: eth1 connected to the local lan and eth0 connected to my private switch. The local lan is connected via ADSL to the Internet and I need my private network to also be able to connect to the Internet.

The first thing did was to configure the ADSL router to send all traffic for my private network to the ip of the SLES 10 server on the local lan. In the case of our ADSL router it involved adding a custom route.

Next I started YasT on the SLES 10 server and under “Network Devices”, Network Card”, I selected “Edit” on one of the network cards and selected “Routing” and then enabled “IP forwarding”.

Then I edited the firewall settings and assigned the network card connected to the local lan to the external zone and the network card connected to the private network to the internal zone.

I did not enable masquerading as I wanted to be able to connect to machines on my private network from the local lan.

I then configured DHCP and DNS on the SLES 10 server and connected a machine to my private network and it was able to lease an IP address and resolve DNS queries. It did not however allow me to connect to anything outside the private lan.

After much googling and trying all sorts of iptables commands, I finally found a post that mentioned something about editing /etc/sysconfig/SuSEfirewall2. This can also be done via Yast, “System”, “etc/Sysconfig Editor”, which is the way I did it.

I had to change the following settings in Network → Firewall → SuSEfirewall2 :

FW_DEV_EXT: ensure that it contains the device of the external interface (eth1 on the local lan in my case)

FW_DEV_INT: ensure that it contains the device of the internal interface (eth0 on the private lan in my case)

FW_ROUTE: yes

FW_MASQUERADE: no

FW_FORWARD: This was the magic line for me. This needs to contain a space separated list of what you will allow. In my case I just put 192.168.0.0/24,192.168.1.0/24 192.168.1.0/24,192.168.0.0/24 192.168.0.1/24,0/0. This allows all traffic between the local lan and the private lan and allows the private lan to connect to the Internet.

The comments and help in YasT is comprehensive and made it quite easy to understand the meaning of each of the fields.

I had to restart the firewall after I made the changes.

I hope someone finds this useful.

1. The distro_target attribute should be turned into some standard distribution identifier to make it really useful. The CPE looks like a good candidate.
2. The spec does not say how to handle repositories of type unknown to the client. They should be ignored, but the type attribute of <repo> is currently optional so the type does not need to be known when refreshing the service. One solution could be to make the type attribute required, another could be to require that the client removes any repositories comming from a service that are of unknown type. The latter seems to be cumbersome, i would go for the former.
   
3. It might be worth to add the examples from this Duncan's post to the page (they're much better than those of mine :O).
4. The specification should not be kept solely as a wiki (should not be editable by broad public; version control is problematic, etc.). Any suggestion where it should be instead?

I am using LaTeX and beamer class to make presentations and posters. A short introduction to start with latex is available. Sometimes I am using LaTeX just to produce eps/pdf text boxes and after that Scribus for poster layout. In the last development version of Scribus, which is 1.3.5svn, there is possible to use latex source/expressions directly in document, so is not necessary anymore the aditional step to create eps/pdf text boxes.

For OpenSUSE there is the last version here:

http://software.opensuse.org/ymp/home:mrdocs/openSUSE_11.0/scribus.ymp

but I don't want to replace 1.3.3.12 stable version, so I will install the latest development version in my home directory

Warning: The documents saved in 1.3.5 will not be back compatible with the other versions, more here: http://scribus.info/svn/Scribus/trunk/Scribus/README

Let's install the last development of Scribus (it is very stable for what I need, I didn't have any problems with it):

$ mkdir ~/aplic/scribus_135
$ mkdir ~/tempsrc
$ cd ~/tempsrc
$ svn co svn://scribus.info/Scribus/trunk/Scribus
$ cd Scribus
$ cmake -DCMAKE_INSTALL_PREFIX:PATH=~/aplic/scribus_135

I obtained an error during the compilation because I didn't have "libqt4-devel" so:

$ zypper install libqt4-devel


:::bash
$ make
$ make install
$ ~/aplic/scribus_135/bin/scribus

Here are two screenshots, the main window and scribus latex editor:

That's all.

References:

• http://wiki.scribus.net/index.php/Building_SVN_versions_with_CMake
• http://scribus.info/svn/Scribus/trunk/Scribus/README
• http://wiki.scribus.net/index.php/Working_with_latex_frames
• http://wiki.scribus.net/index.php/Embedding_other_external_tools_into_a_TeX_frame

After this blog has been dead for about two years, I will start with some technical stuff – at least when computers don’t work as expected, most times I know how to fix it.

Ok, lets move on to the topic of this post. Short time ago I was forced to do some stuff on windows again (EEKK — the word registration number still sends me cold shivers …). As I needed really working USB support (unfortunately Nokia thinks Linux is good enough for their hardware, but not for their customers computers), and I was unable to make it work neither in Xen (not at all) nor with KVM (unusably slow), I ended up with VMWare.

So, USB worked really nice, no problems at all. While I was there, I thought „let’s have a look at the 3D acceleration“. At a first glance, it looked quite easy – „upgraded“ the VMs version to 6.5, and ticked the option for „3D acceleration“ – TADA – „Failed to construct 3-D rendering backend. The 3-D features of the display card will be disabled.“

Ok, what’s wrong? After some digging in the log, I found these two suspicious lines:
mks| GLUtil_InstallExtensionLists: Missing required extension GL_EXT_texture_compression_s3tc
mks| GLUtil_InstallExtensionLists: Missing required extension GL_EXT_framebuffer_object
Unfortunately, the Intel driver does not support these two OpenGL extensions – more or less.

Let’s have a deeper look into this. First, S3 texture compression. S3TC is a lossy texture compression used in many games, and it is mandatory for DirectX. Unfortunately, S3TC is covered by some patents, and although the decompression is handled by the hardware, a conformant OpenGL driver has to handle decompression and compression. As in many cases (most games ship with precompressed textures) only decompression is needed, which is handled by the hardware, there is a switch to force Mesa to report support of S3TC although it actually only handles one half – if you want to know more, force_s3tc_enable drirc are the keywords.

If you want to know more, or even want to enable compression as well, have a look at Roland Scheideggers‘ page.
As said, S3TC is covered by patents, so enabling compression is legally problematic. But there may be some hope, as S3TC is „owned“ by VIA, and they recently open sourced their Linux graphics driver, maybe we will even get S3TC out of that – at least, they could put compression under a liberal license, and still sell licenses to ATI/Nvidia/Intel (I still may have some dreams, don’t I?)

The other part is GL_EXT_framebuffer_object, shortly referred to as FBOs. These are really not supported by the Intel driver at the moment, but there the new memory managers come to the rescue, see this post.

Summarized, as soon as GEM has landed in the kernel tree (and/or in the downstream distributions), it should be possible to make it work. GEM should be available soon, and S3TC can be worked around today.

Today i received the confirmation that openSUSE will have a devroom @ FOSDEM 2009!

Yay! Because it’s a little bit earlier next year (2008-02-07/08), we should
start right now with the the planing.

Please head over to the opensuse-project list and read/comment this posting.

After several requests to get GNOME 2.24 built and made available the GNOME Team (well Magnus Boman really), took on the challenge of making it so.  Unfortunately we were a bit focused on the 11.1 release and didn’t actually think about doing any backports.  This has kind of bitten us squarely on the behind, yes we must bow to the KDE Team‘s backporting powers – make the most of it chaps

Unfortunately there are too many dependencies for the backport, and will involve a heck of a lot of maintenece – more so than normal.  After several attempts to coax things to work we must bow our heads in admission to being beaten This doesn’t mean that we won’t be doing any backports in the future, the championship isn’t over just this match.  It does mean that there wont be a GNOME 2.24 for openSUSE 11.0 however, sorry to disappoint.

We have learnt our lesson and with the aim of not disapointing you again we have already instigated measures to ensure that your backporting needs are met.  We are already starting to build GNOME 2.25 against the current Factory and will continue to ensure that each release has the latest and greatest from the Enchanted Wood.  There may well be occaisons where things just won’t work, but we will do our utmost to minimise them and give you plenty of notice.

One thing we do need is your help.  Funny I always seem to be asking for help, but this time there is a really good reason (actually more than one ).  We need more people to run Factory to test things and ensure that bugs and issues/comments are reported back.  This doesn’t just apply to GNOME but openSUSE in general, please please test our latest releases and give us your feedback.  There are several ways you can do this – Bugzilla, IRC and Mailing Lists, oh and at events like the upcoming FOSDEM.