Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Paul Robert Marino]

Here is a sample of what I've been thinking about as a cluster (as in
multiple boxes in one file) network configuration file. Its no where
near done, I know it needs a little more work on the configuration of
bridges among other types of interfaces, and the scripts to use it
haven't been written yet but it should give any one intrested a good
idea of where I'm thinking of going with it. also I forgot to mention
I was thinking of also adding some optional basic configurations for
quagga to add OSPF and BGP support, and eventually user definable
hooks to execute scripts before and after key actions.






32393735-3733-5355-4531-30374E36445A
firewall01.example.net

192.168.1.2/24

1300

br0


bond0

10.150.99.0/24
192.168.1.8



5
default

loadbalanced





192.168.1.5

1


192.168.1.6
5




192.168.2.2/24
1301

br1




TRUE
br0
FALSE

FALSE



TRUE
br1



FALSE


TRUE
1
0
1
2


bond0
1301

4
1




192.168.1.5
br0
a1:2d:3a:f0:1f:9c
permanent



bond0
eth0
eth1

TRUE
1

bond0





loadbalanced

100




5FEAA22F-7674-2539-9D99-3A7158BCC973
firewall02.example.net

TRUE
br1


FALSE


TRUE
1
0
1
2


bond0
1301

4

2





bond0
eth0
eth1

TRUE
1

bond0





loadbalanced

100







On Sun, Aug 18, 2013 at 1:53 PM, Paul Robert Marino  wrote:
> I totally disagree I love NM on my laptop but its a pox upon my servers. It
> causes far more problems for servers than it fixes.
> 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 beca

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Robert Arkiletian]

On Sun, Aug 18, 2013 at 4:44 PM, Paul Robert Marino  wrote:
> I somewhat agree however I still think systemd needs an other year or two to
> bake before its enterprise ready.
>
> 1) the scripts are still too new and most of them haven't been thoroughly
> thought out yet. There are a lot of things that change when you switch from
> simple start and stop scripts to using an active process manager which take
> time for the developers and system administrators to wrap their heads
> around. Frankly they haven't had enough time to do it well and I will have
> issues all over the place with 3rd party applications when RHEL 7 is
> released because of it.
>
> 2) systemd isn't the first of its kind on Linux in fact Gentoo Linux has
> been doing something similar for years with its startup scripts.
>
> 3) in many ways the design of systemd is very desktop centric which is great
> for a desktop or laptop but horrible in an enterprise. Frankly I'm horrified

+1 and I don't care if my servers take a few seconds longer to boot.
Also, one of the first things I do when configuring a server is remove
NM. When running Fedora 19 the new gnome is also too foreign to me. I
much prefer xfce instead. I wish they had made that the default for
rhel7. The trend towards binary log files is also a little
uncomfortable. I'm so used to using simple tools to parse log files.

> by the idea that if a inexperienced sysadmin does a default install instead
> of our standard nobase install that someone my come along and stick a WiFi
> dongle in a box and create a loop or security hole because it was
> immediately detected and the services to auto configure it were
> automatically started without a authorized sysadmins intervention. By the
> way that is a scenario that I've seen users attempt before because they
> needed access from their desktop and didn't want to wait for or were just
> too lazy to request a firewall change. For that matter I had a consultant
> just this past week accidentally create a loop on my network because he had
> made a mistake in the network configuration and NetworkManager decided to
> bridge several interfaces ( I never thought I'd hear my self say this but
> thank god for spanning tree). So auto starting and restarting services based
> on things like hardware event are scary to me for good reasons. Additionally
> if I have a service that occasionally crashes due to a bug or
> misconfiguration but systems keeps relaunching it I may never know I have a
> problem I'd rather the process crash and get a one time complaint or trouble
> ticket from the user and fix it than have users grumbling how my systems
> suck because they keep having problems but the guy in the NOC sees all green
> on his screen when the user calls and keeps dismissing their complaints
> without further investigation.
>
>
> -- Sent from my HP Pre3
>
> 
> On Aug 18, 2013 9:29, Tom H  wrote:
>
> On Tue, Aug 13, 2013 at 12:30 AM, zxq9  wrote:
>
>
>> * The old init system was complicated (in that the defaults aren't
>> uniform).
>> Familiarity with the system triumphed over lack of clear implementation
>> and
>> lack of documentation.
>
> All Linux users and developers were victims of laziness and inertia
> when we stuck with the mess that sysvinit scripts are for as long as
> we did, especially after Solaris and OS X showed the way with SMF and
> launchd. We should've at least moved to declarative init files with
> one bash/dash/sh script to start and stop daemons; we didn't and we've
> fortunately gone beyond that with systemd.
>
>
>> * systemd is a huge effort that isn't doing anything to remedy the
>> situation.
>
> One or two years after the release of EL-7, everyone'll wonder what
> all the anti-systemd fuss was about...

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Paul Robert Marino]

