Re: [gentoo-user] net-mail/mailbase-1.1 and access rights of /var/spool/mail
On Tue, 29 Jan 2013 06:37:47 + Mick michaelkintz...@gmail.com wrote: Hi All, I got this message when net-mail/mailbase-1.1 was emerged: * Messages for package net-mail/mailbase-1.1: * Your //var/spool/mail/ directory permissions differ from * those which mailbase wants to set it to (03775). * If you did not change them on purpose, consider running: * * chown root:mail //var/spool/mail/ * chmod 03775 //var/spool/mail/ Running this chmod changed access rights from: drwxrwxr-x 2 root mail 4096 Jan 28 19:57 mail to a sticky-fied: drwxrwsr-t 2 root mail 4096 Jan 28 19:57 mail Any idea why are the sticky bits for group and others required? sticky for group so that all sub-dirs and files in them are owned by the mail group. Without it, they would be owned by the user running mailx and the mail system can no longer manager them. sticky for others is so that you can't delete my mail but you can still create your own mail spool files. Identical logic to /tmp (assuming that you are in the mail group) -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] ebtables on Gentoo?
Hello, From here: http://ebtables.sourceforge.net/ We read: The ebtables tool can be combined with the other Linux filtering tools (iptables, ip6tables and arptables) to make a bridging firewall that is also capable of filtering these higher network layers. This is enabled through the bridge-netfilter architecture which is a part of the standard Linux kernel. Can someone explain to me when/how you would use ebtables for enhanced security, or forward me to a good written presentation on when, why or how to deploy ebtables? Maybe a package already blends these components together? I recently saw ebtables pop up in a commercial product ( sniffed terminal boot session) offered by Seimens.. Of keen interest is documentation/experiences on the Gentoo platform when using ebtables. Googling has provided little. curiously, James
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
Am 28.01.2013 22:49, schrieb Stefan G. Weichinger:
ps: my bigger hurdle will be the bridging-setup for running
KVM-virtualization. This was one of the reasons to go back to openrc
back then.
I have no experience with that, but if it works in OpenRC it should
work in systemd. Probably better, even.
I don't think it won't work, I just wonder how to do it in the right and
most efficient way. I will think about that later/tomorrow maybe,
already late here ...
I have a *draft* here for bridge.service ... I used the init.d-script
from here as a template:
http://en.gentoo-wiki.com/wiki/KVM#Script_to_ease_the_configuration
(I used a variation of that as /etc/init.d/kvm for long now)
My service-file reads variables from a separated configfile:
# cat /etc/conf.d/network_systemd
interface=eth0
address=172.32.99.12
netmask=255.255.255.0
broadcast=172.32.99.255
gateway=172.32.99.250
bridge_name=br0
tap_name=qtap0
user=sgw
and it currently looks like this:
# cat /etc/systemd/system/bridge.service
[Unit]
Description=network bridge for KVM
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/network_systemd
ExecStart=/sbin/brctl addbr ${bridge_name}
ExecStart=/usr/bin/tunctl -b -u ${user} -t ${tap_name}
ExecStart=/bin/ifconfig ${bridge_name} ${address} netmask ${netmask} up
ExecStart=/bin/ifconfig ${interface} up
ExecStart=/bin/ifconfig ${tap_name} up 0.0.0.0 promisc
ExecStart=/sbin/brctl addif ${bridge_name} ${tap_name} ${interface}
ExecStart=/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=1
ExecStart=iptables -t nat -A POSTROUTING -o ${interface} -j MASQUERADE
ExecStart=/bin/ip route add default via ${gateway}
ExecStop=/bin/ip route del default via ${gateway}
ExecStop=/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=0
ExecStop=/bin/ifconfig ${tap_name} down
ExecStop=/sbin/brctl delif ${bridge_name} ${tap_name}
ExecStop=/usr/bin/tunctl -d ${tap_name}
ExecStop=/bin/ifconfig ${bridge_name} down
ExecStop=/bin/ifconfig ${interface} down
ExecStop=/sbin/brctl delbr ${bridge_name}
ExecStop=iptables -t nat -D POSTROUTING -o ${interface} -j MASQUERADE
[Install]
WantedBy=multi-user.target
--
I disabled network.service and enabled bridge.service, works fine so
far, I already tested connectivity from KVM-VMs.
I am sure that this quite fresh and bloody, suggestions welcome as
always ...
Stefan
Re: [gentoo-user] net-mail/mailbase-1.1 and access rights of /var/spool/mail
On Tuesday 29 Jan 2013 10:19:16 Alan McKinnon wrote: On Tue, 29 Jan 2013 06:37:47 + Mick michaelkintz...@gmail.com wrote: Hi All, I got this message when net-mail/mailbase-1.1 was emerged: * Messages for package net-mail/mailbase-1.1: * Your //var/spool/mail/ directory permissions differ from * those which mailbase wants to set it to (03775). * If you did not change them on purpose, consider running: * * chown root:mail //var/spool/mail/ * chmod 03775 //var/spool/mail/ Running this chmod changed access rights from: drwxrwxr-x 2 root mail 4096 Jan 28 19:57 mail to a sticky-fied: drwxrwsr-t 2 root mail 4096 Jan 28 19:57 mail Any idea why are the sticky bits for group and others required? sticky for group so that all sub-dirs and files in them are owned by the mail group. Without it, they would be owned by the user running mailx and the mail system can no longer manager them. sticky for others is so that you can't delete my mail but you can still create your own mail spool files. Identical logic to /tmp (assuming that you are in the mail group) Thanks Alan, it makes sense now. No one other than mail are in the mail group in this box (my laptop): $ less /etc/group | grep mail mail:x:12:mail I have rkhunter and some cron jobs using ssmtp to email me log info, but they have been running as root. That's why I hadn't experienced a problem with the previous access rights. I wonder why this was picked up in the 1.1 version and not previously - perhaps a test was added on purpose in the ebuild. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ebtables on Gentoo?
On Tue, Jan 29, 2013 at 9:45 AM, James wirel...@tampabay.rr.com wrote: Hello, From here: http://ebtables.sourceforge.net/ We read: The ebtables tool can be combined with the other Linux filtering tools (iptables, ip6tables and arptables) to make a bridging firewall that is also capable of filtering these higher network layers. This is enabled through the bridge-netfilter architecture which is a part of the standard Linux kernel. Can someone explain to me when/how you would use ebtables for enhanced security, or forward me to a good written presentation on when, why or how to deploy ebtables? Maybe a package already blends these components together? I recently saw ebtables pop up in a commercial product ( sniffed terminal boot session) offered by Seimens.. Of keen interest is documentation/experiences on the Gentoo platform when using ebtables. Googling has provided little. curiously, James iptables and ip6tables operate at the data layer, layer 3. ebtables operates at the link layer, layer 2. This is really the best explanation I can offer, as I haven't used ebtables myself: http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg -- :wq
[gentoo-user] Re: ebtables on Gentoo?
Michael Mol mikemol at gmail.com writes: iptables and ip6tables operate at the data layer, layer 3. ebtables operates at the link layer, layer 2. http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg Nice diagram. I'm surveying what's new/available for wired and wireless networks. Both to secure them and then analyze both sides of the interface. http://airmagnet.flukenetworks.com/products/demo/ I did find this android app for simple problem resolution: http://a.farproc.com/wifi-analyzer thx, james
Re: [gentoo-user] ebtables on Gentoo?
On 01/29/2013 09:45 AM, James wrote: Hello, From here: http://ebtables.sourceforge.net/ We read: The ebtables tool can be combined with the other Linux filtering tools (iptables, ip6tables and arptables) to make a bridging firewall that is also capable of filtering these higher network layers. This is enabled through the bridge-netfilter architecture which is a part of the standard Linux kernel. Can someone explain to me when/how you would use ebtables for enhanced security, or forward me to a good written presentation on when, why or how to deploy ebtables? Maybe a package already blends these components together? I recently saw ebtables pop up in a commercial product ( sniffed terminal boot session) offered by Seimens.. tl;dr ebtables makes it easy to isolate your interfaces in an unsafe environment. This was over a year ago, and the project fell through, so this is just from memory: We were planning on hosting a very insecure electronic health thingy that needs to run on a server (if you want support). The doctors who use it don't have the expertise to maintain it, and the people who sell it didn't have the expertise to do much of anything in my opinion. Since it was just a java web application, the servers didn't need to be powerful. But for HIPAA (and my own peace of mind) we wanted the servers to be as isolated as possible. We decided on using KVM virtual machines, each bridged through to its own public IP address on the host. For preventing *external* traffic, iptables is fine. We obviously don't want the RDP ports open to the world, for example. But how do we prevent one VM instance from communicating with another? One doctor's office shouldn't be able to connect to another office's server. If Dr. Foo notices that he can crash his application by entering nonsense into the login form, then he might suppose that he could crash Dr. Bar's application by doing the same thing. So anyway, my memory of this is all very wishy-washy, but ebtables turned out to be the best way to implement those inter-VM restrictions. It could probably have been done in iptables, but ebtables made it easy to say don't let these two talk.
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
On Tue, Jan 29, 2013 at 10:32 AM, Stefan G. Weichinger li...@xunil.at wrote:
Am 28.01.2013 22:49, schrieb Stefan G. Weichinger:
ps: my bigger hurdle will be the bridging-setup for running
KVM-virtualization. This was one of the reasons to go back to openrc
back then.
I have no experience with that, but if it works in OpenRC it should
work in systemd. Probably better, even.
I don't think it won't work, I just wonder how to do it in the right and
most efficient way. I will think about that later/tomorrow maybe,
already late here ...
I have a *draft* here for bridge.service ... I used the init.d-script
from here as a template:
http://en.gentoo-wiki.com/wiki/KVM#Script_to_ease_the_configuration
(I used a variation of that as /etc/init.d/kvm for long now)
My service-file reads variables from a separated configfile:
# cat /etc/conf.d/network_systemd
interface=eth0
address=172.32.99.12
netmask=255.255.255.0
broadcast=172.32.99.255
gateway=172.32.99.250
bridge_name=br0
tap_name=qtap0
user=sgw
and it currently looks like this:
# cat /etc/systemd/system/bridge.service
[Unit]
Description=network bridge for KVM
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/network_systemd
ExecStart=/sbin/brctl addbr ${bridge_name}
ExecStart=/usr/bin/tunctl -b -u ${user} -t ${tap_name}
ExecStart=/bin/ifconfig ${bridge_name} ${address} netmask ${netmask} up
ExecStart=/bin/ifconfig ${interface} up
ExecStart=/bin/ifconfig ${tap_name} up 0.0.0.0 promisc
ExecStart=/sbin/brctl addif ${bridge_name} ${tap_name} ${interface}
ExecStart=/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=1
ExecStart=iptables -t nat -A POSTROUTING -o ${interface} -j MASQUERADE
ExecStart=/bin/ip route add default via ${gateway}
ExecStop=/bin/ip route del default via ${gateway}
ExecStop=/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=0
ExecStop=/bin/ifconfig ${tap_name} down
ExecStop=/sbin/brctl delif ${bridge_name} ${tap_name}
ExecStop=/usr/bin/tunctl -d ${tap_name}
ExecStop=/bin/ifconfig ${bridge_name} down
ExecStop=/bin/ifconfig ${interface} down
ExecStop=/sbin/brctl delbr ${bridge_name}
ExecStop=iptables -t nat -D POSTROUTING -o ${interface} -j MASQUERADE
[Install]
WantedBy=multi-user.target
--
I disabled network.service and enabled bridge.service, works fine so
far, I already tested connectivity from KVM-VMs.
I am sure that this quite fresh and bloody, suggestions welcome as
always ...
If it works, it works. It just looks... wrong :D
If you really need so much commands from your unit, you can use a script:
$ cat /usr/local/bin/kvm-brigdge
#!/bin/sh
source /etc/conf.d/network_systemd
case ${1} in
start)
/sbin/brctl addbr ${bridge_name}
/usr/bin/tunctl -b -u ${user} -t ${tap_name}
/bin/ifconfig ${bridge_name} ${address} netmask ${netmask} up
/bin/ifconfig ${interface} up
/bin/ifconfig ${tap_name} up 0.0.0.0 promisc
/sbin/brctl addif ${bridge_name} ${tap_name} ${interface}
/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=1
iptables -t nat -A POSTROUTING -o ${interface} -j MASQUERADE
/bin/ip route add default via ${gateway}
;;
stop)
/bin/ip route del default via ${gateway}
/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=0
/bin/ifconfig ${tap_name} down
/sbin/brctl delif ${bridge_name} ${tap_name}
/usr/bin/tunctl -d ${tap_name}
/bin/ifconfig ${bridge_name} down
/bin/ifconfig ${interface} down
/sbin/brctl delbr ${bridge_name}
iptables -t nat -D POSTROUTING -o ${interface} -j MASQUERADE
;;
esac
$ cat /etc/systemd/system/kvm-bridge.service
[Unit]
Description=network bridge for KVM
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/kvm-brigdge start
ExecStop=/usr/local/bin/kvm-brigdge stop
[Install]
WantedBy=multi-user.target
As I have been saying all this years: that systemd can work without
using scripts, doesn't mean that it isn't able to use them. I use a
couple of them myself; I think this is a perfect example of one. Your
unit file then it's small and simple, as all of them should be.
Remember that /usr/local/bin/kvm-brigdge needs to be executable.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
On Tue, Jan 29, 2013 at 1:57 PM, Canek Peláez Valdés can...@gmail.com wrote:
On Tue, Jan 29, 2013 at 10:32 AM, Stefan G. Weichinger li...@xunil.at wrote:
Am 28.01.2013 22:49, schrieb Stefan G. Weichinger:
ps: my bigger hurdle will be the bridging-setup for running
KVM-virtualization. This was one of the reasons to go back to openrc
back then.
I have no experience with that, but if it works in OpenRC it should
work in systemd. Probably better, even.
I don't think it won't work, I just wonder how to do it in the right and
most efficient way. I will think about that later/tomorrow maybe,
already late here ...
I have a *draft* here for bridge.service ... I used the init.d-script
from here as a template:
http://en.gentoo-wiki.com/wiki/KVM#Script_to_ease_the_configuration
(I used a variation of that as /etc/init.d/kvm for long now)
My service-file reads variables from a separated configfile:
# cat /etc/conf.d/network_systemd
interface=eth0
address=172.32.99.12
netmask=255.255.255.0
broadcast=172.32.99.255
gateway=172.32.99.250
bridge_name=br0
tap_name=qtap0
user=sgw
and it currently looks like this:
# cat /etc/systemd/system/bridge.service
[Unit]
Description=network bridge for KVM
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/network_systemd
ExecStart=/sbin/brctl addbr ${bridge_name}
ExecStart=/usr/bin/tunctl -b -u ${user} -t ${tap_name}
ExecStart=/bin/ifconfig ${bridge_name} ${address} netmask ${netmask} up
ExecStart=/bin/ifconfig ${interface} up
ExecStart=/bin/ifconfig ${tap_name} up 0.0.0.0 promisc
ExecStart=/sbin/brctl addif ${bridge_name} ${tap_name} ${interface}
ExecStart=/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=1
ExecStart=iptables -t nat -A POSTROUTING -o ${interface} -j MASQUERADE
ExecStart=/bin/ip route add default via ${gateway}
ExecStop=/bin/ip route del default via ${gateway}
ExecStop=/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=0
ExecStop=/bin/ifconfig ${tap_name} down
ExecStop=/sbin/brctl delif ${bridge_name} ${tap_name}
ExecStop=/usr/bin/tunctl -d ${tap_name}
ExecStop=/bin/ifconfig ${bridge_name} down
ExecStop=/bin/ifconfig ${interface} down
ExecStop=/sbin/brctl delbr ${bridge_name}
ExecStop=iptables -t nat -D POSTROUTING -o ${interface} -j MASQUERADE
[Install]
WantedBy=multi-user.target
--
I disabled network.service and enabled bridge.service, works fine so
far, I already tested connectivity from KVM-VMs.
I am sure that this quite fresh and bloody, suggestions welcome as
always ...
If it works, it works. It just looks... wrong :D
If you really need so much commands from your unit, you can use a script:
$ cat /usr/local/bin/kvm-brigdge
#!/bin/sh
source /etc/conf.d/network_systemd
case ${1} in
start)
/sbin/brctl addbr ${bridge_name}
/usr/bin/tunctl -b -u ${user} -t ${tap_name}
/bin/ifconfig ${bridge_name} ${address} netmask ${netmask} up
/bin/ifconfig ${interface} up
/bin/ifconfig ${tap_name} up 0.0.0.0 promisc
/sbin/brctl addif ${bridge_name} ${tap_name} ${interface}
/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=1
iptables -t nat -A POSTROUTING -o ${interface} -j MASQUERADE
/bin/ip route add default via ${gateway}
;;
stop)
/bin/ip route del default via ${gateway}
/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=0
/bin/ifconfig ${tap_name} down
/sbin/brctl delif ${bridge_name} ${tap_name}
/usr/bin/tunctl -d ${tap_name}
/bin/ifconfig ${bridge_name} down
/bin/ifconfig ${interface} down
/sbin/brctl delbr ${bridge_name}
iptables -t nat -D POSTROUTING -o ${interface} -j MASQUERADE
;;
esac
$ cat /etc/systemd/system/kvm-bridge.service
[Unit]
Description=network bridge for KVM
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/kvm-brigdge start
ExecStop=/usr/local/bin/kvm-brigdge stop
[Install]
WantedBy=multi-user.target
As I have been saying all this years: that systemd can work without
using scripts, doesn't mean that it isn't able to use them. I use a
couple of them myself; I think this is a perfect example of one. Your
unit file then it's small and simple, as all of them should be.
Remember that /usr/local/bin/kvm-brigdge needs to be executable.
I'll note that in your version, you're ignoring the exit statuses of
each of those commands. From a correctness standpoint, I prefer
Stefan's version.
--
:wq
Re: [gentoo-user] net-mail/mailbase-1.1 and access rights of /var/spool/mail
On Tue, 29 Jan 2013 16:36:06 + Mick michaelkintz...@gmail.com wrote: On Tuesday 29 Jan 2013 10:19:16 Alan McKinnon wrote: On Tue, 29 Jan 2013 06:37:47 + Mick michaelkintz...@gmail.com wrote: Hi All, I got this message when net-mail/mailbase-1.1 was emerged: * Messages for package net-mail/mailbase-1.1: * Your //var/spool/mail/ directory permissions differ from * those which mailbase wants to set it to (03775). * If you did not change them on purpose, consider running: * * chown root:mail //var/spool/mail/ * chmod 03775 //var/spool/mail/ Running this chmod changed access rights from: drwxrwxr-x 2 root mail 4096 Jan 28 19:57 mail to a sticky-fied: drwxrwsr-t 2 root mail 4096 Jan 28 19:57 mail Any idea why are the sticky bits for group and others required? sticky for group so that all sub-dirs and files in them are owned by the mail group. Without it, they would be owned by the user running mailx and the mail system can no longer manager them. sticky for others is so that you can't delete my mail but you can still create your own mail spool files. Identical logic to /tmp (assuming that you are in the mail group) Thanks Alan, it makes sense now. No one other than mail are in the mail group in this box (my laptop): $ less /etc/group | grep mail mail:x:12:mail I have rkhunter and some cron jobs using ssmtp to email me log info, but they have been running as root. That's why I hadn't experienced a problem with the previous access rights. I wonder why this was picked up in the 1.1 version and not previously - perhaps a test was added on purpose in the ebuild. There's relevant info and bug numbers in the mailbase Changelog: *mailbase-1.1 (12 Oct 2012) 12 Oct 2012; Eray Aslan e...@gentoo.org +mailbase-1.1.ebuild: Make /var/spool/mail/ directory setgid and sticky - bugs #424431 #426962 #438062 and various others -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
Am 29.01.2013 20:05, schrieb Michael Mol: I'll note that in your version, you're ignoring the exit statuses of each of those commands. From a correctness standpoint, I prefer Stefan's version. Thanks ;-) Also thanks to Canek for the script-version ... I knew that way but wanted to fully take advantage from the step-by-step approach my version gives me. When I debugged my way up to the current draft it was helpful to see which line/command failed etc. btw I had to add absolute paths to the iptables-commands ... - Got libvirt(d) and libvirt-guests running as well (useful with QEMU/KVM). - Right now I am testing service- and socket-files for amanda-backup-client ... The issue with using gdm is still unsolved, but doesn't matter that much right now. Stefan
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
On Tue, Jan 29, 2013 at 1:05 PM, Michael Mol mike...@gmail.com wrote:
On Tue, Jan 29, 2013 at 1:57 PM, Canek Peláez Valdés can...@gmail.com wrote:
On Tue, Jan 29, 2013 at 10:32 AM, Stefan G. Weichinger li...@xunil.at
wrote:
Am 28.01.2013 22:49, schrieb Stefan G. Weichinger:
ps: my bigger hurdle will be the bridging-setup for running
KVM-virtualization. This was one of the reasons to go back to openrc
back then.
I have no experience with that, but if it works in OpenRC it should
work in systemd. Probably better, even.
I don't think it won't work, I just wonder how to do it in the right and
most efficient way. I will think about that later/tomorrow maybe,
already late here ...
I have a *draft* here for bridge.service ... I used the init.d-script
from here as a template:
http://en.gentoo-wiki.com/wiki/KVM#Script_to_ease_the_configuration
(I used a variation of that as /etc/init.d/kvm for long now)
My service-file reads variables from a separated configfile:
# cat /etc/conf.d/network_systemd
interface=eth0
address=172.32.99.12
netmask=255.255.255.0
broadcast=172.32.99.255
gateway=172.32.99.250
bridge_name=br0
tap_name=qtap0
user=sgw
and it currently looks like this:
# cat /etc/systemd/system/bridge.service
[Unit]
Description=network bridge for KVM
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/network_systemd
ExecStart=/sbin/brctl addbr ${bridge_name}
ExecStart=/usr/bin/tunctl -b -u ${user} -t ${tap_name}
ExecStart=/bin/ifconfig ${bridge_name} ${address} netmask ${netmask} up
ExecStart=/bin/ifconfig ${interface} up
ExecStart=/bin/ifconfig ${tap_name} up 0.0.0.0 promisc
ExecStart=/sbin/brctl addif ${bridge_name} ${tap_name} ${interface}
ExecStart=/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=1
ExecStart=iptables -t nat -A POSTROUTING -o ${interface} -j MASQUERADE
ExecStart=/bin/ip route add default via ${gateway}
ExecStop=/bin/ip route del default via ${gateway}
ExecStop=/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=0
ExecStop=/bin/ifconfig ${tap_name} down
ExecStop=/sbin/brctl delif ${bridge_name} ${tap_name}
ExecStop=/usr/bin/tunctl -d ${tap_name}
ExecStop=/bin/ifconfig ${bridge_name} down
ExecStop=/bin/ifconfig ${interface} down
ExecStop=/sbin/brctl delbr ${bridge_name}
ExecStop=iptables -t nat -D POSTROUTING -o ${interface} -j MASQUERADE
[Install]
WantedBy=multi-user.target
--
I disabled network.service and enabled bridge.service, works fine so
far, I already tested connectivity from KVM-VMs.
I am sure that this quite fresh and bloody, suggestions welcome as
always ...
If it works, it works. It just looks... wrong :D
If you really need so much commands from your unit, you can use a script:
$ cat /usr/local/bin/kvm-brigdge
#!/bin/sh
source /etc/conf.d/network_systemd
case ${1} in
start)
/sbin/brctl addbr ${bridge_name}
/usr/bin/tunctl -b -u ${user} -t ${tap_name}
/bin/ifconfig ${bridge_name} ${address} netmask ${netmask} up
/bin/ifconfig ${interface} up
/bin/ifconfig ${tap_name} up 0.0.0.0 promisc
/sbin/brctl addif ${bridge_name} ${tap_name} ${interface}
/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=1
iptables -t nat -A POSTROUTING -o ${interface} -j MASQUERADE
/bin/ip route add default via ${gateway}
;;
stop)
/bin/ip route del default via ${gateway}
/sbin/sysctl net.ipv4.conf.${bridge_name}.forwarding=0
/bin/ifconfig ${tap_name} down
/sbin/brctl delif ${bridge_name} ${tap_name}
/usr/bin/tunctl -d ${tap_name}
/bin/ifconfig ${bridge_name} down
/bin/ifconfig ${interface} down
/sbin/brctl delbr ${bridge_name}
iptables -t nat -D POSTROUTING -o ${interface} -j MASQUERADE
;;
esac
$ cat /etc/systemd/system/kvm-bridge.service
[Unit]
Description=network bridge for KVM
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/kvm-brigdge start
ExecStop=/usr/local/bin/kvm-brigdge stop
[Install]
WantedBy=multi-user.target
As I have been saying all this years: that systemd can work without
using scripts, doesn't mean that it isn't able to use them. I use a
couple of them myself; I think this is a perfect example of one. Your
unit file then it's small and simple, as all of them should be.
Remember that /usr/local/bin/kvm-brigdge needs to be executable.
I'll note that in your version, you're ignoring the exit statuses of
each of those commands. From a correctness standpoint, I prefer
Stefan's version.
I really believe the most important thing abount systemd unit files is
that they are small and simple. You can also check the exit status
from each command in the script,
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
Am 29.01.2013 20:23, schrieb Canek Peláez Valdés: I really believe the most important thing abount systemd unit files is that they are small and simple. You can also check the exit status from each command in the script, or even better, you can do a test after all the commands are done to check the status of the bridge and see if it was created correctly. None of this belongs in the unit service, IMO. Otherwise, you end creating ssh keys and user groups in unit files, and none of this belongs there. Clear separation between the services and the init system. But of course, as I said to Stefan, if it works it works. As I mentioned it is a first version ... just to make things work. If all the services/daemons/stuff work with systemd then I am able to use it as default init-system here and I don't have switch back to openrc to do my work (for example when I need KVM-based virtualization on my workstation). I agree with your argument that unitfiles should be as small and simple as possible, on the other hand those commands just get pulled in from elsewhere: the complexity is just moved out of sight, right? I did quite some research to find more elegant solutions ... so far I wasn't successful. For now I am happy to get my itches scratched ... I am absolutely ready to learn and improve things. Sharing my first steps here maybe helps to motivate other gentoo-users to give systemd a try? Regards, Stefan
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
On Tue, Jan 29, 2013 at 1:22 PM, Stefan G. Weichinger li...@xunil.at wrote: Am 29.01.2013 20:05, schrieb Michael Mol: I'll note that in your version, you're ignoring the exit statuses of each of those commands. From a correctness standpoint, I prefer Stefan's version. Thanks ;-) Also thanks to Canek for the script-version ... I knew that way but wanted to fully take advantage from the step-by-step approach my version gives me. When I debugged my way up to the current draft it was helpful to see which line/command failed etc. That's my point; you don't need (and I would venture to say, you don't want) to debug this kind of stuff within systemd; you create your script, and you run it from the command line: $ /usr/local/bin/kvm-bridge start And see what is missing or what is failing; you debug it from here. When you have a working script, you just put it in a simple, concise systemd unit file, and everything should work (sans stuff like needing to put absolute paths for the executables, which BTW is easily solvable by putting PATH=/sbin:/usr/sbin in your /etc/conf.d/network_systemd file). But, for the last time: if it works, it works. I just think that's not the philosophy behind systemd; the idea is to find the proper solution. Using ExecStart= commands to debug when a service fails is as bad as putting echo statements in SysV/OpenRC scripts to see what is failing, IMO. Don't use the bad practices from SysV/OpenRC in systemd, I'm just saying. Just my opinion. But great to know is working. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
Am 29.01.2013 20:33, schrieb Canek Peláez Valdés: On Tue, Jan 29, 2013 at 1:22 PM, Stefan G. Weichinger li...@xunil.at wrote: When I debugged my way up to the current draft it was helpful to see which line/command failed etc. That's my point; you don't need (and I would venture to say, you don't want) to debug this kind of stuff within systemd; you create your script, and you run it from the command line: $ /usr/local/bin/kvm-bridge start And see what is missing or what is failing; you debug it from here. Ok, I understand your approach. When you have a working script, you just put it in a simple, concise systemd unit file, and everything should work (sans stuff like needing to put absolute paths for the executables, which BTW is easily solvable by putting PATH=/sbin:/usr/sbin in your /etc/conf.d/network_systemd file). Yep, thanks. But, for the last time: if it works, it works. I just think that's not the philosophy behind systemd; the idea is to find the proper solution. Using ExecStart= commands to debug when a service fails is as bad as putting echo statements in SysV/OpenRC scripts to see what is failing, IMO. Don't use the bad practices from SysV/OpenRC in systemd, I'm just saying. Just my opinion. But great to know is working. Thanks for sharing ... I quickly followed your suggestions and built another service-file with your solution (you had typos btw - brigdge ;-) ). It works as well and is maybe even slimmer in execution. I will just keep both versions around and see where it gets me. Thanks, Stefan
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
On Tue, Jan 29, 2013 at 1:33 PM, Stefan G. Weichinger li...@xunil.at wrote: Am 29.01.2013 20:23, schrieb Canek Peláez Valdés: I really believe the most important thing abount systemd unit files is that they are small and simple. You can also check the exit status from each command in the script, or even better, you can do a test after all the commands are done to check the status of the bridge and see if it was created correctly. None of this belongs in the unit service, IMO. Otherwise, you end creating ssh keys and user groups in unit files, and none of this belongs there. Clear separation between the services and the init system. But of course, as I said to Stefan, if it works it works. As I mentioned it is a first version ... just to make things work. If all the services/daemons/stuff work with systemd then I am able to use it as default init-system here and I don't have switch back to openrc to do my work (for example when I need KVM-based virtualization on my workstation). I agree with your argument that unitfiles should be as small and simple as possible, on the other hand those commands just get pulled in from elsewhere: the complexity is just moved out of sight, right? I don't think so, no. It's like the Model/View/Controller design pattern: The code does the same (sometimes it even grows in complexity), so we are just moving stuff around, right? No, we are clearly splitting the information we have, and how do we present it to the user, with a set of well defined interfaces in the control module on how to update the second using the first. Or with a webapp; we can mix the information with the presentation, why to split them? We are just moving it out of sight, right? No, again, we split the information on a web page from how do we present it to the user, so when something breaks, we know where it did. Imagine that systemd had a bug in its ExecStart= directive. Perhaps it works for the first 5 commands, but it fails in the 6th. Then you would have been stuck for hours (perhaps days) trying to debug your unit file, when it had nothing wrong, really. If instead you put all the logic pertaining to your service in a script, or executable, or whatever, but *clearly separated* from systemd, and you got it working, and it doesn't work with systemd, then you *know* where the problem is. I really believe the proper solution is to clearly separate this stuff. You can abuse the Type=oneshot unit files, or heck, even put everything in a single ExecStart=( command1; command2; command3; ...; commandN). That doesn't mean you should. Just my 0.02 cents. I did quite some research to find more elegant solutions ... so far I wasn't successful. I find more elegant to clearly split the commands your service uses from the unit file. For now I am happy to get my itches scratched ... I am absolutely ready to learn and improve things. Sharing my first steps here maybe helps to motivate other gentoo-users to give systemd a try? I would not bet on that ;) too much resistance. However it is certainly getting better and better: the LWN article on The Biggest Myths about systemd had an overwhelmingly majority of comments positive to systemd, and just a handful of negative comments: http://lwn.net/Articles/534210/#Comments But that is in LWN; Gentoo is way behind, I believe. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
On Tue, Jan 29, 2013 at 9:49 PM, Canek Peláez Valdés can...@gmail.com wrote: I would not bet on that ;) too much resistance. However it is certainly getting better and better: the LWN article on The Biggest Myths about systemd had an overwhelmingly majority of comments positive to systemd, and just a handful of negative comments: http://lwn.net/Articles/534210/#Comments But that is in LWN; Gentoo is way behind, I believe. Gentoo is not behind, it provides you the option of using systemd. However openrc is superior in many ways, as unlike systemd it provides script base metadata vs static systemd units, so for example a service can depend on other services based on LOGIC. Also, it has the nature of virtual dependencies what systemd lacks, for example there are N services that provides timesync, in openrc you provide timesync and depend on timesync, in systemd there is no way to do so. openrc is working in various environments including embedded, while systemd requires so much dependencies that it is not really usable at all environments. openrc can be used correctly in chroot environment, while systemd is inoperative. openrc supports extra commands for services, while systemd enforces only start/stop sequence. I can go on an on. Just because there is hype of some branding, does not mean it is better. openrc networking is the best network configuration I ever used, and I used a lot of distributions. I used the following[1][2][3][4] configuration on my environment. Regards, Alon [1] http://en.gentoo-wiki.com/wiki/VM_Tap_Networking [2] http://en.gentoo-wiki.com/wiki/Stealth_DHCP [3] http://en.gentoo-wiki.com/wiki/Firewall_Using_Firehol [4] http://en.gentoo-wiki.com/wiki/OpenVPN_Non_Root
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
On Tue, Jan 29, 2013 at 2:00 PM, Alon Bar-Lev alo...@gentoo.org wrote: On Tue, Jan 29, 2013 at 9:49 PM, Canek Peláez Valdés can...@gmail.com wrote: I would not bet on that ;) too much resistance. However it is certainly getting better and better: the LWN article on The Biggest Myths about systemd had an overwhelmingly majority of comments positive to systemd, and just a handful of negative comments: http://lwn.net/Articles/534210/#Comments But that is in LWN; Gentoo is way behind, I believe. Gentoo is not behind, it provides you the option of using systemd. However openrc is superior in many ways, as unlike systemd it provides script base metadata vs static systemd units, so for example a service can depend on other services based on LOGIC. Also, it has the nature of virtual dependencies what systemd lacks, for example there are N services that provides timesync, in openrc you provide timesync and depend on timesync, in systemd there is no way to do so. I really should not enter into this discussion (again), and even less with a Gentoo dev (BTW, thanks for all the great work). However, this: for example there are N services that provides timesync, in openrc you provide timesync and depend on timesync, in systemd there is no way to do so it's just a lie (or missinformation). display-manager.service and syslog.service work like this; they are soft links to the desired service (gdm.service and syslog.service, for example), and other units depend on them. They work like virtuals in Gentoo. openrc is working in various environments including embedded, while systemd requires so much dependencies that it is not really usable at all environments. I don't know about all environments, but ProFUSION [1] works in embedded systems and several of its developers are systemd upstream. Also GENIVI, the standardized common software platform for developing in-vehicle infotainment (IVI), uses systemd. openrc can be used correctly in chroot environment, while systemd is inoperative. I know it's not exactly the same, but with systemd we have systemd-nspawn, which I (IMHO) consider far superior: man 1 systemd-nspawn. openrc supports extra commands for services, while systemd enforces only start/stop sequence. I can go on an on. Yeah, OpenRC needs zap, because sometimes a daemon ends unexpectedly, and OpenRC is unable to detect it. I would not call this an advantage, though. Just because there is hype of some branding, does not mean it is better. I believe it's better, but it's only my opinion; it's certainly better for my use-cases. I don't want to impose systemd on anyone, but I would be really happy if I could *easily* uninstall OpenRC from Gentoo, since I don't use it. I'm using an ovelay [2] right now, but is far from optimal. And, BTW, I didn't mean behind in the sense that Gentoo doesn't support systemd; I meant behind in the sense that us systemd users get a lot flak just by mention it in the list. [1] http://www.profusion.mobi/ [2] https://github.com/canek-pelaez/gentoo-systemd-only Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
And, BTW, I didn't mean behind in the sense that Gentoo doesn't support systemd; I meant behind in the sense that us systemd users get a lot flak just by mention it in the list. And that's exactly why I see Gentoo as being ahead and actually your talking about a few of the IMO more moronic distributions. The majority have rejected systemd but lets just agree to disagree before we start talking about API'sSNIP... and Startup scripts being GENERIC and easy to understand and very different to controller code. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-user] ebtables on Gentoo?
So anyway, my memory of this is all very wishy-washy, but ebtables turned out to be the best way to implement those inter-VM restrictions. It could probably have been done in iptables, but ebtables made it easy to say don't let these two talk. I don;t know the details but I expect that would be a false sense of security and that you would want a secure switch or ssh or ipsec. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)
On Tue, Jan 29, 2013 at 3:10 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: [...] but lets just agree to disagree [...] Agreed. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] ebtables on Gentoo?
On 30/01/13 05:14, Kevin Chadwick wrote: So anyway, my memory of this is all very wishy-washy, but ebtables turned out to be the best way to implement those inter-VM restrictions. It could probably have been done in iptables, but ebtables made it easy to say don't let these two talk. I don;t know the details but I expect that would be a false sense of security and that you would want a secure switch or ssh or ipsec. Put each vm into its own private vlan and use a firewall on the host to control traffic between them ... seems a better way to go! BillK
[gentoo-user] 'su' stopped working : reminder needed
A few weeks ago, there was a brief thread re a change in a pkg which stopped 'su' from working. It didn't affect my desktop system, so I didn't pay much attention, but it's just hit my netbook. Can anyone remind me what I need to do to restore it ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] fcron
hey.. I wonder about the last update of fcron.It is an update to 3.1.1, there is a new /etc/crontab file, which is mixed with /etc/fcronfcrontab, without update notice. The latest stable version is 3.0.6 on the fcron homepage. bye, jens.
Re: [gentoo-user] 'su' stopped working : reminder needed
On Wednesday 30 January 2013 07:46:48 AM IST, Philip Webb wrote: A few weeks ago, there was a brief thread re a change in a pkg which stopped 'su' from working. It didn't affect my desktop system, so I didn't pay much attention, but it's just hit my netbook. Can anyone remind me what I need to do to restore it ? You probably updated your system after a long time and forgot to run etc-update. There was a major PAM update recently (I guess more than 1.5 months) which required changes in /etc/pam.d. -- Nilesh Govindarajan http://nileshgr.com
Re: [gentoo-user] nvidia-drivers-304.64 build failure against vanilla linux-3.7.4
On 01/27/2013 01:06 AM, staticsafe wrote: I just grabbed vanilla 3.7.4 from kernel.org, the kernel build itself went fine but when I did a modules-rebuild, the nvidia module failed to build. As requested by the error message: I had the same problem, I had success with this: https://devtalk.nvidia.com/default/topic/525699/linux/nvidia-linux-3-7-patch-fix/ I applied the patch and also had to create the link to version.h as suggested towards the end of the page. That was with gentoo-sources-3.7.4-something and nvidia-drivers-304.64 on ~amd64. raf
