[CentOS] Cemtos 7 : Systemd alternatives ?

classic Classic list List threaded Threaded
260 messages Options
1 ... 10111213
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Lamar Owen
On 07/15/2014 11:57 AM, [hidden email] wrote:
> Which contradicts the long post from the guy I was responding to, who
> said it *only* did start, stop, restart....

I figured it was a typo on his part, leaving out 'reload' like that, as
condrestart is also missing, and it's part of the standard set. I took
it more as, for instance, the PostgreSQL initscript's 'initdb' command,
which is a unique one, is no longer directly supported as a command line
option.  I haven't looked at what PostgreSQL's unit under C7 does as yet
if a database instance doesn't exist, but I'm sure it's already been
thought through; I'll cross that bridge when I come to it.

Read the man page for yourself.


_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Jonathan Billings
In reply to this post by Les Mikesell
On Tue, Jul 15, 2014 at 10:32:16AM -0500, Les Mikesell wrote:
> On Tue, Jul 15, 2014 at 10:18 AM, Jonathan Billings <[hidden email]> wrote:
> > I think the point is that systemd unit file syntax is significantly
> > simpler than shell syntax -- can we agree on that?
>
> No.  Everything you type on a command line is shell syntax.  If you
> don't think that is an appropriate way to start programs you probably
> shouldn't be using a unix-like system, much less redesigning it.  If
> you don't think the shell is the best tool, how about fixing it so it
> will be the best in all situations.