I totally disagree I love NM on my laptop but its a pox upon my servers. It causes far more problems for servers than it fixes.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 Pre3On Aug 18, 2013 12:42, Tom H  wrote: On Mon, Aug 12, 2013 at 10:24 AM, Paul Robert Marino
 wrote:
> On Wed, Jul 31, 2013 at 10:21 PM, zxq9  wrote:
>> On 07/31/2013 11:57 PM, Tom H wrote:
>>> On Tue, Jul 30, 2013 at 5:12 PM, zxq9  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/" 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

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Paul Robert Marino]

I somewhat agree however I still think systemd needs an other year or two to bake before its enterprise ready.1) the scripts are still too new and most of them haven't been thoroughly thought out yet. There are a lot of things that change when you switch from simple start and stop scripts to using an active process manager which take time for the developers and system administrators to wrap their heads around. Frankly they haven't had enough time to do it well and I will have issues all over the place with 3rd party applications when RHEL 7 is released because of it.2) systemd isn't the first of its kind on Linux in fact Gentoo Linux has been doing something similar for years with its startup scripts.3) in many ways the design of systemd is very desktop centric which is great for a desktop or laptop but horrible in an enterprise. Frankly I'm horrified by the idea that if a inexperienced sysadmin does a default install instead of our standard nobase install that someone my come along and stick a WiFi dongle in a box and create a loop or security hole because it was immediately detected and the services to auto configure it were automatically started without a authorized sysadmins intervention. By the way that is a scenario that I've seen users attempt before because they needed access from their desktop and didn't want to wait for or were just too lazy to request a firewall change. For that matter I had a consultant just this past week accidentally create a loop on my network because he had made a mistake in the network configuration and NetworkManager decided to bridge several interfaces ( I never thought I'd hear my self say this but thank god for spanning tree). So auto starting and restarting services based on things like hardware event are scary to me for good reasons. Additionally if I have a service that occasionally crashes due to a bug or misconfiguration but systems keeps relaunching it I may never know I have a problem I'd rather the process crash and get a one time complaint or trouble ticket from the user and fix it than have users grumbling how my systems suck because they keep having problems but the guy in the NOC sees all green on his screen when the user calls and keeps dismissing their complaints without further investigation.-- Sent from my HP Pre3On Aug 18, 2013 9:29, Tom H  wrote: On Tue, Aug 13, 2013 at 12:30 AM, zxq9  wrote:


> * The old init system was complicated (in that the defaults aren't uniform).
> Familiarity with the system triumphed over lack of clear implementation and
> lack of documentation.

All Linux users and developers were victims of laziness and inertia
when we stuck with the mess that sysvinit scripts are for as long as
we did, especially after Solaris and OS X showed the way with SMF and
launchd. We should've at least moved to declarative init files with
one bash/dash/sh script to start and stop daemons; we didn't and we've
fortunately gone beyond that with systemd.


> * systemd is a huge effort that isn't doing anything to remedy the
> situation.

One or two years after the release of EL-7, everyone'll wonder what
all the anti-systemd fuss was about...

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Tom H]

On Mon, Aug 12, 2013 at 10:24 AM, Paul Robert Marino
 wrote:
> On Wed, Jul 31, 2013 at 10:21 PM, zxq9  wrote:
>> On 07/31/2013 11:57 PM, Tom H wrote:
>>> On Tue, Jul 30, 2013 at 5:12 PM, zxq9  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/" 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]#

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Nico Kadel-Garcia]

