For one thing if I have a process bound to an IP and NM stops that interface due to a transient issue with the network such as a switch rebooting or some one accidentally unplugging the wrong cable in the patch panel for a split second. The problem is it brings the interfaces down when link is lost. However the file handle for the network socket stays in a "DELETED" state until the the service is restarted or the service detects an issue with the socket because the programmer was better than average and though about the scenario. Now the link comes back but the socket is still broken because it still points to the deleted file handle for the old link so it spears although my service is working but in reality it can't hear new connections coming in. By the way this scenario doesn't apply to things bound to the default 0.0.0.0.
Also the fact that I saw it decide on its own to bridge several interfaces together last week on a CentOS 6.4 box because a consultant made a mistake I just don't trust it.
In fact I've been thinking I just may scrap it all the redhat network tools and write a ground up replacement for the firewall tools I'm writing right now (yes the will be released under the GPL when they are ready).
I'm thinking thinking I'll do something similar to what I did with Fedora 4 back in the day when I worked for a network secuity appliance company with an XML based config for the network interfaces. But I think I can get away with a simple set if small scripts that mostly just do XSLT transforms to create the appropriate commands for iproute2 this would mean that adding or modifying features would simply be a matter of updating a DTD or schema and the XSLT file. Also I'm thinking of possibly integrating iptables and ipset into it as well. Since I already have successfully compiled and tested ipset on RHEL 6.x and already have the tools and sysV init scripts written for them based on a slightly modified (I added to it but didn't change any thing already in it) version of the XML dumped by the ipset command.
-- Sent from my HP Pre3
On Aug 18, 2013 12:42, Tom H <tomh0...@gmail.com> wrote:
On Mon, Aug 12, 2013 at 10:24 AM, Paul Robert Marino
<prmari...@gmail.com> wrote:
> On Wed, Jul 31, 2013 at 10:21 PM, zxq9 <z...@zxq9.com> wrote:
>> On 07/31/2013 11:57 PM, Tom H wrote:
>>> On Tue, Jul 30, 2013 at 5:12 PM, zxq9<z...@zxq9.com> wrote:
>>>> On 07/30/2013 10:26 PM, Tom H wrote:
>>>
>>> I was only commenting on the more complex and unreadable spec files.
>>> Otherwise I'm happy about systemd and journald. In short, the kernel
>>> has evolved, the applications have evolved, why not the init system?
>>
>> Its not that the init system can't do with some modernization, its that the
>> new system has a severe case of featuritis that is spawning little eddies of
>> nonlocalized complexity all over the place. Modernizing a system and tossing
>> everything that's come before in the interest of a deliberately incompatible
>> rewrite are different things. Remember HAL?
>
> well thats mostly due to the fact that its new and far more complex.
> there was a mad rush for every one to rewrite there statup scripts and
> quite a few of them weren't done very well and others weren't fully
> thought out.
>
> what I find worse is they did a ground up rewrite and didn't touch the
> network configuration portion wasn't rewritten.
>
> The network scripts are limited and problematic if you want to do any
> thing advanced. for example its a long story why but on one device a
> bridge I have to add a static arp entry. iproute2 has been able to do
> this for as long as i can remember but there was no clean way to get
> it to work was to hack the network scripts in order to add the
> functionality.
>
> Really the scripts network scripts need to have hooks added so user
> defined scripts can be called at various points of the startup and
> shutdown of an interface. but more than that they mostly date back to
> the 2.0 Kernel and Linux's Network capabilities have change
> significantly since then but for the most part these scripts keep
> people stuck in the 90's.
(Couldn't you top-post like everyone else?)
There's been more than one hint on fedora-devel that the reason that
the "/etc/sysconfig/network-scripts/<scripts>" haven't been adapted to
systemd is that no one wants to do the (large amount of) work that
would be required when the eventual goal is to default to NM and only
use NM; and that that goal's ever closer. (As a Fedora user, I
sometimes wish that TUV weren't so involved with GNOME and NM and that
netctl were packaged for Fedora - and in the future for EL-7 - because
it's integrated into systemd; but NM's slowly getting there for
servers.)
EL-6.4's network scripts mostly use iproute (although I don't think
that you can use "PREFIX=24" instead of "NETMASK=255.255.255.0" as you
can on Fedora).
The following command returns nothing on F-19, but on EL-6.4:
[root@sci6:/etc/sysconfig/network-scripts]# grep ifconfig *
ifup-ippp: /usr/bin/logger -p daemon.info -t ifup-ippp "ifconfig
$DEVICE $IPADDR pointopoint $GATEWAY $netmask up"
ifup-ippp: ifconfig $DEVICE $IPADDR pointopoint $GATEWAY $netmask
up >/dev/null 2>&1
ifup-isdn: /usr/bin/logger -p daemon.info -t ifup-ippp "ifconfig
$DEVICE $IPADDR pointopoint $GATEWAY $netmask up"
ifup-isdn: ifconfig $DEVICE $IPADDR pointopoint $GATEWAY $netmask
up >/dev/null 2>&1
ifup-plip:ifconfig ${DEVICE} ${IPADDR} pointopoint ${REMIP}
ifup-plusb: ifconfig ${DEVICE} ${IPADDR} pointopoint ${REMIP}
netmask ${NETMASK}
ifup-plusb: ifconfig ${DEVICE} ${IPADDR} pointopoint ${REMIP}
netmask ${NETMASK}
[root@sci6:/etc/sysconfig/network-scripts]#