Yes, everything you type in a shell uses shell syntax.  But systemd
doesn't use a shell to start a program for a service.  This has
nothing to do with how programs are started from a shell, but rather
how the init system is starting the program.  Simplified, declaritive
syntax, no need to write the entire logical sequence for handling the
action verb parameter for each script ("Whoops!  I forgot that ;; in
the case statement!").  That's simpler.

> > It also is
> > significantly less-featureful than a shell programming language.  Yes,
> > you're going to be using shell elsewhere, but in my experience, the
> > structure of most SysVinit scripts is nearly identical, and where it
> > deviates is where things often get confusing to people not as familiar
> > with shell scripting.  Many of the helper functions in
> > /etc/rc.d/init.d/functions seem to exist to STOP people from writing
> > unique shell code in their init scripts.
>
> Yes, reusing common code and knowledge is a good thing.  But spending
> a bit of time learning shell syntax will help you with pretty much
> everything else you'll ever do on a unix-like system, where spending
> that time learning a new way to make your program start at boot will
> just get you back to what you already could do on previous systems.

If the entirety of the Linux startup process was written in simple
shell code, that might be a useful line of argument, but even in
CentOS6 there was a non-shell init system (Upstart) which requires
understanding of a domain-specific language, plus dozens of other
various configurations, like xinetd, cron, anacron, gdm, etc which
start processes on boot. Each has their quirks.  Not all of them use
shell syntax, and even those that did had caveats.  systemd just
replaces Upstart, and can potentially replace xinetd and cron as well,
using the same syntax and bringing in the ability to refer to each
other for startup sequence management.

I'm not arguing that you shouldn't learn shell programming (and I
don't believe that Mr. Poettering is either), just that systemd units
flattens the learning curve for creating new unit files.


--
Jonathan Billings <[hidden email]>
_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Richard Mann
In reply to this post by Jonathan Billings
You can still run apache's configtest

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Web_Servers.html

httpd Service Control
With the migration away from SysV init scripts, server administrators should switch to using the apachectl and systemctl commands to control the service, in place of the service command. The following examples are specific to the httpd service. The command:
service httpd graceful
is replaced by
apachectl graceful
The command:
service httpd configtest
is replaced by
apachectl configtest
The systemd unit file for httpd has different behavior from the init script as follows:
A graceful restart is used by default when the service is reloaded.
A graceful stop is used by default when the service is stopped.

Thanks,
Richard

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jonathan Billings
Sent: Tuesday, July 15, 2014 12:01 PM
To: CentOS mailing list
Subject: Re: [CentOS] Cemtos 7 : Systemd alternatives ?

On Tue, Jul 15, 2014 at 11:57:10AM -0400, [hidden email] wrote:

>
> Lamar Owen wrote:
> > On 07/15/2014 11:33 AM, [hidden email] wrote:
> >> This one does bother me. I may not want to restart a production
> >> instance of apache, when all I want it to do is reload the
> >> configuration files, so that one site changes while the others are all
> >> running happily as clams.
> >
> > systemctl reload $unit
> >
> > Documented in the systemctl(1) man page.
> <snip>
> Which contradicts the long post from the guy I was responding to, who said
> it *only* did start, stop, restart....

What I meant is that it doesn't support extra action verbs, such as
'service httpd configtest'.  I didn't mean to indicate that it ONLY
supported start, stop, restart and status.

--
Jonathan Billings <[hidden email]>
_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Marko Vojinovic
In reply to this post by Les Mikesell
On Tue, 15 Jul 2014 10:32:16 -0500
Les Mikesell <[hidden email]> wrote:

> On Tue, Jul 15, 2014 at 10:18 AM, Jonathan Billings
> <[hidden email]> wrote:
> > It also is
> > significantly less-featureful than a shell programming language.
> > Yes, you're going to be using shell elsewhere, but in my
> > experience, the structure of most SysVinit scripts is nearly
> > identical, and where it deviates is where things often get
> > confusing to people not as familiar with shell scripting.  Many of
> > the helper functions in /etc/rc.d/init.d/functions seem to exist to
> > STOP people from writing unique shell code in their init scripts.
>
> Yes, reusing common code and knowledge is a good thing.  But spending
> a bit of time learning shell syntax will help you with pretty much
> everything else you'll ever do on a unix-like system, where spending
> that time learning a new way to make your program start at boot will
> just get you back to what you already could do on previous systems.

Les, I could re-use your logic to argue that one should never even try
to learn bash, and stick to C instead. Every *real* user of UNIX-like
systems should be capable of writing C code, which is used in so many
more circumstances than bash. C is so much more powerful, more
expressive, immensely faster, covers a broader set of use-cases, is
being used in so many more circumstances than bash, is far more generic,
and in the long run it's a good investment in programming skills and
knowledge.

Why would you ever want to start your system using some clunky
shell-based interpreter like bash, (which cannot even share memory
between processes in a native way), when you can simply write a short
piece of C code, fork() all your services, compile it, and run?

All major pieces of any UNIX-like system were traditionally written in
C, so what would be the point of ever introducing a less powerful
language like bash, and doing the system startup in that?

And if you really insist on writing commands interactively into a
command prompt, you are welcome to use tcsh, and reuse all the syntax
and well-earned knowledge of C, rather than invest time to learn
yet-another-obscure-scripting-language...

Right? Or not?

If not, you may want to reconsider your argument against systemd ---
it's simple, clean, declarative, does one thing and does it well, and
it doesn't pretend to be a panacea of system administration like bash
does.

HTH, :-)
Marko

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Always Learning-3
In reply to this post by Les Mikesell

On Tue, 2014-07-15 at 10:32 -0500, Les Mikesell wrote:

> .... spending
> that time learning a new way to make your program start at boot will
> just get you back to what you already could do on previous systems.

So what is the advantage of systemd?  I accept we have to use it in C7,
but how is systemd going to improve the usability and reliability of
Centos ?


--
Regards,

Paul.
England, EU.

   Centos, Exim, Apache, Libre Office.
   Linux is the future. Micro$oft is the past.

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Always Learning-3
In reply to this post by mark-3

On Tue, 2014-07-15 at 11:33 -0400, [hidden email] wrote:

> This one does bother me. I may not want to restart a production instance
> of apache, when all I want it to do is reload the configuration files, so
> that one site changes while the others are all running happily as clams.

That's easy. I just type: sv httpd reload

(sv is my system-wide abbreviation for system, 'cos I'm lazy)



--
Regards,

Paul.
England, EU.

   Centos, Exim, Apache, Libre Office.
   Linux is the future. Micro$oft is the past.

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Always Learning-3
In reply to this post by Jonathan Billings

On Tue, 2014-07-15 at 12:00 -0400, Jonathan Billings wrote:


> What I meant is that it doesn't support extra action verbs, such as
> 'service httpd configtest'.  I didn't mean to indicate that it ONLY
> supported start, stop, restart and status.

So, in C7, how do I do a

system httpd configtest ?

Am I going to lose that facility in C7?


--
Regards,

Paul.
England, EU.

   Centos, Exim, Apache, Libre Office.
   Linux is the future. Micro$oft is the past.

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

John R Pierce
In reply to this post by Always Learning-3
On 7/15/2014 10:00 AM, Always Learning wrote:
> So what is the advantage of systemd?  I accept we have to use it in C7,
> but how is systemd going to improve the usability and reliability of
> Centos ?

the big thing with any of these new service managers (I'm more familiar
with Solaris SMF than systemd, but I believe it does the same thing), is
that it determines whether the service properly starts and tracks
service dependencies.    sysVinit style services could only be sequenced
(start all lower numbered services before starting this one) and it had
to wait for each service to start before going onto the next, while SMF
and presumably systemd will start multiple services in parallel as long
as they aren't dependent.    also, SMF at least detects when a service
fails/stops, and attempts to take corrective action per how that service
is configured

--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Keith Keller
In reply to this post by Always Learning-3
On 2014-07-15, Always Learning <[hidden email]> wrote:
> So, in C7, how do I do a
>
> system httpd configtest ?
>
> Am I going to lose that facility in C7?

apachectl configtest

(which is all the init script does anyway)

--keith

--
[hidden email]


_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Les Mikesell
In reply to this post by Marko Vojinovic
On Tue, Jul 15, 2014 at 11:56 AM, Marko Vojinovic <[hidden email]> wrote:
> >>
>> Yes, reusing common code and knowledge is a good thing.  But spending
>> a bit of time learning shell syntax will help you with pretty much
>> everything else you'll ever do on a unix-like system, where spending
>> that time learning a new way to make your program start at boot will
>> just get you back to what you already could do on previous systems.
>
> Les, I could re-use your logic to argue that one should never even try
> to learn bash, and stick to C instead.

You could, if every command typed by every user since unix v7 had been
parsed with C syntax instead of shell so there would be something they
could 'stick to'.  But, that's not true.

> Every *real* user of UNIX-like
> systems should be capable of writing C code, which is used in so many
> more circumstances than bash.

That might be true, but it is irrelevant.

> Why would you ever want to start your system using some clunky
> shell-based interpreter like bash, (which cannot even share memory
> between processes in a native way), when you can simply write a short
> piece of C code, fork() all your services, compile it, and run?

If you think bash is 'clunky', then why even run an operating system
where it is used as the native user interface?    Or, if you need to
change something, why not fix bash to have the close mapping to system
calls that bourne shell had back in the days before sockets?

> And if you really insist on writing commands interactively into a
> command prompt, you are welcome to use tcsh, and reuse all the syntax
> and well-earned knowledge of C, rather than invest time to learn
> yet-another-obscure-scripting-language...
>
> Right? Or not?

Well, Bill Joy thought so.  I wouldn't argue with him about it for his
own use, but for everyone else it is just another incompatible waste
of human time.

> If not, you may want to reconsider your argument against systemd ---
> it's simple, clean, declarative, does one thing and does it well, and
> it doesn't pretend to be a panacea of system administration like bash
> does.

I'm sure it can work - and will.  But I'm equally sure that in my
lifetime the cheap computer time it might save for me in infrequent
server reboots will never be a win over the expensive human time for
the staff training and new documentation that will be needed to deal
with it and the differences in the different systems that will be
running concurrently for a long time.

The one place it 'seems' like it should be useful would be on a laptop
if it handles sleep mode gracefully, but on the laptop where I've been
testing RHEL7 beta it seems purely random whether it will wake from
sleep and continue or if it will have logged me out.   And I don't
have a clue how to debug it.

--
   Les Mikesell
      [hidden email]
_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Keith Keller
In reply to this post by Jonathan Billings
On 2014-07-15, Jonathan Billings <[hidden email]> wrote:
>
> Ok, I'll give some examples of my experiences.  Warning: long post.

Long, but really helpful.  Thank you so much for putting your time in!

> So, the things that have bothered me so far:
> 1.) The order of the 'service SERVICENAME start|stop|status' options
> is reversed for 'systemctl start|stop|status SERVICENAME.service'