I'm afraid that the wholesale switch to systemd is going to leave a lot of
blood on the pavement, especially for EPEL and Repoforge. I'm looking at it
right now for Subversion based daemons and some Java based daemons, poking
around in Fedora 19 for backporting to SL 6, and I'm wincing a lot. I'm
afraid that it's going to cause a lot of environments to be very reluctant
to upgrade from SL 5 to *any* more recent operating systems.

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[zxq9]

On 08/18/2013 10:29 PM, Tom H wrote:

On Tue, Aug 13, 2013 at 12:30 AM, zxq9  wrote:



* The old init system was complicated (in that the defaults aren't uniform).
Familiarity with the system triumphed over lack of clear implementation and
lack of documentation.


All Linux users and developers were victims of laziness and inertia
when we stuck with the mess that sysvinit scripts are for as long as
we did, especially after Solaris and OS X showed the way with SMF and
launchd. We should've at least moved to declarative init files with
one bash/dash/sh script to start and stop daemons; we didn't and we've
fortunately gone beyond that with systemd.



* systemd is a huge effort that isn't doing anything to remedy the
situation.


One or two years after the release of EL-7, everyone'll wonder what
all the anti-systemd fuss was about...


It will be ditched for the precisely the same reasons HAL has been and 
similarly replaced by a system that recognizes where its design mandate 
beginds and ends. What we'll be wondering was perhaps not what all the 
anti-systemd fuss was about, but what all the "keep sysv-style init 
forever" fuss was all about and why the response was yet another HAL 
mistake. Being anti-systemd is not the same thing as being purely 
pro-sysv init.


Immature missteps are a sign of an immature community. I think its 
obvious that as a culture we've inherited a lot of new blood we have not 
yet learned how to metabolize. Unmanaged company politics exacerbate 
this, of course. Sort of like how they did when UNIX went through its 
pains in the 80's -- an era where the incompatible actions of agitating 
for "diversification" while wielding new standards as anticompetitive 
weapons was the norm.

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Tom H]

On Tue, Aug 13, 2013 at 12:30 AM, zxq9  wrote:


> * The old init system was complicated (in that the defaults aren't uniform).
> Familiarity with the system triumphed over lack of clear implementation and
> lack of documentation.

All Linux users and developers were victims of laziness and inertia
when we stuck with the mess that sysvinit scripts are for as long as
we did, especially after Solaris and OS X showed the way with SMF and
launchd. We should've at least moved to declarative init files with
one bash/dash/sh script to start and stop daemons; we didn't and we've
fortunately gone beyond that with systemd.


> * systemd is a huge effort that isn't doing anything to remedy the
> situation.

One or two years after the release of EL-7, everyone'll wonder what
all the anti-systemd fuss was about...

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[zxq9]

On 08/13/2013 03:41 AM, Kraus, Dave (GE Healthcare) wrote:

I did say, dependent on system configuration.

X11 is not treated as a "standard" service on a Red Hat box. (Debian, for 
example, does.)

If you've installed services outside of Red Hat's management, then see above 
re:system configuration.


This discussion demonstrates two things:

* The old init system was complicated (in that the defaults aren't 
uniform). Familiarity with the system triumphed over lack of clear 
implementation and lack of documentation.


* systemd is a huge effort that isn't doing anything to remedy the 
situation.


This echoes the history of HAL and a few other things that have come 
before. My whole point was that these changes are politically, not 
technically driven, and that's not going to end well for anyone because 
RH doesn't have a monopoly in market or mindshare (recall the decline of 
Unix in the 80's due to this very issue).


A third, sidetrack point that's been demonstrated is that internet 
discussions have a tendency to get sidetracked.

RE: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Kraus, Dave (GE Healthcare)]

I did say, dependent on system configuration.

X11 is not treated as a "standard" service on a Red Hat box. (Debian, for 
example, does.)

If you've installed services outside of Red Hat's management, then see above 
re:system configuration. 

