Please anybody interested in improving current status of printing configuration - test it and give me (any) feedback.
Thank you,
Michal
Monday, August 11, 2008
New YaST2 printer configuration module
Today I submitted new version of yast2-printer (2.17.2). This version contains big (major) changes. It uses Johannes Meixner's code from Build service, based on some ideas to improve current status.
Please anybody interested in improving current status of printing configuration - test it and give me (any) feedback.
Thank you,
Michal
Please anybody interested in improving current status of printing configuration - test it and give me (any) feedback.
Thank you,
Michal
Thursday, August 7, 2008
Installation via wireless network
I fixed some issues in yast2-network-2.17.16 and did some tests and the result is : it works fine!
1 - Boot into any already installed linux, download kernel & initrd, create /boot/grub/menu.lst entry - some documentation here, also possible to use miniISO
2 - Into bootloader pass install=$custom_or_public_NETWORK_repository option
3 - Unplug your wired card
4 - With this setup will Linuxrc try to use your wireless network card to connect network repository. There are some dialogs to specify ESSID, WEP/WPA and sharedkey
5 - In case of connection succeed, do installation as usual (via wireless ;-))
6 - Before first reboot this network setup will be saved as persistent (into /etc/sysconfig/network/ifcfg-wlan0)
7 - During next boot (2nd stage of installation) wireless network is automatically up and you can finish installation
1 - Boot into any already installed linux, download kernel & initrd, create /boot/grub/menu.lst entry - some documentation here, also possible to use miniISO
2 - Into bootloader pass install=$custom_or_public_NETWORK_repository option
3 - Unplug your wired card
4 - With this setup will Linuxrc try to use your wireless network card to connect network repository. There are some dialogs to specify ESSID, WEP/WPA and sharedkey
5 - In case of connection succeed, do installation as usual (via wireless ;-))
6 - Before first reboot this network setup will be saved as persistent (into /etc/sysconfig/network/ifcfg-wlan0)
7 - During next boot (2nd stage of installation) wireless network is automatically up and you can finish installation
Monday, August 4, 2008
YaST network and Tunnels
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
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
Using TAP device with VirtualBox.
Virtualized machine through tunnel connected into bridge is accessible from outside network!
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!
Monday, July 21, 2008
AutoYaST, network device names
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
/etc/udev/rules.d/70-persistent-net.rules file as a result:
4 - Migration from SLES10-style syntax. When you use your old profile (from <=SLES10x), it's something like:
YaST will convert device name eth-id-08:00:27:07:a2:2d into rule for udev:
and rename configuration name into eth0
And that's all for now ...
... have a lot of fun
Bye,
Michal
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
Wednesday, July 9, 2008
Network Documentation
I started to document some exceptions or special cases of network during installation. But this is I already know (I don't know what users don't know or wants to know ;-)) so if anybody wants to some parts be more detailed or something is missing there, your feedback is welcome.
Thursday, July 3, 2008
IPv6 - network, applications, ...
As I already wrote, there is support in YaST network module to configure IPv6 addresses (one or more), possibly mixed with IPv4:
But what is really new - support to configure apache2 server for IPv6 environment:
Setup on which addresses apache listen
Detail of virtual host (based on IP)
And test that it works:
This is in version yast2-http-server-2.17.2
But what is really new - support to configure apache2 server for IPv6 environment:
Setup on which addresses apache listen
Detail of virtual host (based on IP)
And test that it works:
This is in version yast2-http-server-2.17.2
Sunday, June 22, 2008
web UI for YaST
With python-bindings we can slowly move our wishes from impossible into possible group.One of our wishes is web UI. Today before lunch I did some research, and it works!
Fist of all enable mod_python in apache2, then configure Handler for Python.
Then write index.py with this code:
def getDescription():
import ycp
ycp.import_module('Lan')
ycp.import_module('LanItems')
ycp.Lan.Read(ycp.Term('nocache'))
interfaces=ycp.LanItems.Overview()
descr="<table>"
for interface in interfaces:
descr+="<tr><td>"+interface['table_descr'][0]+"</td>"
descr+="<td>"+interface['rich_descr']+"</td></tr>"
descr+="</table>"
return descr
def index():
s = """\
<html>
<body>
"""+getDescription()+"""
</body>
</html>
"""
return s
It needs some hack - disable check if YaST code is running as root. I commented one line in Lan::Read() function. And result is here:
It's just summary of network devices configuration. I know it's very simple example, but as I wrote - the plan was to do it before lunch, not instead of ;-)
Fist of all enable mod_python in apache2, then configure Handler for Python.
Then write index.py with this code:
def getDescription():
import ycp
ycp.import_module('Lan')
ycp.import_module('LanItems')
ycp.Lan.Read(ycp.Term('nocache'))
interfaces=ycp.LanItems.Overview()
descr="<table>"
for interface in interfaces:
descr+="<tr><td>"+interface['table_descr'][0]+"</td>"
descr+="<td>"+interface['rich_descr']+"</td></tr>"
descr+="</table>"
return descr
def index():
s = """\
<html>
<body>
"""+getDescription()+"""
</body>
</html>
"""
return s
It needs some hack - disable check if YaST code is running as root. I commented one line in Lan::Read() function. And result is here:
| PRO/Wireless 3945ABG Network Connection | PRO/Wireless 3945ABG Network Connection (Not connected) MAC : 00:18:de:64:b8:0d The device is not configured. Press Edit |
| 82573L Gigabit Ethernet Controller | 82573L Gigabit Ethernet Controller MAC : 00:16:41:aa:74:56
|
It's just summary of network devices configuration. I know it's very simple example, but as I wrote - the plan was to do it before lunch, not instead of ;-)
Wednesday, June 18, 2008
IPv6, prefixlen
This story started when I discussed with our openSUSE member Marek Stopka and he told me that he is running IPv6 network but because of really bad support in YaST2 he needs to configure that manually.
Oh, what a shame! So we made a deal that he'll test my patches and I'll try to implement initial support.
So now we have initial support for IPv6 in YaST. Initial means that you're able to configure "primary" address IPv6 type. Nothing more, nothing less.
Because of this I add new parameter to configure prefixlen (in v6 there is no netmask as we know from v4). In UI you can configure prefix with a little trick - instead of 255.255.255.0 you can write "/24".
Ok, example of CLI:
And some screenshots from ncurses UI:
Of course there's still much work to implement full support, routing, network services support, test all possible cases, AutoYaST, etc.
Implemented in yast2-network-2.17.1
Oh, what a shame! So we made a deal that he'll test my patches and I'll try to implement initial support.
So now we have initial support for IPv6 in YaST. Initial means that you're able to configure "primary" address IPv6 type. Nothing more, nothing less.
Because of this I add new parameter to configure prefixlen (in v6 there is no netmask as we know from v4). In UI you can configure prefix with a little trick - instead of 255.255.255.0 you can write "/24".
Ok, example of CLI:
linux-1pi7:~ # yast lan list
0 79c970 [PCnet32 LANCE], Not configured
1 79c970 [PCnet32 LANCE], Not configured
linux-1pi7:~ # yast lan edit id=0 ip=2001:15c0:668e::5 prefix=48
Ethernet Network Card
MAC : 08:00:27:80:b5:07
Device Name: eth1
Started automatically at boot
IP address: 2001:15c0:668e::5/48
linux-1pi7:~ # yast lan list
0 Ethernet Network Card, 2001:15c0:668e::5
1 79c970 [PCnet32 LANCE], Not configured
linux-1pi7:~ #
And some screenshots from ncurses UI:
Of course there's still much work to implement full support, routing, network services support, test all possible cases, AutoYaST, etc.
Implemented in yast2-network-2.17.1
Saturday, June 14, 2008
running YaST in debugger
First of all - I like Python.
Second - we have some prototype for mysql-server configuration written in Python I never tried before.
So I check-in code from subversion and try to run. Unfortunately it exits with some errors like "couldn't initialize UI". So I open the code in Eric - great Python debugger.
With breakpoints, globals and locals variables dispatcher it was really easy to find problematic places in code. Also possibility to write code interactively into interpreter is very helpful.
And finally module runs ;-)
Sorry, video is pretty slow - probably ati driver problem ;-(
Second - we have some prototype for mysql-server configuration written in Python I never tried before.
So I check-in code from subversion and try to run. Unfortunately it exits with some errors like "couldn't initialize UI". So I open the code in Eric - great Python debugger.
With breakpoints, globals and locals variables dispatcher it was really easy to find problematic places in code. Also possibility to write code interactively into interpreter is very helpful.
And finally module runs ;-)
Sorry, video is pretty slow - probably ati driver problem ;-(
Monday, June 9, 2008
http-server, dns-server integration
Actually this is not new feature, but because I re-tested that functionality today, I found it's good time to describe it in a few words.
Integration in this case means that you can configure DNS server records while adding new virtual hosts for apache HTTP server (with YaST, both on the same machine)
yast2-dns-server
First - DNS server must be installed, enabled and running:
Then add new zone (it must be type "Master"):
yast2-http-server
Then in yast2-http-server module add new virtual host. Server name belongs into dns zone "example.com" we configured in yast2-dns-server:
Virtual Host ID must be valid IP address
And here we can see there is button "Add to Zone" which in this case will add record www.example.com with IP address 10.20.30.40 into example.com zone
yast2-dns-server
When you open YaST DNS server again, you can see that new record for "example.com" zone was correctly added.
Integration in this case means that you can configure DNS server records while adding new virtual hosts for apache HTTP server (with YaST, both on the same machine)
yast2-dns-server
First - DNS server must be installed, enabled and running:
Then add new zone (it must be type "Master"):
yast2-http-server
Then in yast2-http-server module add new virtual host. Server name belongs into dns zone "example.com" we configured in yast2-dns-server:
Virtual Host ID must be valid IP address
And here we can see there is button "Add to Zone" which in this case will add record www.example.com with IP address 10.20.30.40 into example.com zone
yast2-dns-server
When you open YaST DNS server again, you can see that new record for "example.com" zone was correctly added.
Thursday, June 5, 2008
Command Line Interface
This is probably nothing new but for those who don't know yet ...
You can run every YaST2 module in Qt, GTK or Ncurses UI. Some of that modules has implemented also command line interface. Just type: yast module_name help and you will see something like this:
In case module doesn't support CLI, output is like:
Option interactive is useful when you want to do several actions, because read and write are done only one. Difference between using ip or ifconfig commands and yast lan is that yast lan works with configurations, not only current status.
Ok, so let's start with example. List all network cards:
See configuration of last device:
Change configuration to DHCP :
Done, that was easy ;-)
Bye,
Michal
You can run every YaST2 module in Qt, GTK or Ncurses UI. Some of that modules has implemented also command line interface. Just type: yast module_name help and you will see something like this:
linux:/home/mzugec # yast lan help
YaST Configuration Module lan
------------------------------
Network Card Configuration
Basic Syntax:
yast2 lan interactive
yast2 lan[verbose] [options]
yast2 lan help
yast2 lan longhelp
yast2 lan xmlhelp
yast2 lanhelp
Commands:
add Add a network card
delete Delete a network card
edit Change existing configuration
list Display configuration summary
show Display configuration summary
Run 'yast2 lanhelp' for a list of available options.
In case module doesn't support CLI, output is like:
linux:/home/mzugec # yast dsl help
There is no user interface available for this module.
Option interactive is useful when you want to do several actions, because read and write are done only one. Difference between using ip or ifconfig commands and yast lan is that yast lan works with configurations, not only current status.
Ok, so let's start with example. List all network cards:
linux:/home/mzugec # yast lan list
0 Ethernet Network Card, DHCP
1 79c970 [PCnet32 LANCE], Not configured
2 79c970 [PCnet32 LANCE], DHCP
3 Ethernet Network Card, 10.20.30.40
See configuration of last device:
linux:/home/mzugec # yast lan show id=3
Ethernet Network Card
MAC : 08:00:27:d9:db:b7
Device Name: eth0
Started automatically at boot
IP address: 10.20.30.40, subnet mask 255.255.255.0
Change configuration to DHCP :
linux:/home/mzugec # yast lan edit id=3 bootproto=dhcp
Device Type : eth
Bootproto : dhcp
IP Address :
Mask :
Done, that was easy ;-)
Bye,
Michal
Monday, May 26, 2008
Research of possibility: running YaST anywhere
Hello !
One week ago I installed Fedora Core 9 distribution. But (experienced from openSUSE) there was something I missed : YaST and zypper. So I decide to port them to Fedora (and maybe to other distributons later).
I did something similar a long time ago (it was FC5) but now it seems much easier. Our developers makes UI part independent from ycp language. So I just compile libyui, libyui-bindings, qt, ncurses and was able to run example code in both frontends. With GTK there is still problem that is not cleaned from libzypp dependency.
Then I compiled libzypp and zypper. Then I add installation source - local CD-rom:
And it works perfectly!
Compared to yum is zypper much, much faster. Just for an example (I turn autorefresh on, by default is autorefresh disabled):
With autorefresh disabled search time is even better:
Note: I don't wan't to say which tool is better (everybody knows ;-)). Just that you can use zypper on the same installation source like yum. There are some requests on that porting from RH/Fedora users. And also some other people are thinking about this.
Ok, after that I compiled yast2-core, yast2-devtools, yast2-testsuite, yast2-perl-bindings, yast2-ycp-ui-bindings, yast2, yast2-pkg-bindings (maybe I forgot something, sorry). Finally mine package yast2-iscsi-client. Some patch because of distribution differences ... and the result is:
It works! ;-)
So we definitely can run YaST and its configuration modules on Fedora Core 9!
Ok, some work is needed to be done: create Build Service project and as a first step some distribution based patches. After that we should find some system how to use different backends for different distributions (like NetworkManager does). But this is something for another post ...
Good night,
Michal
One week ago I installed Fedora Core 9 distribution. But (experienced from openSUSE) there was something I missed : YaST and zypper. So I decide to port them to Fedora (and maybe to other distributons later).
I did something similar a long time ago (it was FC5) but now it seems much easier. Our developers makes UI part independent from ycp language. So I just compile libyui, libyui-bindings, qt, ncurses and was able to run example code in both frontends. With GTK there is still problem that is not cleaned from libzypp dependency.
Then I compiled libzypp and zypper. Then I add installation source - local CD-rom:
zypper ar cd:///?devices=/dev/sr0 CD
And it works perfectly!
Compared to yum is zypper much, much faster. Just for an example (I turn autorefresh on, by default is autorefresh disabled):
[root@dhcp24 ~]# time zypper se rpmlint
Reading installed packages...
S | Name | Summary | Type
--+---------+-------------------------------------------------+--------
| rpmlint | Tool for checking common errors in RPM packages | package
real 0m0.958s
user 0m0.308s
sys 0m0.482s
[root@dhcp24 ~]# time yum search rpmlint
Loaded plugins: refresh-packagekit
======================================== Matched: rpmlint =========================================
rpmlint.noarch : Tool for checking common errors in RPM packages
real 0m2.765s
user 0m1.826s
sys 0m0.788s
With autorefresh disabled search time is even better:
[root@dhcp24 ~]# time zypper se rpmlint
Reading installed packages...
S | Name | Summary | Type
--+---------+-------------------------------------------------+--------
| rpmlint | Tool for checking common errors in RPM packages | package
real 0m0.717s
user 0m0.289s
sys 0m0.362s
Note: I don't wan't to say which tool is better (everybody knows ;-)). Just that you can use zypper on the same installation source like yum. There are some requests on that porting from RH/Fedora users. And also some other people are thinking about this.
Ok, after that I compiled yast2-core, yast2-devtools, yast2-testsuite, yast2-perl-bindings, yast2-ycp-ui-bindings, yast2, yast2-pkg-bindings (maybe I forgot something, sorry). Finally mine package yast2-iscsi-client. Some patch because of distribution differences ... and the result is:
It works! ;-)
So we definitely can run YaST and its configuration modules on Fedora Core 9!
Ok, some work is needed to be done: create Build Service project and as a first step some distribution based patches. After that we should find some system how to use different backends for different distributions (like NetworkManager does). But this is something for another post ...
Good night,
Michal
Friday, April 4, 2008
YaST2 Network - metric
Last Friday I added support for metric into Route dialog. You can imagine metric as "preference" value.
Example of use:
We have 2 interfaces, eth0 and eth1. Both of them are connected into different networks with different routes (we have 2 possible gateways). Here we can set one of them as default gateway. When it somehow failed we lost connetion.
Solution:
In situation above we can set both routes as a default route with different metrics. Set devices controled with ifplugd daemon. Route with higher metric is used as default. When device is disconnected, it's route is removed and the next one is used.
Note:
Current kernel doesn't use metric in static routing, Only routing daemons like multipathd does.
Monday, March 17, 2008
YaST2 network, driver options
I've added support for driver options for openSUSE-11.0.
This is feature I don't really use, but some of openSUSE or SLES users does. Maybe I'll need it when I will play more with bonding devices.
Hm, feature ...
In fact it brings back functionality that there was already there. But it was done in "hwcfg" files - deprecated configuration files for hardware devices. Now that configuration is stored in /etc/modprobe.d/network. But it's probably not final solution.
Why? because all that options are stored "on one place" but options packaged by driver rpms are stored in /etc/modprobe.d/$driver_name.
Maybe in future I'll change that place or enhance functionality to work on whole directory, but I need some feedback or opinions. Are there any?
This is feature I don't really use, but some of openSUSE or SLES users does. Maybe I'll need it when I will play more with bonding devices.
Hm, feature ...
In fact it brings back functionality that there was already there. But it was done in "hwcfg" files - deprecated configuration files for hardware devices. Now that configuration is stored in /etc/modprobe.d/network. But it's probably not final solution.
Why? because all that options are stored "on one place" but options packaged by driver rpms are stored in /etc/modprobe.d/$driver_name.
Maybe in future I'll change that place or enhance functionality to work on whole directory, but I need some feedback or opinions. Are there any?
Sunday, March 16, 2008
YaST2 network, bridge devices
Hello,
this is my first (and very short) blog about YaST2 development.
I put some screenshots here: new features::bridge.
What is bridged network good for? Mostly for network used with virtualisation (Xen, VirtualBox, Vmware, etc.). For this purpose all virtualisation products has their own tools, configurations and scripts.
This (per-virtualisation-application) has some disadvantages:
- possible conflict between sysconfig
- not unified way how to configure
- network configuration can't be clone by AutoYaST
That's why it makes sense to be implemented in YaST
Briefed introduction : when you want for any of your hosted machine to be seen from network, create bridge attached with physical network interface and some tun device. TUN device will be attached into your virtual machine and it makes virtual hosted machine be directly connected to real LAN.
The plan is (together with bridge) to implement also support for tun/tap devices (this should be done in sysconfig first) and Xen networking to confgure all this staff in one place.
Do you like this feature? If you have any feedback, comment or enhancement request - please let me know.
this is my first (and very short) blog about YaST2 development.
I put some screenshots here: new features::bridge.
What is bridged network good for? Mostly for network used with virtualisation (Xen, VirtualBox, Vmware, etc.). For this purpose all virtualisation products has their own tools, configurations and scripts.
This (per-virtualisation-application) has some disadvantages:
- possible conflict between sysconfig
- not unified way how to configure
- network configuration can't be clone by AutoYaST
That's why it makes sense to be implemented in YaST
Briefed introduction : when you want for any of your hosted machine to be seen from network, create bridge attached with physical network interface and some tun device. TUN device will be attached into your virtual machine and it makes virtual hosted machine be directly connected to real LAN.
The plan is (together with bridge) to implement also support for tun/tap devices (this should be done in sysconfig first) and Xen networking to confgure all this staff in one place.
Do you like this feature? If you have any feedback, comment or enhancement request - please let me know.
Subscribe to:
Posts (Atom)