Yes, I've seen this too with initctl.  Grr!  But that's mostly
cosmetic, and just something to get used to (as you have).

> 2.) Daemons under systemd don't really need to daemonize anymore.  In
> the past, to start up a daemon process, you'd need to fork (or
> double-fork) and disconnect STDIN, STDOUT and STDERR file
> descriptors.  This was just accepted knowledge.  You don't need to do
> that anymore in systemd service units.  Heck, write to stdout or
> stderr, it'll be recorded in the journal.  Check out the
> openssh-server service unit, you'll see that sshd is run with -D
> there.  Systemd supports daemonized services, it's just not necessary
> anymore.

How is logging handled if services are printing to stdout?  Does systemd
separate logs (if told to) so that e.g. my sshd logs are separate from
my postfix logs?

> 4.) Debugging.  Why is my unit not starting when I can start it from
> the command line?  Once I figured out journalctl it was a bit easier,
> and typically it was SELinux, but no longer being able to just run
> 'bash -x /etc/rc.d/init.d/foobar' was frustrating.  sytemd disables
> core dumps on services by default (at least it did on Fedora, the
> documentation now says it's on by default.  Huh.  I should test
> that...)

Hmm, this seems most problematic of the issues you've described so far.
Is journalctl the way to get to stdout/err of a systemd unit?  If a
service fails, where is that failure logged, and where is the output of
the failed executable logged?