-Original Message-
From: owner-scientific-linux-us...@listserv.fnal.gov 
[mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Konstantin 
Olchanski
Sent: Monday, August 12, 2013 12:51 PM
To: Kraus, Dave (GE Healthcare)
Cc: SL Users
Subject: Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

On Mon, Aug 12, 2013 at 05:22:10PM +, Kraus, Dave (GE Healthcare) wrote:
> Q1: Start in runlevel 3
> 
> Q2: Dependent on system configuration. One way to check a little easier is:
> 
>chkconfig --list| awk '{print $1,$5,$7}' and see. 
> 

(I did ask for the quick answer, not the correct answer)

chkconfig does not show if X11 is started at what run level. what else does it 
not show?

Hint: ls -l /etc/init

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Steven Miano]

My inittab seems to indicate that X11 should only start on one run level:

# Default runlevel. The runlevels used are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have
networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)
#
id:3:initdefault:

uname -a
Linux hostname.com 2.6.32-358.11.1.el6.x86_64 #1 SMP Tue Jun 11 17:23:30
CDT 2013 x86_64 x86_64 x86_64 GNU/Linux


On Mon, Aug 12, 2013 at 1:50 PM, Konstantin Olchanski wrote:

> On Mon, Aug 12, 2013 at 05:22:10PM +, Kraus, Dave (GE Healthcare)
> wrote:
> > Q1: Start in runlevel 3
> >
> > Q2: Dependent on system configuration. One way to check a little easier
> is:
> >
> >chkconfig --list| awk '{print $1,$5,$7}' and see.
> >
>
> (I did ask for the quick answer, not the correct answer)
>
> chkconfig does not show if X11 is started at what run level. what else
> does it not show?
>
> Hint: ls -l /etc/init
>
> --
> Konstantin Olchanski
> Data Acquisition Systems: The Bytes Must Flow!
> Email: olchansk-at-triumf-dot-ca
> Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
>



-- 
 Miano, Steven M.
http://stevenmiano.com

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Konstantin Olchanski]

On Mon, Aug 12, 2013 at 05:22:10PM +, Kraus, Dave (GE Healthcare) wrote:
> Q1: Start in runlevel 3
> 
> Q2: Dependent on system configuration. One way to check a little easier is:
> 
>chkconfig --list| awk '{print $1,$5,$7}' and see. 
> 

(I did ask for the quick answer, not the correct answer)

chkconfig does not show if X11 is started at what run level. what else does it 
not show?

Hint: ls -l /etc/init

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

RE: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Kraus, Dave (GE Healthcare)]

Q1: Start in runlevel 3

Q2: Dependent on system configuration. One way to check a little easier is:

   chkconfig --list| awk '{print $1,$5,$7}' and see. 

On the system this Windows VM is running under, the only service that would not 
be run in runlevel 3 was spice-vdagentd. Which makes sense.

Your mileage my vary...

-Original Message-
From: owner-scientific-linux-us...@listserv.fnal.gov 
[mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Konstantin 
Olchanski
Sent: Monday, August 12, 2013 12:13 PM
To: Jeffrey Anderson
Cc: SL Users
Subject: Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

On Mon, Aug 12, 2013 at 09:56:53AM -0700, Jeffrey Anderson wrote:
> On Mon, Aug 12, 2013 at 8:40 AM, Konstantin Olchanski 
> wrote:
>
> > My prediction is that it is going to be like the HAL/UDEV story ...
>
> > Also same as the NetworkManager introduction ...
> 
> I don't necessarily disagree with your worries about the future.  But 
> I must add that the networking config scripts for our favorite distro 
> and its cousins have been located in /etc/sysconfig/network-scripts 
> for many years, long before the advent of NetworkManager.
> 


Now for a quick quiz.

In SL6.4, how do you prevent Xorg from starting on boot?

(Hint: in SL5, you comment it out in /etc/inittab)

P.S.

Those who answer: "change run level from 5 to 3", get a second quiz:

quickly, when you do this, what other services become disabled?


--
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Konstantin Olchanski]

