Hello, I'm desperately trying to set up a secure file sharing server. It should support both user authentification and data encryption. It will run in a non-secure LAN and provide about 15 users with their home directories. My first idea was to use NFS over SSH. However, for this you need to specify the ports rpc / nfs /nfslock use. It seems that in SuSE there is no way of specifying the nfslock port, is this correct? What am I doing wrong? How to do NFS over SSH in SuSE? Samba would also be a possibility, however there are a couple of problems with that one: 1) problem with high UID's, we have UIDs >> 65535 and the mounted samba shares do not get proper permissions 2) is it true that Samba does not support special files (like sockets), thus rendering this file system unusable for the purpose of mounting home directories to use e.g. with KDE (which needs to create sockets)? Am I wrong? What other possibilities are there? Best regards, January Weiner -- ------------ January Weiner 3 ---------------------+--------------- Division of Bioinformatics, University of Muenster | Schloßplatz 4 (+49)(251)8321634 | D48149 Münster http://www.uni-muenster.de/Biologie.Botanik/ebb/ | Germany
Hi,
I'm desperately trying to set up a secure file sharing server. It should support both user authentification and data encryption. It will run in a non-secure LAN and provide about 15 users with their home directories.
depending on your needs you could either use openafs (supports encryption) http://www.openafs.org/ but thats maybe too much for the setting you want. If you only got around 5 users that want to mount their homes ( -> the "client" machines run linux), you maybe want to give shfs a try: http://shfs.sourceforge.net/ Bascically you can mount server directories on your clients, using ssh. This only works, if your "client computers" run linux, because it has a kernel module that allows transparent mounting. Works like a charm for me... peace, Tom
depending on your needs you could either use openafs (supports encryption)
but thats maybe too much for the setting you want.
Yeah, this could be an overkill. Afs is much more than what I want and setting up could be a little tricky if you lack afs knowledge like I do.
If you only got around 5 users that want to mount their homes ( -> the "client" machines run linux), you maybe want to give shfs a try:
Bascically you can mount server directories on your clients, using ssh. This only works, if your "client computers" run linux, because it has a kernel module that allows transparent mounting. Works like a charm for me...
Hm, I've seen that one, but I was not really sure whether the code is mature enough. I have tried it now, basically I'm enthusiastic, we will probably give it a try. It was really a treat to install and configure, I'm enthusiastic. regards, January
You could also give openvpn a try. It ships with SuSE's distros and is very
quick and easy to setup. It is based on openssl. Then you can do NFS
transparently.
Ferdinand
--On Wednesday, June 02, 2004 05:32:22 PM +0200 January Weiner
depending on your needs you could either use openafs (supports encryption)
but thats maybe too much for the setting you want.
Yeah, this could be an overkill. Afs is much more than what I want and setting up could be a little tricky if you lack afs knowledge like I do.
If you only got around 5 users that want to mount their homes ( -> the "client" machines run linux), you maybe want to give shfs a try:
Bascically you can mount server directories on your clients, using ssh. This only works, if your "client computers" run linux, because it has a kernel module that allows transparent mounting. Works like a charm for me...
Hm, I've seen that one, but I was not really sure whether the code is mature enough. I have tried it now, basically I'm enthusiastic, we will probably give it a try. It was really a treat to install and configure, I'm enthusiastic.
regards,
January
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
-- Ferdinand Schmid Architectural Energy Corporation Celebrating over 20 Years of Improving Building Energy Performance http://www.archenergy.com
Hi On Wednesday 02 June 2004 21:08, Ferdinand Schmid wrote:
You could also give openvpn a try. It ships with SuSE's distros and is very quick and easy to setup. It is based on openssl. Then you can do NFS transparently.
insert your favorite vpn here> * tinc uses udp with a tcp control channel. So you don't stack 2 tcp layers. http://www.tinc-vpn.org/ BB, Arjen
Hi, I had the same problem and resolve it using nis and nfs. I am using data encryption - ipsec (freeswan) - for the communication between clients and server. Maybe it is a possible way for you too. Best regards, Ralf Farke, ps: I had just seen, you are a member of WWU like me. So, if you need more information, just call me. Ralf Farke Westf. Wilhelms-Universität Münster Institut für Wirtschaftsinformatik Leonardo-Campus 3 Am Mi, 2004-06-02 um 16.29 schrieb January Weiner:
Hello,
I'm desperately trying to set up a secure file sharing server. It should support both user authentification and data encryption. It will run in a non-secure LAN and provide about 15 users with their home directories.
My first idea was to use NFS over SSH. However, for this you need to specify the ports rpc / nfs /nfslock use. It seems that in SuSE there is no way of specifying the nfslock port, is this correct? What am I doing wrong? How to do NFS over SSH in SuSE?
Samba would also be a possibility, however there are a couple of problems with that one:
1) problem with high UID's, we have UIDs >> 65535 and the mounted samba shares do not get proper permissions
2) is it true that Samba does not support special files (like sockets), thus rendering this file system unusable for the purpose of mounting home directories to use e.g. with KDE (which needs to create sockets)?
Am I wrong? What other possibilities are there?
Best regards,
January Weiner
-- ------------ January Weiner 3 ---------------------+--------------- Division of Bioinformatics, University of Muenster | Schloßplatz 4 (+49)(251)8321634 | D48149 Münster http://www.uni-muenster.de/Biologie.Botanik/ebb/ | Germany --
On Wed, 2 Jun 2004, January Weiner wrote:
I'm desperately trying to set up a secure file sharing server. It should support both user authentification and data encryption. It will run in a non-secure LAN and provide about 15 users with their home directories.
My first idea was to use NFS over SSH. However, for this you need to specify the ports rpc / nfs /nfslock use. It seems that in SuSE there is no way of specifying the nfslock port, is this correct? What am I doing wrong? How to do NFS over SSH in SuSE?
Samba would also be a possibility, however there are a couple of problems with that one:
1) problem with high UID's, we have UIDs >> 65535 and the mounted samba shares do not get proper permissions
Haven't been a problem for a couple of years, as far as I can gather, definitely shouldn't be for Samba 3. Changed rather shortly after kernel 2.4 appeared supporting UiDs > 65535. Haven't tested this myself, just did a quick google just now. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=59407
2) is it true that Samba does not support special files (like sockets), thus rendering this file system unusable for the purpose of mounting home directories to use e.g. with KDE (which needs to create sockets)?
Not true. 'Unix extension = yes' in smb.conf solves this, the problem with KDE is that it has odd (':' in particular) characters in filenames, this is solved by also setting 'mangled names = no'. Gnome, on the other hand, uses a file locking strategy which is broken with sambamount. Setting an environment variable GCONF_LOCAL_LOCKS=1 for the user moves the file locking to /tmp and makes Gnome useable, though the solution isn't optimal.
Am I wrong? What other possibilities are there?
Someone suggested VPN, which can force the user to authenticate to get an IP address - at which point IP security all of a sudden deserves to contain the word "security" in it. Bjørn -- Bjørn Tore Sund Phone: (+47) 555-84894 Stupidity is like a System administrator Fax: (+47) 555-89672 fractal; universal and Math. Department Mobile: (+47) 918 68075 infinitely repetitive. University of Bergen VIP: 81724 Support: system@mi.uib.no Contact: teknisk@mi.uib.no Direct: bjornts@mi.uib.no
Hello,
1) problem with high UID's, we have UIDs >> 65535 and the mounted samba shares do not get proper permissions
Haven't been a problem for a couple of years, as far as I can gather, definitely shouldn't be for Samba 3. Changed rather shortly after kernel 2.4 appeared supporting UiDs > 65535. Haven't tested this myself, just did a quick google just now.
Well. Take a look at https://bugzilla.samba.org/show_bug.cgi?id=1234 . If I understand it correctly, there are still many programs which use __kernel_uid_t instead of uid_t or __kernel_uid32_t. I agree -- it should not be a problem. But it is.
2) is it true that Samba does not support special files (like sockets), thus rendering this file system unusable for the purpose of mounting home directories to use e.g. with KDE (which needs to create sockets)?
Not true. 'Unix extension = yes' in smb.conf solves this, the problem with KDE is that it has odd (':' in particular) characters in filenames, this is solved by also setting 'mangled names = no'. Gnome, on the other hand, uses a file locking strategy which is broken with sambamount. Setting an environment variable GCONF_LOCAL_LOCKS=1 for the user moves the file locking to /tmp and makes Gnome useable, though the solution isn't optimal.
Thanks! That are good news for us. And what about directories exported from Windows?
Am I wrong? What other possibilities are there?
Someone suggested VPN, which can force the user to authenticate to get an IP address - at which point IP security all of a sudden deserves to contain the word "security" in it.
:-) OTOH -- as far as I understand, VPN encrypts the whole private network traffic, which may or may not be a problem in terms of performance. I have played now with shfs for a couple of days. Well, the code is maybe not very mature (I had to correct the high UID issue here as well), and the performance remains to be tested, but at least for some purposes it is really great, and it is by far the easiest solution to configure and use. And the really nice thing about is that you do not need to configure or install anything on the server side.
University of Bergen VIP: 81724
One of our PhD students worked in Bergen for some time -- he says it is great :-))) Regards, January -- ------------ January Weiner 3 ---------------------+--------------- Division of Bioinformatics, University of Muenster | Schloßplatz 4 (+49)(251)8321634 | D48149 Münster http://www.uni-muenster.de/Biologie.Botanik/ebb/ | Germany
On Fri, 4 Jun 2004, January Weiner wrote:
Hello,
1) problem with high UID's, we have UIDs >> 65535 and the mounted samba shares do not get proper permissions
Haven't been a problem for a couple of years, as far as I can gather, definitely shouldn't be for Samba 3. Changed rather shortly after kernel 2.4 appeared supporting UiDs > 65535. Haven't tested this myself, just did a quick google just now.
Well. Take a look at https://bugzilla.samba.org/show_bug.cgi?id=1234 . If I understand it correctly, there are still many programs which use __kernel_uid_t instead of uid_t or __kernel_uid32_t.
I agree -- it should not be a problem. But it is.
Yes. You got me. And I've verified that this is a problem with the 3.0.2a which used to be provided on the suse ftp-server. I wonder whether a patched version is forthcoming, though it looks trivial enough to patch it yourself and compile - assuming the patch is good.
2) is it true that Samba does not support special files (like sockets), thus rendering this file system unusable for the purpose of mounting home directories to use e.g. with KDE (which needs to create sockets)?
Not true. 'Unix extension = yes' in smb.conf solves this, the problem with KDE is that it has odd (':' in particular) characters in filenames, this is solved by also setting 'mangled names = no'. Gnome, on the other hand, uses a file locking strategy which is broken with sambamount. Setting an environment variable GCONF_LOCAL_LOCKS=1 for the user moves the file locking to /tmp and makes Gnome useable, though the solution isn't optimal.
Thanks! That are good news for us. And what about directories exported from Windows?
Not tested, but the server file system lacks the attributes you want to see on your linux client so I can't see how it could work. For providing disk to multiple platforms, your server should be running unix or linux. The rest (NFS, Samba, whatever) is just cosmetics.
Am I wrong? What other possibilities are there?
Someone suggested VPN, which can force the user to authenticate to get an IP address - at which point IP security all of a sudden deserves to contain the word "security" in it.
:-)
OTOH -- as far as I understand, VPN encrypts the whole private network traffic, which may or may not be a problem in terms of performance.
VPN is a concept. It's not a protocol, and there's no one true VPN way of doing things. There's a tunnel. Whether you're running encrypted data, compressed data, encrypted compressed data or just raw data through depends on configuration and which VPN software you go for. There's overhead, but with raw data they should be negligible. Here at UiB we're running pptp without encryption, but don't ask me about configuration - not my field.
I have played now with shfs for a couple of days. Well, the code is maybe not very mature (I had to correct the high UID issue here as well), and the performance remains to be tested, but at least for some purposes it is really great, and it is by far the easiest solution to configure and use. And the really nice thing about is that you do not need to configure or install anything on the server side.
I like it when I can change things in one place - on a server - rather than running through hundreds of clients to make changes. But tastes differ, as do the level of influence one has on the server configurations.
One of our PhD students worked in Bergen for some time -- he says it is great :-)))
Except, of course, that the Bioinformatics group here is running DeadRat linux. >:( Bjørn -- Bjørn Tore Sund Phone: (+47) 555-84894 Stupidity is like a System administrator Fax: (+47) 555-89672 fractal; universal and Math. Department Mobile: (+47) 918 68075 infinitely repetitive. University of Bergen VIP: 81724 Support: system@mi.uib.no Contact: teknisk@mi.uib.no Direct: bjornts@mi.uib.no
I agree -- it should not be a problem. But it is.
Yes. You got me. And I've verified that this is a problem with the 3.0.2a which used to be provided on the suse ftp-server. I wonder whether a patched version is forthcoming, though it looks trivial enough to patch it yourself and compile - assuming the patch is good.
Yes, I applied the patch and rebuild the rpm's, works very nicely, uid's are perfectly OK.
Thanks! That are good news for us. And what about directories exported from Windows?
Not tested, but the server file system lacks the attributes you want to see on your linux client so I can't see how it could work. For providing disk to multiple platforms, your server should be running unix or linux. The rest (NFS, Samba, whatever) is just cosmetics.
Yeah. OK, I tell you what the other problem is -- apart from our home directories, which are on our server. There are university wide home directories for windows clients, and also shares with program files. It would be nice to access them, too. They are exported from ...VMS. :-))))
OTOH -- as far as I understand, VPN encrypts the whole private network traffic, which may or may not be a problem in terms of performance.
VPN is a concept. It's not a protocol, and there's no one true VPN way of doing things. There's a tunnel. Whether you're running encrypted data, compressed data, encrypted compressed data or just raw data through depends on configuration and which VPN software you go for. There's overhead, but with raw data they should be negligible. Here at UiB we're running pptp without encryption, but don't ask me about configuration - not my field.
OK, thanks.
I have played now with shfs for a couple of days. Well, the code is maybe not very mature (I had to correct the high UID issue here as well), and the performance remains to be tested, but at least for some purposes it is really great, and it is by far the easiest solution to configure and use. And the really nice thing about is that you do not need to configure or install anything on the server side.
I like it when I can change things in one place - on a server - rather than running through hundreds of clients to make changes. But tastes differ, as do the level of influence one has on the server configurations.
You've got a point there, but since either way I need to 1) configure VPN on all the clients or 2) install the patched samba on all the clients or 3) install shfs on all the clients, it is all the same for me. We have full power over our local data / home directories server, but of course there are central facilities like the central web services, program repositories or high performance clusters -- and they are not likely to open up anything else than ssh connection; so shfs is a nice way of accessing them.
One of our PhD students worked in Bergen for some time -- he says it is great :-)))
Except, of course, that the Bioinformatics group here is running DeadRat linux. >:(
I really, really hate to say that, I've been using SuSE ever since around the 5th version, but the last SuSE release got me really pissed of, and we are considering alternatives at this point of time (debian to be specific). The problems for me are - my favorite number one: the persistent nfslock problem - the automatic mounting of USB devices with "sync" option -- welcome back to floppy-and-DOS-era (why not mount the hard disk that way, too?) - problems with high uids in samba - printing: I distinctly remember that SuSE was able to detect CUPS servers available on the network automatically and out of the box, so what happened now? - dozens of minor configuration problems (ever tried to use ACPI on a laptop with SuSE 9.1? ever worked with custom LDAP settings? tried to export cups printers to Windows computers with yast? had to reinstall your system because yast got plem-plem and went medieval on your elaborate system of the library and package dependencies?) Then, there is this general KDE-centric attitude, which could be bearable if there were not so many problems, little annoyances and occasional crashes while running it. (For example, we have always some printing problems with konqueror/kprinter, sometimes it works, sometimes not, sometimes it crashes, sometimes it produces a dozen of blank pages. Mozilla does not seem to print at all via kprinter in SuSE 9.1...). Well, it is all nice and well for the corporate, computer-illiterate and Windows-educated user, but I'm too old to change my favorite editor and Window Manager :-)). Sorry, I know it is not the scope of this discussion list. I just had to rant a little. Regards, j. -- ------------ January Weiner 3 ---------------------+--------------- Division of Bioinformatics, University of Muenster | Schloßplatz 4 (+49)(251)8321634 | D48149 Münster http://www.uni-muenster.de/Biologie.Botanik/ebb/ | Germany
Hi, We should probably be moving off-list soon, this is drifting away from the topic of security. On Fri, 4 Jun 2004, January Weiner wrote:
Not tested, but the server file system lacks the attributes you want to see on your linux client so I can't see how it could work. For providing disk to multiple platforms, your server should be running unix or linux. The rest (NFS, Samba, whatever) is just cosmetics.
Yeah. OK, I tell you what the other problem is -- apart from our home directories, which are on our server. There are university wide home directories for windows clients, and also shares with program files. It would be nice to access them, too. They are exported from ...VMS. :-))))
Access is no problem. Useless as home directories, but as data repositories mounted as sub-directories of the proper home dir - no problem. I do that from Windows 200X servers all the time. Not sure you'd be able to run the program files (using wine?) but it would be worth a try.
Except, of course, that the Bioinformatics group here is running DeadRat linux. >:(
I really, really hate to say that, I've been using SuSE ever since around the 5th version, but the last SuSE release got me really pissed of, and we are considering alternatives at this point of time (debian to be specific).
The problems for me are - my favorite number one: the persistent nfslock problem
Fixed by enabling the nfslock service on clients. 'rcnfslock start' for the current session, 'insserv nfslock' to handle next reboot.
- the automatic mounting of USB devices with "sync" option -- welcome back to floppy-and-DOS-era (why not mount the hard disk that way, too?)
Hadn't noticed, what's the problem?
- problems with high uids in samba
Come on, the patch you found is from mid-April, no way that was going to make it into SuSE 9.1, in particular since it hasn't yet made it into the vanilla Samba 3.X. SuSE needs to work with the software as it is, they can't enhance every piece of software they pack up to some sort of standard.
- printing: I distinctly remember that SuSE was able to detect CUPS servers available on the network automatically and out of the box, so what happened now?
Works for me, tested with two SuSE 9.1 boxes at home this weekend.
- dozens of minor configuration problems (ever tried to use ACPI on a laptop with SuSE 9.1?
APM is a Known problem with kernel 2.6.X - but I really think it was the right decision for SuSE to go for 2.6 this time. Though they might have included 2.4 as an option, like they did during the 2.2 -> 2.4 switch- over (I forget which SuSE version that was) - but I realise this complicates things a lot. ACPI, by the way, only started working on my Asus L3 laptop when I upraded from SuSE 9.0 to 9.1. Working perfectly now, as far as I can determine, straight out of the box. But 2.6 does have problems which I'm hoping will have solutions soon - and maybe make it into a patched kernel from SuSE when they do.
ever worked with custom LDAP settings?
Does Active Directory count? Works fine with SuSE 9.0 as the client (haven't tested 9.1 yet).
Then, there is this general KDE-centric attitude, which could be bearable if there were not so many problems, little annoyances and occasional crashes while running it. (For example, we have always some printing problems with konqueror/kprinter, sometimes it works, sometimes not, sometimes it crashes, sometimes it produces a dozen of blank pages. Mozilla does not seem to print at all via kprinter in SuSE 9.1...).
All works fine on KDE 3.whatever on SuSE 8.2, 9.0, and 9.1 here. No problems, straight out of the box. I have had my problems with SuSE. 8.1 was badly broken, for instance, and I was never happy with the late 7.X editions. But do attack them on what they've done, not on stuff where they depend on others (Samba and kernel developers for instance) and really have no choice on what they deliver. Changing distro based on that will leave you with exactly the same problems + a few new ones related to having to figure out a new setup. Bjørn -- Bjørn Tore Sund Phone: (+47) 555-84894 Stupidity is like a System administrator Fax: (+47) 555-89672 fractal; universal and Math. Department Mobile: (+47) 918 68075 infinitely repetitive. University of Bergen VIP: 81724 Support: system@mi.uib.no Contact: teknisk@mi.uib.no Direct: bjornts@mi.uib.no
Hello, Bjorn Tore Sund wrote:
On Fri, 4 Jun 2004, January Weiner wrote: [...]
- the automatic mounting of USB devices with "sync" option -- welcome back to floppy-and-DOS-era (why not mount the hard disk that way, too?)
Hadn't noticed, what's the problem?
- I think it appears to be much slower since you have to wait (i. e. for the next prompt) until the data is written - in opposite to nosync whitch writes to the cache very fast and syncs to the disk in background. - USB sticks, CF cards, ... can only be written a limited number of times. With sync option, the directory indexes get updated more often (every time you do something with one file - copying of 100 files may mean 100 writes) and the lifetime of your USB stick may be reduced. There was an interesting discussion about this in suse-linux some time ago. If you understand German, you can find details in the list archives. Yours, Christian Boltz -- D: is just a data disk. That's why it's called "D", for "DATA". C: is the Windows OS disk, so it's called "C", for "CRAP". [David P. Murphy]
- the automatic mounting of USB devices with "sync" option -- welcome back to floppy-and-DOS-era (why not mount the hard disk that way, too?)
Hadn't noticed, what's the problem?
- I think it appears to be much slower since you have to wait (i. e. for the next prompt) until the data is written - in opposite to nosync whitch writes to the cache very fast and syncs to the disk in background.
- USB sticks, CF cards, ... can only be written a limited number of times. With sync option, the directory indexes get updated more often (every time you do something with one file - copying of 100 files may mean 100 writes) and the lifetime of your USB stick may be reduced. There was an interesting discussion about this in suse-linux some time ago. If you understand German, you can find details in the list archives.
The point is they expect you to pull out the drive without umounting it. Heck, even Windows have learned recently that mounting is useful, and MacOS had it always. SuSE is going in the opposite direction. So, what also counts for me is that when I'm e.g. compiling my music on my USB stick I would rather do several quick cp commands (possibly even from different xterms) and then wait for the umount to finish the job than - either wait after each cp, or - start many cp at once and forget about one when unplugging the stick Besides, it is often hard to tell whether there is somewhere some program still accessing the device, esp. if you work with it all the time. If you can umount, then it's fine, since umount will wait for the device to get free or issue a warning. But you cannot umount the devices mounted with subfs, you are just supposed to plug them out. That's why I say it's like in the good, ole DOS times: you need to wait for your program to finish writing the floppy, and then you take it out. No mounting or any other fancy stuff. The drawback is you can't hear the USB sticks to have finished writing -- some of them blink but hell, that's not the same. But one could try to implement a floppy-sound-emulator, possibly as kernel module. j., getting sarcastic after 15 hours of doing science
Quoting Christian Boltz
Bjorn Tore Sund wrote:
On Fri, 4 Jun 2004, January Weiner wrote: [...]
- the automatic mounting of USB devices with "sync" option -- welcome back to floppy-and-DOS-era (why not mount the hard disk that way, too?)
Hadn't noticed, what's the problem?
- I think it appears to be much slower since you have to wait (i. e. for the next prompt) until the data is written - in opposite to nosync whitch writes to the cache very fast and syncs to the disk in background.
- USB sticks, CF cards, ... can only be written a limited number of times. With sync option, the directory indexes get updated more often (every time you do something with one file - copying of 100 files may mean 100 writes) and the lifetime of your USB stick may be reduced. There was an interesting discussion about this in suse-linux some time ago. If you understand German, you can find details in the list archives.
I believe it's probably a good idea to have "sync" on as the default. Casual users will find it useful. That said, if you're planning on using it for any length of time, put an entry in the fstab and mount it properly. The speed difference between 'sync' and normal is INCREDIBLE. I've recently be using USB hard drives. When I first plugged them in, I had them mounted with sync. I doubt they were writing at even 1 meg/sec. Far too slow to get anything done. Remove the 'sync' option and they function just like regular hard drives. Not quite as fast (I wouldn't want to put a swap partition on one), but very reasonable for data storage.
Hi January, i'm using shfs a lot for sending and retrieving hard disk images via network in a secure way. This works like a charm for me, even for very big files. The "clients" are only running a debian on a ramdisk. Performance is fine. I noticed a bug (although i dont have the most recent shfs on my recovery boot cd) in shfs. Sometimes when you edit a file on the server side and the has accessed in before hand, accessing the file on the client again will give you the old file (seems to be a issue with file caching, checksums or timestamps). If that is an issue in your setup, you may want to check this first. Also shfs does not support "sparse files", although in a common setup you should not need this. peace, Tom January Weiner wrote:
I have played now with shfs for a couple of days. Well, the code is maybe not very mature (I had to correct the high UID issue here as well), and the performance remains to be tested, but at least for some purposes it is really great, and it is by far the easiest solution to configure and use. And the really nice thing about is that you do not need to configure or install anything on the server side.
participants (8)
-
Arjen Runsink -
Bjorn Tore Sund -
Christian Boltz -
Ferdinand Schmid -
January Weiner -
Ralf Farke -
suse＠rio.vg -
Thomas Seliger