Thanks for your patience in this sometimes frustrating thread.  ;-)

--keith


--
[hidden email]


_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Mark Tinberg

On Jul 15, 2014, at 4:16 PM, Keith Keller <[hidden email]> wrote:

> On 2014-07-15, Jonathan Billings <[hidden email]> wrote:
>
>> 2.) Daemons under systemd don't really need to daemonize anymore.  In
>> the past, to start up a daemon process, you'd need to fork (or
>> double-fork) and disconnect STDIN, STDOUT and STDERR file
>> descriptors.  This was just accepted knowledge.  You don't need to do
>> that anymore in systemd service units.  Heck, write to stdout or
>> stderr, it'll be recorded in the journal.  Check out the
>> openssh-server service unit, you'll see that sshd is run with -D
>> there.  Systemd supports daemonized services, it's just not necessary
>> anymore.
>
> How is logging handled if services are printing to stdout?  Does systemd
> separate logs (if told to) so that e.g. my sshd logs are separate from
> my postfix logs?

Service stdout logging goes to the journal and is copied to rsyslog, log entries are tagged with the control group they came from, in addition to the process name, so it is easy to see any logs, whether via syslog or stdout, generated by any process in the sshd.service control group, or postfix.service control group.

$ journalctl --follow  _SYSTEMD_UNIT=sshd.service

man systemd.journal-fields for a list of all the fields you can search on

>> 4.) Debugging.  Why is my unit not starting when I can start it from
>> the command line?  Once I figured out journalctl it was a bit easier,
>> and typically it was SELinux, but no longer being able to just run
>> 'bash -x /etc/rc.d/init.d/foobar' was frustrating.  sytemd disables
>> core dumps on services by default (at least it did on Fedora, the
>> documentation now says it's on by default.  Huh.  I should test
>> that...)
>
> Hmm, this seems most problematic of the issues you've described so far.
> Is journalctl the way to get to stdout/err of a systemd unit?  If a
> service fails, where is that failure logged, and where is the output of
> the failed executable logged?

When you view the status of a service with systemctl it shows you the command line, when it last tried to start it, what processes are associated with the service if any are running, what the exit code was, and the last few lines from the journal of anything logged by that service, so is kind of a one-stop-shop.  For example:

$ systemctl status sshd
sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
   Active: active (running) since Thu 2014-07-10 20:55:47 CDT; 4 days ago
  Process: 1149 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
 Main PID: 1164 (sshd)
   CGroup: /system.slice/sshd.service
           └─1164 /usr/sbin/sshd -D