On Mon, Aug 12, 2013 at 09:56:53AM -0700, Jeffrey Anderson wrote:
> On Mon, Aug 12, 2013 at 8:40 AM, Konstantin Olchanski 
> wrote:
>
> > My prediction is that it is going to be like the HAL/UDEV story ...
>
> > Also same as the NetworkManager introduction ...
> 
> I don't necessarily disagree with your worries about the future.  But I
> must add that the networking config scripts for our favorite distro and its
> cousins have been located in /etc/sysconfig/network-scripts for many years,
> long before the advent of NetworkManager.
> 


Now for a quick quiz.

In SL6.4, how do you prevent Xorg from starting on boot?

(Hint: in SL5, you comment it out in /etc/inittab)

P.S.

Those who answer: "change run level from 5 to 3", get a second quiz:

quickly, when you do this, what other services become disabled?


-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Jeffrey Anderson]

On Mon, Aug 12, 2013 at 8:40 AM, Konstantin Olchanski wrote:

> On Mon, Aug 12, 2013 at 10:24:42AM -0400, Paul Robert Marino wrote:
> > 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.
>
> My prediction is that it is going to be like the HAL/UDEV story. Before,
> if you wanted to automatically "chmod a+wr /dev/ttyUSB*", you just put it
> in /etc/rc.local. Now you have to write some arcane udev rules that have to
> be adjusted for every new os update. Documentation and examples are absent.
>
> Also same as the NetworkManager introduction. Something that was described
> in many books is replaced with something described by a few paragraphs
> in some obscure malformatted wiki. For example the fact that on SL
> the NM settings are stored in /etc/sysconfig/network-scripts/ifcfg-eth*
> files
> is documented (I was able to find the obscure wiki that mentions
> this in passing), but documentation for the exact format and meaning
> of the different entries is absent.
>

I don't necessarily disagree with your worries about the future.  But I
must add that the networking config scripts for our favorite distro and its
cousins have been located in /etc/sysconfig/network-scripts for many years,
long before the advent of NetworkManager.


> K.O.
>
>
> --
--
Jeffrey Anderson| jdander...@lbl.gov
Lawrence Berkeley National Laboratory   |
Office: 50A-5104E   | Mailstop 50A-5101
Phone: 510 486-4208 | Fax: 510 486-4204

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[David Sommerseth]

On 12/08/13 17:40, Konstantin Olchanski wrote:
[...snip...]
> Also same as the NetworkManager introduction. Something that was described
> in many books is replaced with something described by a few paragraphs
> in some obscure malformatted wiki. For example the fact that on SL
> the NM settings are stored in /etc/sysconfig/network-scripts/ifcfg-eth* files
> is documented (I was able to find the obscure wiki that mentions
> this in passing), but documentation for the exact format and meaning
> of the different entries is absent.

I find /usr/share/doc/initscripts-9.03.38/sysconfig.txt  fairly
informative and straight to the point - for most files in /etc/sysconfig.


--
kind regards,

David Sommerseth

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Konstantin Olchanski]

On Mon, Aug 12, 2013 at 10:24:42AM -0400, Paul Robert Marino wrote:
> 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.

My prediction is that it is going to be like the HAL/UDEV story. Before,
if you wanted to automatically "chmod a+wr /dev/ttyUSB*", you just put it
in /etc/rc.local. Now you have to write some arcane udev rules that have to
be adjusted for every new os update. Documentation and examples are absent.

Also same as the NetworkManager introduction. Something that was described
in many books is replaced with something described by a few paragraphs
in some obscure malformatted wiki. For example the fact that on SL
the NM settings are stored in /etc/sysconfig/network-scripts/ifcfg-eth* files
is documented (I was able to find the obscure wiki that mentions
this in passing), but documentation for the exact format and meaning
of the different entries is absent.

K.O.