Jul 10 20:55:47 localhost systemd[1]: Starting OpenSSH server daemon...
Jul 10 20:55:47 localhost systemd[1]: Started OpenSSH server daemon.
Jul 10 20:55:48 localhost sshd[1164]: Server listening on 0.0.0.0 port 22.
Jul 10 20:55:48 localhost sshd[1164]: Server listening on :: port 22.

$ sudo systemctl stop sshd
$ systemctl status sshd
sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
   Active: inactive (dead) since Tue 2014-07-15 17:29:09 CDT; 3s ago
  Process: 1164 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
  Process: 1149 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
 Main PID: 1164 (code=exited, status=0/SUCCESS)

Jul 10 20:55:47 localhost systemd[1]: Starting OpenSSH server daemon...
Jul 10 20:55:47 localhost systemd[1]: Started OpenSSH server daemon.
Jul 10 20:55:48 localhost sshd[1164]: Server listening on 0.0.0.0 port 22.
Jul 10 20:55:48 localhost sshd[1164]: Server listening on :: port 22.
Jul 15 17:29:09 localhost systemd[1]: Stopping OpenSSH server daemon...
Jul 15 17:29:09 localhost sshd[1164]: Received signal 15; terminating.
Jul 15 17:29:09 localhost systemd[1]: Stopped OpenSSH server daemon.




Mark Tinberg, System Administrator
Division of Information Technology - Network Services
University of Wisconsin - Madison
[hidden email]

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Always Learning-3
In reply to this post by John R Pierce

On Tue, 2014-07-15 at 10:25 -0700, John R Pierce wrote:

> the big thing with any of these new service managers (I'm more familiar
> with Solaris SMF than systemd, but I believe it does the same thing), is
> that it determines whether the service properly starts and tracks
> service dependencies.    sysVinit style services could only be sequenced
> (start all lower numbered services before starting this one) and it had
> to wait for each service to start before going onto the next, while SMF
> and presumably systemd will start multiple services in parallel as long
> as they aren't dependent.    also, SMF at least detects when a service
> fails/stops, and attempts to take corrective action per how that service
> is configured


Thank you for the enlightening information.


--
Regards,

Paul.
England, EU.

   Centos, Exim, Apache, Libre Office.
   Linux is the future. Micro$oft is the past.

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

Always Learning-3
In reply to this post by Keith Keller

On Tue, 2014-07-15 at 11:00 -0700, Keith Keller wrote:

> apachectl configtest
>
> (which is all the init script does anyway)

Thanks. Its useful information.


--
Regards,

Paul.
England, EU.

   Centos, Exim, Apache, Libre Office.
   Linux is the future. Micro$oft is the past.

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] Cemtos 7 : Systemd alternatives ?

James B. Byrne
In reply to this post by Always Learning-3

On Tue, July 15, 2014 11:01, Les Mikesell wrote:

> On Mon, Jul 14, 2014 at 11:50 PM, Keith Keller
> <[hidden email]> wrote:
>>>>
>>> 1. See the systemd myths web page
>>> http://0pointer.de/blog/projects/the-biggest-myths.html
>>
>> In the interest of full disclosure, that page is written by one of the
>> primary authors of systemd, so we shouldn't expect an unbiased opinion.
>> (Not saying it's wrong, only that it's important to understand the
>> perspective an author might have.)
>
> One thing that bothers me very much when reading that is the several
> mentions of how you don't need to learn shell syntax as though that is
> an advantage or as if the author didn't already know and use it
> already.   As if he didn't understand that _every command you type at
> the command line_ is shell syntax.   Or as if he thinks learning a
> bunch of special-case language quirks is somehow better than one that
> you can use in many other situations.  When you get something that
> fundamental wrong it is hard to take the rest seriously.
>

Without gainsaying any of the foregoing, let me put the alternative case.

In my opinion, the era of dedicated sys-admins is passing if not already
finished.  A good friend of mine, sadly now deceased, began his career working
for RCA adjusting colour television sets in the owner's homes.  The
neighbourhood garage with two or three teen-aged grease-monkeys and
owner-mechanic are gone. So too are chauffeur-mechanics for car owners,
elevator operators in buildings, attendants at public toilets (at least in
North America), telephone-operators (mainly), and telephone booths (mostly).