> 
> 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.
> 
> On Wed, Jul 31, 2013 at 10:21 PM, zxq9  wrote:
> > On 07/31/2013 11:57 PM, Tom H wrote:
> >>
> >> On Tue, Jul 30, 2013 at 5:12 PM, zxq9  wrote:
> >>>
> >>> On 07/30/2013 10:26 PM, Tom H wrote:
> 
>  On Tue, Jul 30, 2013 at 8:24 AM, Nico Kadel-Garcia
>  wrote:
> >
> >
> > On Tue, Jul 30, 2013 at 8:18 AM, Tom H   wrote:
> > Thanks, good link. I'm just concerned it's going to cause build
> > problems for *every single open source daemon* as their SRPM's or
> > .spec files need to have two sets of options, one for the older SysV
> > init scripts and one for systemd, or need to be split to two different
> > .spec files. This is going to be so much fun!
> 
> 
>  You're welcome.
> 
>  Very true. Similar to some current Fedora spec files:
> 
>  %if 0%{?rhel}
>  ...
>  %endif
>  %if 0%{?fedora}
>  ...
>  %endif
> 
>  An eyesore and a mess; until December 2020...
> >>>
> >>>
> >>> tl;dr, Relevant Fedora thread first:
> >>>
> >>> http://lists.fedoraproject.org/pipermail/devel/2012-October/thread.html#172159
> >>>
> >>> Reminds me of a dismal post from October:
> >>> http://zxq9.com/archives/711
> >>
> >>
> >> 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?

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Paul Robert Marino]

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.

On Wed, Jul 31, 2013 at 10:21 PM, zxq9  wrote:
> On 07/31/2013 11:57 PM, Tom H wrote:
>>
>> On Tue, Jul 30, 2013 at 5:12 PM, zxq9  wrote:
>>>
>>> On 07/30/2013 10:26 PM, Tom H wrote:

 On Tue, Jul 30, 2013 at 8:24 AM, Nico Kadel-Garcia
 wrote:
>
>
> On Tue, Jul 30, 2013 at 8:18 AM, Tom H   wrote:
> Thanks, good link. I'm just concerned it's going to cause build
> problems for *every single open source daemon* as their SRPM's or
> .spec files need to have two sets of options, one for the older SysV
> init scripts and one for systemd, or need to be split to two different
> .spec files. This is going to be so much fun!


 You're welcome.

 Very true. Similar to some current Fedora spec files:

 %if 0%{?rhel}
 ...
 %endif
 %if 0%{?fedora}
 ...
 %endif

 An eyesore and a mess; until December 2020...
>>>
>>>
>>> tl;dr, Relevant Fedora thread first:
>>>
>>> http://lists.fedoraproject.org/pipermail/devel/2012-October/thread.html#172159
>>>
>>> Reminds me of a dismal post from October:
>>> http://zxq9.com/archives/711
>>
>>
>> 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?

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[zxq9]

On 07/31/2013 11:57 PM, Tom H wrote:

On Tue, Jul 30, 2013 at 5:12 PM, zxq9  wrote:

On 07/30/2013 10:26 PM, Tom H wrote:

On Tue, Jul 30, 2013 at 8:24 AM, Nico Kadel-Garcia
wrote:


On Tue, Jul 30, 2013 at 8:18 AM, Tom H   wrote:
Thanks, good link. I'm just concerned it's going to cause build
problems for *every single open source daemon* as their SRPM's or
.spec files need to have two sets of options, one for the older SysV
init scripts and one for systemd, or need to be split to two different
.spec files. This is going to be so much fun!


You're welcome.

Very true. Similar to some current Fedora spec files:

%if 0%{?rhel}
...
%endif
%if 0%{?fedora}
...
%endif

An eyesore and a mess; until December 2020...


tl;dr, Relevant Fedora thread first:
http://lists.fedoraproject.org/pipermail/devel/2012-October/thread.html#172159

Reminds me of a dismal post from October:
http://zxq9.com/archives/711


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?

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Tom H]

On Tue, Jul 30, 2013 at 5:12 PM, zxq9  wrote:
> On 07/30/2013 10:26 PM, Tom H wrote:
>> On Tue, Jul 30, 2013 at 8:24 AM, Nico Kadel-Garcia
>> wrote:
>>>
>>> On Tue, Jul 30, 2013 at 8:18 AM, Tom H  wrote:
>>> Thanks, good link. I'm just concerned it's going to cause build
>>> problems for *every single open source daemon* as their SRPM's or
>>> .spec files need to have two sets of options, one for the older SysV
>>> init scripts and one for systemd, or need to be split to two different
>>> .spec files. This is going to be so much fun!
>>
>> You're welcome.
>>
>> Very true. Similar to some current Fedora spec files:
>>
>> %if 0%{?rhel}
>> ...
>> %endif
>> %if 0%{?fedora}
>> ...
>> %endif
>>
>> An eyesore and a mess; until December 2020...
>
> tl;dr, Relevant Fedora thread first:
> http://lists.fedoraproject.org/pipermail/devel/2012-October/thread.html#172159
>
> Reminds me of a dismal post from October:
> http://zxq9.com/archives/711

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?

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Nico Kadel-Garcia]

On Tue, Jul 30, 2013 at 5:12 PM, zxq9  wrote:
> On 07/30/2013 10:26 PM, Tom H wrote:
>>
>> On Tue, Jul 30, 2013 at 8:24 AM, Nico Kadel-Garcia
>> wrote:
>>>
>>> On Tue, Jul 30, 2013 at 8:18 AM, Tom H  wrote:
>>> Thanks, good link. I'm just concerned it's going to cause build
>>> problems for *every single open source daemon* as their SRPM's or
>>> .spec files need to have two sets of options, one for the older SysV
>>> init scripts and one for systemd, or need to be split to two different
>>> .spec files. This is going to be so much fun!
>>
>>
>> You're welcome.
>>
>> Very true. Similar to some current Fedora spec files:
>>
>> %if 0%{?rhel}
>> ...
>> %endif
>> %if 0%{?fedora}
>> ...
>> %endif
>>
>> An eyesore and a mess; until December 2020...
>
>
> tl;dr, Relevant Fedora thread first:
> http://lists.fedoraproject.org/pipermail/devel/2012-October/thread.html#172159
>
> Reminds me of a dismal post from October:
> http://zxq9.com/archives/711

Yes. It's too bad that dismal poster didn't actually know more of the
history and types of daemon managers. SysV init scripts, which are
what that article so casually refer to as "*nix", are actually a
massive upgrade from the old /etc/rc.local setups. But there are
problems with them: they don't maintain the states of daemons that are
likely to crash and need restart, they're used inconsistently and
erratically, and their output is not logged reliably when they're run
as a root user. So there are a compelling set of reasons to use a
better daemon and init process.

i am afraid that the systemd authors have fallen prey to the idea that
their own tool can do *everything* better than the smaller, less
flexible, but more stable and better integrated tools currently used.
NetworkManager and Gnome3 have encountered similar issues, and it
concerns me about what we will inherit from upstream for use in
Scientific Linux 7.

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[zxq9]

On 07/30/2013 10:26 PM, Tom H wrote:

On Tue, Jul 30, 2013 at 8:24 AM, Nico Kadel-Garcia  wrote:

On Tue, Jul 30, 2013 at 8:18 AM, Tom H  wrote:
Thanks, good link. I'm just concerned it's going to cause build
problems for *every single open source daemon* as their SRPM's or
.spec files need to have two sets of options, one for the older SysV
init scripts and one for systemd, or need to be split to two different
.spec files. This is going to be so much fun!


You're welcome.

Very true. Similar to some current Fedora spec files:

%if 0%{?rhel}
...
%endif
%if 0%{?fedora}
...
%endif

An eyesore and a mess; until December 2020...


tl;dr, Relevant Fedora thread first:
http://lists.fedoraproject.org/pipermail/devel/2012-October/thread.html#172159

Reminds me of a dismal post from October:
http://zxq9.com/archives/711

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Tom H]

On Tue, Jul 30, 2013 at 8:24 AM, Nico Kadel-Garcia  wrote:
> On Tue, Jul 30, 2013 at 8:18 AM, Tom H  wrote:
>> On Tue, Jul 30, 2013 at 8:05 AM, Nico Kadel-Garcia  wrote:
>>>
>>> It is interesting. I also see Samba 3.x, not Samba 4.x. *Rats*. I was
>>> hoping for built-in Active Directory server replacements: guess I'll
>>> be rebundling the work I've done backporting Samba 4.0.7 to RHEL 6.
>>> And the slides don't say anything about the migration from SysV init
>>> scripts to systemd: that is going to be a *serious* adventure for
>>> 3rd-party open source components, like EPEL and Repoforge and atrpms.
>>
>> http://rhsummit.files.wordpress.com/2013/06/poettering_f_0945_getting_ready_for_systemd-the-new-red-hat-enterprise-linux-7-service-manager.pdf
>
> Thanks, good link. I'm just concerned it's going to cause build
> problems for *every single open source daemon* as their SRPM's or
> .spec files need to have two sets of options, one for the older SysV
> init scripts and one for systemd, or need to be split to two different
> .spec files. This is going to be so much fun!