It is called the advance of the ages. All technology must, if it is to become
truly useful, disappear from conscious consideration when operated. Consider
how little user maintenance is even possible with a modern automobile, how
pervasive the idea of instant world-wide voice and data communication is and
the absurd triviality of the operating the technology necessary to accomplish
this is (from the end user's perspective).

How many here remember party-line telephone service? Operator assisted
Station-to-Station and Person-to-Person long distance calls? Telegrams?
Telex?  Centrex?  Analysis pads?

Residual artifacts of all these things are still to be found but their
function has been subsumed and submerged by technology and the skills
necessary to operate them are obsolete.

All successful automation is going down the same path. The *nixes have not won
the OS wars but they are, I believe, a significant part of the medium term
future of automation.  However, to become truly useful to the widest possible
audience the arcane user interface commonly encountered in the myriad of
disjointed *nix system utilities has to be radically simplified to the point
of triviality.

A shell is, at its root, a programming language.  A peculiar form of virtual
machine if you will.  The vast majority of computer users are not programmers
and will never become so.  What this means is that the shell, of whatever ilk,
must be submerged to the view of most users if *nix is to thrive.

For the cognoscenti this will ever be a point of discomfort for it puts into
question the value of their hard won skills.  Nonetheless, things like
systemd, gnome3, and no-doubt dumber and more awful things to come are, in my
opinion, inevitable.  Computing is just too valuable a resource to be left
solely in the hands of a self-selected elite whose entrance requirement is
mastery of a dozen subtly different ways of telling computer systems to do
essentially the same thing.

There is a reason that things like Webmin already exist and it is not because
of MS-Windows or LUsers.  It is because the native administrative interface to
the standard *nix system is a nightmare of complexity, inconsistency and sheer
bloody-mindedness.

At least, that is how I see it.  I am not comfortable with change but I have
long ago given up trying to resist it.  If systemd presents a common DSL for
service management dependencies __AND__ it works then bring it on.  I had to
write upstart Stanzas for IAXModem on C6.  I suppose it will not be any harder
in its successor on C7.

--
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] TOT - Cemtos 7 : Systemd alternatives ?

mark-3
In reply to this post by mark-3
This is...weird.

Not sure why this suddenly showed, a week later, nor why it showed to me,
on my webmail/squirrelmail/ensignia that I use at work for this account,
as html/an attachment.

      mark

[hidden email] wrote:

> Robert Moskowitz wrote:
>>
>> On 07/10/2014 12:47 PM, [hidden email] wrote:
>>> Always Learning wrote:
>>>> On Thu, 2014-07-10 at 10:39 -0400, [hidden email] wrote:
>>>>
>>>>>          mark "we won't talk about the month I punch Addressograph
>>>>> plates...."
>>>> Addressograph plates?  That is really ancient !  but they were
>>>> incredible useful in those days.
>>>>
>>> Yeah... but did you ever do it, or see it done? Forget the old manual
>>> Underwood, this required actual *force* hitting the keys (yes, the
>>> machine was electric). No speed, either - the actuator arms had to hit
>>> the
>>> metal. WHAM-WHAM-WHAM-WHAM
>>
>> But the Linotype melted the lead and you pressed which key you wanted
>> the lead to flow into.  Kind of.  It was cool to see that bar of lead
>> slowly get lowered into the melting pot and finally out the other side
>> came the lead on steel printing plate.  Though one I saw only made rows
>> of text that then had to be lined up on the steel plate.  I guess it was
>> for allowing inclusion of pictures and such.
>>
>> Ah how xerography changed things.
>>
>> And that is again the point.  We do things one way because with a big
>> enough hammer we can get it to work.  Then new ways and new goals come
>> along and the old stuff heads off for the big melting pot in the
>> backyard.
>
> But with a good hammer, you can force the lead into the new plates without
> melting....
>
>         mark (who's taken at least part of this offlist)
>
> _______________________________________________
> CentOS mailing list
> [hidden email]
> http://lists.centos.org/mailman/listinfo/centos
>
>


_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] TOT - Cemtos 7 : Systemd alternatives ?

Always Learning-3

On Wed, 2014-07-16 at 11:47 -0400, [hidden email] wrote:

> This is...weird.
>
> Not sure why this suddenly showed, a week later, nor why it showed to me,
> on my webmail/squirrelmail/ensignia that I use at work for this account,
> as html/an attachment.

Reading the headers of that strange message

> Message-ID:
<[hidden email]>
> Date: Thu, 10 Jul 2014 17:39:15 +0000

one notices (well I did) that the email left the sender's computer
system on 16 July 2014. Here is the relevant header

> Received: from Pickup by OCCASHUB03.overstock.com with Microsoft SMTP
>        Server id 14.3.158.1; Wed, 16 Jul 2014 15:39:45 +0000
>

As you may appreciate, anything is possible with M$ :-)



--
Regards,

Paul.
England, EU.

   Centos, Exim, Apache, Libre Office.
   Linux is the future. Micro$oft is the past.

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] TOT - Cemtos 7 : Systemd alternatives ?

mark-3
Always Learning wrote:
> On Wed, 2014-07-16 at 11:47 -0400, [hidden email] wrote:
>
>> This is...weird.
>>
>> Not sure why this suddenly showed, a week later, nor why it showed to
>> me, on my webmail/squirrelmail/ensignia that I use at work for this
account,

>> as html/an attachment.
>
> Reading the headers of that strange message
>
>> Message-ID:
> <[hidden email]>
>> Date: Thu, 10 Jul 2014 17:39:15 +0000
>
> one notices (well I did) that the email left the sender's computer
> system on 16 July 2014. Here is the relevant header
>
>> Received: from Pickup by OCCASHUB03.overstock.com with Microsoft SMTP
>>        Server id 14.3.158.1; Wed, 16 Jul 2014 15:39:45 +0000
>>
I didn't even think to look at the header. overstock.com? Huh?
>
> As you may appreciate, anything is possible with M$ :-)

That's deeply weird. My email, from hostmonster, my hosting provider, (and
my domain is, of course, hosted on linux) goes through their email gateway
of unifiedlayer. How on earth did it get through overstock? I need to go
see if there's any more in that header....

Thanks, Paul.

        mark

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] TOT - Cemtos 7 : Systemd alternatives ?

mark-3
In reply to this post by Always Learning-3
Always Learning wrote:
> On Wed, 2014-07-16 at 11:47 -0400, [hidden email] wrote:
>
>> This is...weird.
>>
>> Not sure why this suddenly showed, a week later, nor why it showed to
>> me,on my webmail/squirrelmail/ensignia that I use at work for this
account,

>> as html/an attachment.
>
> Reading the headers of that strange message
>
>> Message-ID:
> <[hidden email]>
>> Date: Thu, 10 Jul 2014 17:39:15 +0000
>
> one notices (well I did) that the email left the sender's computer
> system on 16 July 2014. Here is the relevant header
>
>> Received: from Pickup by OCCASHUB03.overstock.com with Microsoft SMTP
>>        Server id 14.3.158.1; Wed, 16 Jul 2014 15:39:45 +0000
<snip>
Went back and looked at the full header... and sent a note to my hosting
provider, to see if they have a clue, and I'm wondering about a
man-in-the-middle attack. It *looks* to me as though it was resent, not
forwarded, from overstock.com as HTML email, too....

This just gets weirder.

      mark

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
Reply | Threaded
Open this post in threaded view
|

Re: [CentOS] TOT - Cemtos 7 : Systemd alternatives ?

Mark Tinberg

On Jul 16, 2014, at 3:30 PM, [hidden email] wrote:

>
> Went back and looked at the full header... and sent a note to my hosting
> provider, to see if they have a clue, and I'm wondering about a
> man-in-the-middle attack. It *looks* to me as though it was resent, not
> forwarded, from overstock.com as HTML email, too....
>
> This just gets weirder.
>

Maybe someone who is on the list in that domain redirected the message in a funky way that ended up going back to the list?  I know some MUAs can resend a message to a new destination as if that was the original target, with the original headers and an envelope sender based on the from header.


Mark Tinberg, System Administrator
Division of Information Technology - Network Services
University of Wisconsin - Madison
[hidden email]

_______________________________________________
CentOS mailing list
[hidden email]
http://lists.centos.org/mailman/listinfo/centos
1 ... 10111213