You're welcome.

Very true. Similar to some current Fedora spec files:

%if 0%{?rhel}
...
%endif
%if 0%{?fedora}
...
%endif

An eyesore and a mess; until December 2020...

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Nico Kadel-Garcia]

On Tue, Jul 30, 2013 at 8:18 AM, Tom H  wrote:
> On Tue, Jul 30, 2013 at 8:05 AM, Nico Kadel-Garcia  wrote:
>> On Mon, Jul 29, 2013 at 1:25 PM, Lamar Owen  wrote:
>>> On 07/29/2013 10:47 AM, Pat Riehecky wrote:

 I believe there was some relevant information in this year's Red Hat
 Enterprise Linux Roadmap
  at Red Hat 
 Summit.
>>>
>>> See
>>> https://rhsummit.files.wordpress.com/2013/06/dumas_w_0120_rhel_roadmap1.pdf
>>>
>>> See slide 11.
>>>
>>> Also includes info relevant to the large filesystem thread. Seems EL7
>>> may ship with XFS as the default filesystem if it passes validation. (Slide
>>> 17).
>>>
>>> A very good read; time will tell how much actually comes to pass.
>>>
>>> (I'm personally looking forward to IEEE1588 PTP as shown on slide 38)...
>>
>> It is interesting. I also see Samba 3.x, not Samba 4.x. *Rats*. I was
>> hoping for built-in Active Directory server replacements: guess I'll
>> be rebundling the work I've done backporting Samba 4.0.7 to RHEL 6.
>> And the slides don't say anything about the migration from SysV init
>> scripts to systemd: that is going to be a *serious* adventure for
>> 3rd-party open source components, like EPEL and Repoforge and atrpms.
>
> http://rhsummit.files.wordpress.com/2013/06/poettering_f_0945_getting_ready_for_systemd-the-new-red-hat-enterprise-linux-7-service-manager.pdf

Thanks, good link. I'm just concerned it's going to cause build
problems for *every single open source daemon* as their SRPM's or
.spec files need to have two sets of options, one for the older SysV
init scripts and one for systemd, or need to be split to two different
.spec files. This is going to be so much fun!

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Tom H]

On Tue, Jul 30, 2013 at 8:05 AM, Nico Kadel-Garcia  wrote:
> On Mon, Jul 29, 2013 at 1:25 PM, Lamar Owen  wrote:
>> On 07/29/2013 10:47 AM, Pat Riehecky wrote:
>>>
>>> I believe there was some relevant information in this year's Red Hat
>>> Enterprise Linux Roadmap
>>>  at Red Hat Summit.
>>
>> See
>> https://rhsummit.files.wordpress.com/2013/06/dumas_w_0120_rhel_roadmap1.pdf
>>
>> See slide 11.
>>
>> Also includes info relevant to the large filesystem thread. Seems EL7
>> may ship with XFS as the default filesystem if it passes validation. (Slide
>> 17).
>>
>> A very good read; time will tell how much actually comes to pass.
>>
>> (I'm personally looking forward to IEEE1588 PTP as shown on slide 38)...
>
> It is interesting. I also see Samba 3.x, not Samba 4.x. *Rats*. I was
> hoping for built-in Active Directory server replacements: guess I'll
> be rebundling the work I've done backporting Samba 4.0.7 to RHEL 6.
> And the slides don't say anything about the migration from SysV init
> scripts to systemd: that is going to be a *serious* adventure for
> 3rd-party open source components, like EPEL and Repoforge and atrpms.

http://rhsummit.files.wordpress.com/2013/06/poettering_f_0945_getting_ready_for_systemd-the-new-red-hat-enterprise-linux-7-service-manager.pdf