[CentOS] Hylafax without modems - SIP?

[Gary Stainburn]

I've just had to replace my Hylafax server as the cooling fan in the rack case 
has died and could not be replaced.

My box runs three fax modems, one for each of the original 3 fax machines that 
got skipped years ago.

This means that I now have 3 lots of:

USB to seral converter (new box doesn't have any COM ports.
9pin->25-pin serial cable
Modem
power supply
phone line
analogue port on our Mitel 3300 controller

I was wondering if there a better way?

I've done lots of Googling and there is a lot of conflicting - and mostly very 
old - information out there.

Does anyone have any more up-to-date opinions or advice on doing this?

Most of the concerns about reliability were based on IP latency, but my fax 
server and my Mitel controller are both on the same Procurv Gigabit switch so 
hopefully that would be quick enough
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Sorin Srbu]

> -Original Message-
> From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On
> Behalf Of Peter Duffy
> Sent: den 26 januari 2016 13:16
> To: centos@centos.org
> Subject: Re: [CentOS] Just need to vent
> 
> reminds me of first installing windows 95 (by the
> choice of my then employer, not me!) and seeing the message that it
> would completely change the way I related to my computer.

But it did!
I got really fast in shuffling those 3,5" install-diskettes every time the
OS puked and trashed the filesystem necessitating a reinstall. 8-)

-- 
//Sorin
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Peter Duffy]

On Mon, 2016-01-25 at 08:05 -0600, Chris Adams wrote:
> Once upon a time, Peter Duffy  said:
> > The thing which always gets me about systemd is not the thing itself,
> > but the way it was rolled out. When I first installed Red Hat 7, if a
> > window had appeared telling me about systemd and asking me if I wanted
> > to use it, or stick with the old init framework, I'd have opted for the
> > latter (as I was interested primarily in continuity from the previous
> > version.)
> 
> That's not really practical for something as core as the init system.
> Trying to support two init systems in parallel, especially for as long
> as Red Hat supports a RHEL release, would require a massive amount of
> work.  A distribution is about making choices and implementing them in
> the best way possible; for "leaf" packages like an editor or a web
> browser, it is easy to have multiple options (where they don't
> conflict), but core stuff like the kernel and init system don't leave
> lots of room for choice.
> 

Ultimately it's all software, and software can be
written/changed/updated to do anything required - all that's needed is
the skill and the motivation. If systemd is so "core" that it can't be
unplugged and plugged easily, and glues together a lot of otherwise
unrelated components,  then it's just bad software - end of story (the
problems with tightly-coupled components were first identified over 40
years ago, and modularization has been the watchword ever since.)

In my view, it's high time someone independently analysed systemd down
to basic code level, and understood why it's so invasive (if it actually
is.) Then the way forward would be clear - fork it, and produce a new
version which wasn't so invasive, and which could be swapped in/out. I'm
not saying it would be easy! ("We do not do these things because they
are easy - we do them because they are hard!") 
 
> I remember people complaining about SysV-style init too, "what's with
> all these scripts" and "why can't I just add a line to /etc/rc".
> systemd is a different way of thinking, but it isn't exactly original
> (Sun and Mac have similar launchers); practical experience has shown
> that this can be a better way of managing services.

No one is saying that sysvinit is perfect. What I can't grasp is why
replace it with something which is no less imperfect, and is almost
certainly worse in at least some respects - and to make that replacement
unavoidable and mandatory. 

I'm also still trying to figure out in what way systemd is supposed to
be "better". I've seen the following things claimed for it:

- faster boot time (this was apparently the main motivation behind it.)
My experience with systemd-managed systems has been limited - but so
far, I've not noticed faster boot times with systemd (maybe because the
boxes booted fast enough previously.)

- parallel startup of services. Not sure that I'd want that anyway - too
much risk of two services trying to grab the same resource at the same
time - I'm absolutely happy with the sysvinit approach of one service
startup completing/failing before the next one happens. That way, things
are nice and orderly.

- better handling of hot-plug devices. I've not yet seen that in action,
but that is the one thing which makes me inclined to investigate systemd
in more detail.

> Nobody is forcing you to run systemd; you can continue to run CentOS 6
> and earlier for years.  But if you are a system administrator, your job
> is about learning and adapting, not trying to keep a static setup for
> life.  systemd is different (just like SELinux was years ago), but I
> suggest you learn it.  It can make your admin life easier.  Is it
> perfect?  No, nothing ever is; I do think it is a big improvement
> though.
> 

My job as a system administrator is to serve the users who use the
servers I manage and administer, and to keep those servers and services
in suitable condition for the users to do their work and earn their
daily bread. 

As we all know (don't we just?) sysadmin work and responsibilities are
heavy, and frequently eat into evenings, nights, weekends and
(so-called) holidays. Anything which increases the sysadmin workload -
e.g. suddenly faced with a vertical learning curve just to do the tasks
they did yesterday, or a GUI which leaves them unable to find anything
on their screens - is a major issue, and prejudicial not only to the
sysadmin's own work, but also to that of the users to whom he/she is
responsible. And when you're talking about systems used by hundreds and
thousands of users, that's a big problem. 


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Peter Duffy]

On Mon, 2016-01-25 at 16:53 +, Richard Mann wrote:
> > 
> > Complaining on the CentOS list is probably not that productive, though.
> > 
> 
> +1.  To be constructive, the criticism would need to be done ELSEWHERE.  On 
> this list, it is just whining.

It's not complaining. It's discussion. 


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] kernel update does not update grub boot list ...

[Philippe BOURDEU d'AGUERRE]

Le 26/01/2016 12:53, lejeczek a écrit :

.. in that expected way where newly installed kernel is set to boot as
default.

would you suggest where to look, what to check?


In /etc/sysconfig/kernel :

# UPDATEDEFAULT specifies if new-kernel-pkg should make
# new kernels the default
UPDATEDEFAULT=yes


--
Philippe BOURDEU d'AGUERRE
AIME - Campus de l'INSA http://www.aime-toulouse.fr/
135 av. de Rangueil Tél +33 561 559 885
31077 TOULOUSE Cedex 4 - FRANCE Fax +33 561 559 870
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS-announce Digest, Vol 131, Issue 8

[centos-announce-request]

Send CentOS-announce mailing list submissions to
centos-annou...@centos.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@centos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."


Today's Topics:

   1. CESA-2016:0063 Important CentOS 6 ntp SecurityUpdate
  (Johnny Hughes)
   2. CESA-2016:0063 Important CentOS 7 ntp SecurityUpdate
  (Johnny Hughes)
   3. CESA-2016:0064 Important CentOS 7 kernel Security Update
  (Johnny Hughes)


--

Message: 1
Date: Mon, 25 Jan 2016 14:27:37 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2016:0063 Important CentOS 6 ntp
SecurityUpdate
Message-ID: <20160125142737.ga16...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2016:0063 Important

Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-0063.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
b172e4c9936ba6db7e7df9a611f2ba305b0682bb0545c03ba23bc501ae7833f8  
ntp-4.2.6p5-5.el6.centos.4.i686.rpm
0cbe654866db67e07ba4dbea484f6eea8136a0a23e5123dfebf1ac097162dfb4  
ntpdate-4.2.6p5-5.el6.centos.4.i686.rpm
9a0cbc08c20ee5b43fd8518a2ccd0a13a274b0464a688fef4cc10b940c848993  
ntp-doc-4.2.6p5-5.el6.centos.4.noarch.rpm
4fdf6a42d2a1178394d328832e70284d631a0b14535af97ffa94d659b545d4b8  
ntp-perl-4.2.6p5-5.el6.centos.4.i686.rpm

x86_64:
c9bcbc789b84223a297f54197d407520f56d0d4d4775787dd0f746426d2e8866  
ntp-4.2.6p5-5.el6.centos.4.x86_64.rpm
07fcdccf4e98b884fc6e99bf568fb037547d7340083ba913d598d0b53cc162d7  
ntpdate-4.2.6p5-5.el6.centos.4.x86_64.rpm
9a0cbc08c20ee5b43fd8518a2ccd0a13a274b0464a688fef4cc10b940c848993  
ntp-doc-4.2.6p5-5.el6.centos.4.noarch.rpm
c2069c233875863df714450ba095380586746768fab379e7fe737c915e27721f  
ntp-perl-4.2.6p5-5.el6.centos.4.x86_64.rpm

Source:
7a3f04e3f4c7402309a5a7cbf9a7997778298cd1dbac24efd2ca98b9d75eacec  
ntp-4.2.6p5-5.el6.centos.4.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS



--

Message: 2
Date: Mon, 25 Jan 2016 15:08:59 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2016:0063 Important CentOS 7 ntp
SecurityUpdate
Message-ID: <20160125150859.ga31...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2016:0063 Important

Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-0063.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
4b606ea94878f359cc016e2fb3545c87af50b77cab65c21ca7daa534c5a49252  
ntp-4.2.6p5-22.el7.centos.1.x86_64.rpm
4a320e7a12cf9b0e662e05a5371df9fe3b8fe3881f8b489ec02fc97769ac8628  
ntpdate-4.2.6p5-22.el7.centos.1.x86_64.rpm
37c9092a5fc997a11dd02bd4748024584c305f691437e4546418e453cec19c7e  
ntp-doc-4.2.6p5-22.el7.centos.1.noarch.rpm
b71ff70a1dfd7ed80ad43c76d651b821b5cdc3cd4360b87f244b4aff154d5387  
ntp-perl-4.2.6p5-22.el7.centos.1.noarch.rpm
71e36f16c2b105c208284bdfc4d08b1e93b0822fa7f08a569043c4cefdccf4f8  
sntp-4.2.6p5-22.el7.centos.1.x86_64.rpm

Source:
207b221dcadaa5ce149bd47258f23eafe973686dfe31030d689850dfe6b4d9ed  
ntp-4.2.6p5-22.el7.centos.1.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS



--

Message: 3
Date: Tue, 26 Jan 2016 02:08:06 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2016:0064 Important CentOS 7 kernel
SecurityUpdate
Message-ID: <20160126020806.ga42...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2016:0064 Important

Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-0064.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
29350967bf2d01358deaf9a99e1520eeb0af7bedae1d1cde8fdc73bf80731d4c  
kernel-3.10.0-327.4.5.el7.x86_64.rpm
674d565da50e81500b2b7fc49fc5a8005e2819b07acbd1d405078e7bc605036a  
kernel-abi-whitelists-3.10.0-327.4.5.el7.noarch.rpm
3c412b021fdab6881f46d0d7a09e9a2f2e3ffb33a93fb4f365f508e8e35b5b2d  
kernel-debug-3.10.0-327.4.5.el7.x86_64.rpm
21b228926c50ffcf49e55ed47bab7012d7cb55b495e84934138089cc1595933b  
kernel-debug-devel-3.10.0-327.4.5.el7.x86_64.rpm

[CentOS] kernel update does not update grub boot list ...

[lejeczek]

.. in that expected way where newly installed kernel is set 
to boot as default.


would you suggest where to look, what to check?

many thanks.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Peter Duffy]

On Tue, 2016-01-26 at 11:57 +, John Hodrien wrote:
> On Tue, 26 Jan 2016, Peter Duffy wrote:
> 
> https://wiki.debian.org/Debate/initsystem/systemd#Why_Debian_should_default_to_systemd
> 

Might be more convincing if they stuck to reasoned argument, rather than
propaganda. "Systemd is straightforward"; "systemd is incredibly fast (1
second to boot)" - reminds me of first installing windows 95 (by the
choice of my then employer, not me!) and seeing the message that it
would completely change the way I related to my computer. 

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-es] [VirtualBox] No aparece boton de apagar Windows

[Oscar Osta Pueyo]

Hola,
Creo que problema es del windows y debe ser un tema de políticas de
seguridad del usuario. Los Terminal Server son compartidos por varios
usuarios trabajando al mismo tiempo, imagina que todos pudieran apagar la
máquina, sin avisar a los otros.

Debes usar más google y el problema es de Windows no de CentOS.
http://www.thinstuff.com/faq/index.php?action=artikel=94

Saludos,
Gracias por su respuesta, pero debido a que los que dan uso de los
programas que estan en el Windows 7 virtualizado dentro de CentOS no puedo
forzarlos a que hagan algo que para mi gusto lo haria por comando. Ya
saben, lo primero que me dicen "porque no esta el boton de apagar en inicio
?? podrias ponerselo es que no puedo apagar el equipo"

Asi que vuelvo a preguntarles, alguien de casualidad sabe como colocar ese
boton ??? porque me imagino es por culpa del VirtualBox, no creo que sea
por el lado de Windows !???



El 26 de enero de 2016, 16:02, Rhamyro Alcoser A. 
escribió:

> De pronto, Reinicia al Windows Vía comando. mas rápido. shutdown -r -f -t
0
>
> El 26 de enero de 2016, 16:49, Oscar Osta Pueyo
> escribió:
>
> > Hola,
> > Siendo un tema windows, www.google.com.
> > El dia 26/01/2016 9:39 p. m., "angel jauregui" 
> va
> > escriure:
> >
> > > Buenas.
> > >
> > > Uso CentOS 6 y he montado Windows 7 en una VirtualBox en la cuenta del
> > > usuairio "admin", y al iniciarla me topo conque no puedo apagar el
> equipo
> > > desde el entorno de Windows :S, no me sale el "inicio / Apagar". Es un
> > > fastidio porque siempre que el de soporte se conecta via RemoteDesktop
> al
> > > Windows en la VirtualBox y pone alguna actualizacion me pide que la
> > > reinicie porque no da la opcion :S
> > >
> > > Alguien que sepa como habilitar el boton ?
> > >
> > >
> > >
> > > --
> > > M.S.I. Angel Haniel Cantu Jauregui.
> > >
> > > Celular: (011-52-1)-899-871-17-22
> > > E-Mail: angel.ca...@sie-group.net
> > > Web: http://www.sie-group.net/
> > > Cd. Reynosa Tamaulipas.
> > > ___
> > > CentOS-es mailing list
> > > CentOS-es@centos.org
> > > https://lists.centos.org/mailman/listinfo/centos-es
> > >
> > ___
> > CentOS-es mailing list
> > CentOS-es@centos.org
> > https://lists.centos.org/mailman/listinfo/centos-es
> >
>
>
>
> --
>
> *Rhamyro Alcoser A.*
>
> *ITIL & Systems Development*
>
> *Mailto1:* rhamyr...@gmail.com
>
> *Mailto2:* rhamyr...@icloud.com 
>
> *Skype: *rhamyr...@outlook.com 
>
> *Quito - Ecuador *
>
>
> *¿Qué, pues, diremos a esto? Si Dios es por nosotros, ¿quién contra
> nosotros?, Rm 8:31*
> ___
> CentOS-es mailing list
> CentOS-es@centos.org
> https://lists.centos.org/mailman/listinfo/centos-es
>



--
M.S.I. Angel Haniel Cantu Jauregui.

Celular: (011-52-1)-899-871-17-22
E-Mail: angel.ca...@sie-group.net
Web: http://www.sie-group.net/
Cd. Reynosa Tamaulipas.
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS-virt] hoping to reschedule SIG meetings to Tuesdays 1500 UTC

[George Dunlap]

On Thu, Jan 14, 2016 at 11:52 AM, Sandro Bonazzola  wrote:
>
>
> On Tue, Jan 12, 2016 at 6:00 PM, Lokesh Mandvekar 
> wrote:
>>
>> I can't make it to the current schedule for alternate Tuesday 1400 UTC
>> meetings.
>>
>> I was hoping we could reschedule it to 1500 UTC on the same Tuesdays
>> instead, or
>> any other slot which could work for all.
>>
>> What do other members think?
>
>
>
> Ok for me

OK, well let's change the meeting then -- 1500 UTC (at the moment --
changes with British DST).

That makes it in one hour -- hope to see you guys there! :-)

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Mouse and display issues with Windows 10 guest

[Robert Nichols]

Anyone managed to get a Windows 10 guest running well under qemu/kvm?
I can get it up and running, but there is a major issue with losing
use of the mouse, plus my display resolution is stuck at 1024x768.

The mouse will work for a short time (a few seconds to a few minutes),
but then stops responding. That's with the mouse coming in as the
recommended QEMU tablet device. I can assign a USB mouse to the guest
as a USB host device, but it also stops responding after a short time.
At least with the USB mouse I can remove it from the guest and then
reassign it again. That gives me use of the mouse, but again only for
a short time. Trying run Windows 10 from just a keyboard is an
exercise in frustration.

I can't get Windows 10 to believe that any screen resolution besides
1024x768 is available. That's the case both with VNC/vga and
Spice/qxl. This is in contrast with Windows 7, which offers a good
selection of resolutions with VNC/vga.

Any suggestions or success reports would be appreciated.

--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.

___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-docs] Introduction

[Remi Collet]

Introduction:

Remi Collet


I'd like to get wiki access, only to be able to create my user page
https://wiki.centos.org/RemiCollet


And perhaps later, some edit about SCL documentation
https://wiki.centos.org/SpecialInterestGroup/SCLo


Thanks,
Remi
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs

Re: [CentOS-docs] Introduction

[Akemi Yagi]

On Tue, Jan 26, 2016 at 8:37 AM, Remi Collet 
wrote:

> Introduction:
>
> Remi Collet
>
>
> I'd like to get wiki access, only to be able to create my user page
> https://wiki.centos.org/RemiCollet
>
> You should be able to edit this page now.


> And perhaps later, some edit about SCL documentation
> https://wiki.centos.org/SpecialInterestGroup/SCLo
>
>
Apparently already done by Honza Horak. :)

> Thanks,
> Remi
>

Thanks for your contribution.
Akemi
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs

Re: [CentOS] Just need to vent

[Sylvain CANOINE]

>> I'm also still trying to figure out in what way systemd is supposed to
>> be "better".
> 
> https://wiki.debian.org/Debate/initsystem/systemd#Why_Debian_should_default_to_systemd
> 
Counter-arguments are easy to find as well. For example :
http://judecnelson.blogspot.fr/2014/09/systemd-biggest-fallacies.html

Sylvain.
Pensez ENVIRONNEMENT : n'imprimer que si ncessaire

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] kernel update does not update grub boot list ...

[lejeczek]

On 26/01/16 12:23, Philippe BOURDEU d'AGUERRE wrote:

Le 26/01/2016 12:53, lejeczek a écrit :
.. in that expected way where newly installed kernel is 
set to boot as

default.

would you suggest where to look, what to check?


In /etc/sysconfig/kernel :

# UPDATEDEFAULT specifies if new-kernel-pkg should make
# new kernels the default
UPDATEDEFAULT=yes



gee, kernel-uek (for those of us who use it) puts in:

DEFAULTKERNEL=kernel-uek

replacing usual.
Strange! though cause after updates (even with 
UPDATEDEFAULT=yes) default was kept to be still distro's 
(non-uek) default kernel, only older version.

but reverse to:

DEFAULTKERNEL=kernel

and it works,
seems like a tiny bug, either on grub's or kernel-uek 
packages' side.


thanks man

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] vpn - xl2tpd and routing to a net?

[lejeczek]

hi everybody

I'm having a, I'd like to think a "regular" VPN with 
IPsec/xl2tpd and it all works OK, except..
One thing that I never needed but now I do and I wonder 
is it my iptables, or/and routing or maybe VPN server config..?


vpn clients with established tunnels can get to VPN server's 
NICs/IPs but cannot get through to the net behind the server.
Well... they can, but only if on a host (eg. 192.168.2.33) 
on VPN server's net I do:


route add -host 192.168.2.10 gw 192.168.2.100# 
192.168.2.10 is VPN client


I thought this I'd not need since that local net (eg. 
192.168.2.33) use VPN server's 192.168.2.100 as the default gw.


is it by design and nature of that VPN solution it works 
this way or I actually have missed/messed up something?
I hope the latter and adding routing on per "to host" basis 
is redundant.


many thanks
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Jonathan Billings]

On Tue, Jan 26, 2016 at 11:53:27AM +, Peter Duffy wrote:
> It's not complaining. It's discussion. 

Discuss it all you like.  But "constructive criticism" (used earlier)
isn't terribly useful on the CentOS list, because CentOS has very
little control over the implementation of init systems or desktop
environments.  I'm probably the 123123th person on the list to say
this, but if you want a hand in the direction CentOS goes, get
involved in Fedora.

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Jonathan Billings]

On Tue, Jan 26, 2016 at 02:21:40PM +0100, Sylvain CANOINE wrote:
>
> >> I'm also still trying to figure out in what way systemd is supposed to
> >> be "better".
> > 
> > https://wiki.debian.org/Debate/initsystem/systemd#Why_Debian_should_default_to_systemd
> > 
> Counter-arguments are easy to find as well. For example :
> http://judecnelson.blogspot.fr/2014/09/systemd-biggest-fallacies.html

I've seen these counter-arguments.  It's not really a direct response
to Debian's arguments.  Its just a list of "fallacies" used to support
systemd.  I agree that some arguments pro-systemd are poor arguments,
but many of the technical arguments anti-systemd seem to boil down to:
"You can do this will SysVinit/xinetd/something else.  Its just
that nobody has done that yet" or "SysVinit can do this if we just fix
all the init scripts."  I agree that it is possible, but years of
trying have never managed to do it.  

For what its worth, I've already seen one vendor (to be left unnamed)
provide AWFUL systemd service units that seem to prove Douglas Adams
famous quote:  "...a common mistake that people make when trying to
design something completely foolproof is to underestimate the
ingenuity of complete fools."


-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Matthew Miller]

On Tue, Jan 26, 2016 at 08:43:46AM -0500, Jonathan Billings wrote:
> Discuss it all you like.  But "constructive criticism" (used earlier)
> isn't terribly useful on the CentOS list, because CentOS has very
> little control over the implementation of init systems or desktop
> environments.  I'm probably the 123123th person on the list to say
> this, but if you want a hand in the direction CentOS goes, get
> involved in Fedora.

Definitely. But please don't show up ranting about systemd unless you
genuinely have something new and insightful to add. We have literally
been discussing moving to an improved init system since 2005:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/Y6PUIY3HOPVKA5IUJQ5TL6WAVTE3G4KY/
and in that decade, pretty much everything to be said _has_ been said
and considered. That is, we've *been through* the independent analysis
of systemd.


-- 
Matthew Miller

Fedora Project Leader
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Sylvain CANOINE]

> Ultimately it's all software, and software can be
> written/changed/updated to do anything required - all that's needed is
> the skill and the motivation. If systemd is so "core" that it can't be
> unplugged and plugged easily, and glues together a lot of otherwise
> unrelated components,  then it's just bad software - end of story (the
> problems with tightly-coupled components were first identified over 40
> years ago, and modularization has been the watchword ever since.)
> 
> In my view, it's high time someone independently analysed systemd down
> to basic code level, and understood why it's so invasive (if it actually
> is.) Then the way forward would be clear - fork it, and produce a new
> version which wasn't so invasive, and which could be swapped in/out. I'm
> not saying it would be easy! ("We do not do these things because they
> are easy - we do them because they are hard!")

I know only one attempt : uselessd. Unfortunatly, the project is dead.
http://uselessd.darknedgy.net/

> 
>> I remember people complaining about SysV-style init too, "what's with
>> all these scripts" and "why can't I just add a line to /etc/rc".
>> systemd is a different way of thinking, but it isn't exactly original
>> (Sun and Mac have similar launchers); practical experience has shown
>> that this can be a better way of managing services.
> 
> No one is saying that sysvinit is perfect. What I can't grasp is why
> replace it with something which is no less imperfect, and is almost
> certainly worse in at least some respects - and to make that replacement
> unavoidable and mandatory.

I agree.
There are other init/service managers (no, init and service manager are not one 
same program) that combine the best of System V (simplicity, lightness, 
minimalism), and interesting ideas used by systemd ("BSD-style" dependencies 
management between services, for example). On Gentoo, the duo sysvinit/openrc 
works well, for example.

> - faster boot time (this was apparently the main motivation behind it.)
> My experience with systemd-managed systems has been limited - but so
> far, I've not noticed faster boot times with systemd (maybe because the
> boxes booted fast enough previously.)

My professional experience shows me systemd is by far lower than, for example, 
upstart.
But... let's be honest : is the OS launch time so important to make a software 
like systemd so revolutionary when it promises to save a handful of seconds ?
On servers, which spend much more time checking and starting the hardware 
components than really booting the system, the difference is negligible. A bit 
less on virtual guests, I agree, but, anyway, they're always on, and the lonely 
reason to reboot them is normally to update the kernel... This kind of 
intervention is normally scheduled, and the announced unavailability time is 
often overestimated, to be able to get round Murphy's laws. Benefit ? Zero.
On stations, maybe, systemd might potentially be useful. I don't know, I don't 
have systemd-dependant stations to hand. And I reboot my stations as often as 
my servers.

> 
> - parallel startup of services. Not sure that I'd want that anyway

Especially when the obvious directives are not respected. Tell systemd to start 
sshd AFTER network, for exemple, but forget to say sshd REQUIRES network, and 
systemd starts sshd... BEFORE network ! And says network isn't started, by the 
way.
Anyway, one more time, why this obsession to gain one or two seconds ?


> - better handling of hot-plug devices. I've not yet seen that in action,
> but that is the one thing which makes me inclined to investigate systemd
> in more detail.

Why does systemd care about devices pluging ? It's not its rule, it's the 
device manager's one. Udev, for example. Oh, wait...

> 
>> Nobody is forcing you to run systemd; you can continue to run CentOS 6
>> and earlier for years.  But if you are a system administrator, your job
>> is about learning and adapting, not trying to keep a static setup for
>> life.  systemd is different (just like SELinux was years ago), but I
>> suggest you learn it.

So I learn... I adapt... And I update... So I learn... I adapt...

>> It can make your admin life easier.

But it didn't say us how, then. :)

> As we all know (don't we just?) sysadmin work and responsibilities are
> heavy, and frequently eat into evenings, nights, weekends and
> (so-called) holidays. Anything which increases the sysadmin workload -
> e.g. suddenly faced with a vertical learning curve just to do the tasks
> they did yesterday, or a GUI which leaves them unable to find anything
> on their screens - is a major issue, and prejudicial not only to the
> sysadmin's own work, but also to that of the users to whom he/she is
> responsible. And when you're talking about systems used by hundreds and
> thousands of users, that's a big problem.

I don't think systemd was designed for servers... But sysadmins have to deal 
with it though.
When we need simply, robust and reliable 

Re: [CentOS] Just need to vent

[Matthew Miller]

On Tue, Jan 26, 2016 at 11:51:29AM +, Peter Duffy wrote:
> I'm also still trying to figure out in what way systemd is supposed to
> be "better". I've seen the following things claimed for it:

Of the three things you list, hot-plug is certainly an important one.
But, it's not the big deal. The big deal is that systemd is not just a
fire-and-hope startup system, but a service manager. It knows which
processes came from where. That means it can:

* insure that when something is stopped, it's actually stopped. (If
  you've ever managed an HPC cluster and had processes escape the
  scheduler, you know this problem is real.)

* track process lifecycle, and restart (or take other action) on
  failure. (If software were perfect, this wouldn't be needed, but as
  is, this can save you being paged in the middle of the night.)

* actually securely connect output to the process it came from for
  logging -- both stdout/stderr and actual log messages. (This is why
  journald is closely integrated.)

There are other advantages (real dependency ordering, resource
management/reservation with cgroups, etc.), but process supervision is
the big deal. There are other alternative systems which _also_ do this,
but overall, Fedora, openSUSE, Arch, Debian, Ubuntu, and others
eventually decided that systemd was the technically best choice.


-- 
Matthew Miller

Fedora Project Leader
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS 7 - DNAT with firewalld

[Django [BOfH]]

HI,

here I have an eMail with connected to a DMZ 10.0.0.0/24 network. This
server holds 10.0.0.87

There are two firewall-hosts one with CentOS 6 10.0.0.10 and one with
CentOS 7 10.0.0.17

The CentOS 6 has the following iptables-rule (extract):
--8<--8<--8<
*nat
-A POSTROUTING -o eth1 -j MASQUERADE
-A PREROUTING -i eth1 -d 217.91.103.190/32 -p tcp -m tcp --dport 25 -j
DNAT --to-destination 10.0.0.87:25


*filter
-A FORWARD -d 10.0.0.87/32 -i ppp0 -o eth0 -p tcp -m state --state NEW
-m tcp --dport 25 -j ACCEPT
--8<--8<--8<

If a external mailserver access the firewall, the traffic is routed to
10.0.0.87 port 25. As IP-adress from the external server I see hois
public-IP. Here's the part of maillog:

Jan 26 13:03:20 vml87 postfix/postscreen[14214]: CONNECT from
[88.198.212.215]:36131 to [10.0.0.87]:25
Jan 26 13:03:20 vml87 postfix/postscreen[14214]: PASS OLD
[88.198.212.215]:36131
Jan 26 13:03:20 vml87 postfix/smtpd[10268]: connect from
mx1.piratenpartei-bayern.de[88.198.212.215]
Jan 26 13:03:31 vml87 postfix/smtpd[10268]: disconnect from
mx1.piratenpartei-bayern.de[88.198.212.215]

so far so good, this work'ed fine the last 5 years ...

Now I've a second network with a CentOS 7 base firewall. I've tried to
adapt the roules I've mad on the old firewall.

--8<--8<--8<
# cat /etc/firewalld/zones/public.xml


  Public
  For use on external networks. You do not trust the other
computers on networks to not harm your computer. Only selected incoming
connections are accepted.
  
  


# cat /etc/firewalld/zones/private.xml


  Private
  For use on internal networks. You mostly trust the other
computers on the networks to not harm your computer. Only selected
incoming connections are accepted.
  
  
  


# cat /etc/firewalld/direct.xml


  -o eth1
-j MASQUERADE
  -i eth1
-d 192.168.0.17/32 -p tcp -m tcp --dport 25 -j DNAT --to-destination
10.0.0.87:25
  -i eth1
-d 10.0.0.87/32 -p tcp -m state --state NEW -m tcp --dport 25 -j
ACCEPT

--8<--8<--8<

The traffic over this firewall is routed to my mailserver, too. BUT I
did'nt see the external customer-IP, I only can see the IP-address of my
own firewall.

Jan 26 13:04:52 vml87 postfix/postscreen[14214]: CONNECT from
[10.0.0.17]:33803 to  [10.0.0.87]:25
Jan 26 13:04:52 vml87 postfix/postscreen[14214]: WHITELISTED
[10.0.0.17]:33803
Jan 26 13:04:52 vml87 postfix/smtpd[10268]: connect from
vml17.dmz.nausch.org[10.0.0.17]
Jan 26 13:04:53 vml87 postfix/smtpd[11397]: disconnect from
vml17.dmz.nausch.org[10.0.0.17]

So I think destination NAT (DNAT) isn't working on my CentOS 7 host. As
I seaid on my CentOS6 host DNAT is working very well.

So where's my error? in my configuration or in my head? ;)

Thanx 4 help!


ttyl
Django
-- 
"Bonnie & Clyde der Postmaster-Szene!" approved by Postfix-God
http://wetterstation-pliening.info
http://dokuwiki.nausch.org
http://wiki.piratenpartei.de/Benutzer:Django
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Johnny Hughes]

On 01/26/2016 05:51 AM, Peter Duffy wrote:
> On Mon, 2016-01-25 at 08:05 -0600, Chris Adams wrote:
>> Once upon a time, Peter Duffy  said:
>>> The thing which always gets me about systemd is not the thing itself,
>>> but the way it was rolled out. When I first installed Red Hat 7, if a
>>> window had appeared telling me about systemd and asking me if I wanted
>>> to use it, or stick with the old init framework, I'd have opted for the
>>> latter (as I was interested primarily in continuity from the previous
>>> version.)
>>
>> That's not really practical for something as core as the init system.
>> Trying to support two init systems in parallel, especially for as long
>> as Red Hat supports a RHEL release, would require a massive amount of
>> work.  A distribution is about making choices and implementing them in
>> the best way possible; for "leaf" packages like an editor or a web
>> browser, it is easy to have multiple options (where they don't
>> conflict), but core stuff like the kernel and init system don't leave
>> lots of room for choice.
>>
> 
> Ultimately it's all software, and software can be
> written/changed/updated to do anything required - all that's needed is
> the skill and the motivation. If systemd is so "core" that it can't be
> unplugged and plugged easily, and glues together a lot of otherwise
> unrelated components,  then it's just bad software - end of story (the
> problems with tightly-coupled components were first identified over 40
> years ago, and modularization has been the watchword ever since.)
> 
> In my view, it's high time someone independently analysed systemd down
> to basic code level, and understood why it's so invasive (if it actually
> is.) Then the way forward would be clear - fork it, and produce a new
> version which wasn't so invasive, and which could be swapped in/out. I'm
> not saying it would be easy! ("We do not do these things because they
> are easy - we do them because they are hard!") 
>  
>> I remember people complaining about SysV-style init too, "what's with
>> all these scripts" and "why can't I just add a line to /etc/rc".
>> systemd is a different way of thinking, but it isn't exactly original
>> (Sun and Mac have similar launchers); practical experience has shown
>> that this can be a better way of managing services.
> 
> No one is saying that sysvinit is perfect. What I can't grasp is why
> replace it with something which is no less imperfect, and is almost
> certainly worse in at least some respects - and to make that replacement
> unavoidable and mandatory. 
> 
> I'm also still trying to figure out in what way systemd is supposed to
> be "better". I've seen the following things claimed for it:
> 
> - faster boot time (this was apparently the main motivation behind it.)
> My experience with systemd-managed systems has been limited - but so
> far, I've not noticed faster boot times with systemd (maybe because the
> boxes booted fast enough previously.)
> 
> - parallel startup of services. Not sure that I'd want that anyway - too
> much risk of two services trying to grab the same resource at the same
> time - I'm absolutely happy with the sysvinit approach of one service
> startup completing/failing before the next one happens. That way, things
> are nice and orderly.
> 
> - better handling of hot-plug devices. I've not yet seen that in action,
> but that is the one thing which makes me inclined to investigate systemd
> in more detail.
> 
>> Nobody is forcing you to run systemd; you can continue to run CentOS 6
>> and earlier for years.  But if you are a system administrator, your job
>> is about learning and adapting, not trying to keep a static setup for
>> life.  systemd is different (just like SELinux was years ago), but I
>> suggest you learn it.  It can make your admin life easier.  Is it
>> perfect?  No, nothing ever is; I do think it is a big improvement
>> though.
>>
> 
> My job as a system administrator is to serve the users who use the
> servers I manage and administer, and to keep those servers and services
> in suitable condition for the users to do their work and earn their
> daily bread. 
> 
> As we all know (don't we just?) sysadmin work and responsibilities are
> heavy, and frequently eat into evenings, nights, weekends and
> (so-called) holidays. Anything which increases the sysadmin workload -
> e.g. suddenly faced with a vertical learning curve just to do the tasks
> they did yesterday, or a GUI which leaves them unable to find anything
> on their screens - is a major issue, and prejudicial not only to the
> sysadmin's own work, but also to that of the users to whom he/she is
> responsible. And when you're talking about systems used by hundreds and
> thousands of users, that's a big problem. 

So don't use it then .. EL6 has support until 30 Nov 2020.

SystemD is not better, the 3.x and 4.x Linux kernels are not better,
Gnome 3.x is not better, KDE 4.x is not better.  Blah, Blah, Blah.

Red Hat Linux 3.0.3 

Re: [CentOS] Hylafax without modems - SIP?

[James B. Byrne]

On Tue, January 26, 2016 04:57, Gary Stainburn wrote:
> I've just had to replace my Hylafax server as the cooling fan in the
> rack case has died and could not be replaced.
>
> My box runs three fax modems, one for each of the original 3 fax
> machines that got skipped years ago.
>
> This means that I now have 3 lots of:
>
> USB to seral converter (new box doesn't have any COM ports.
> 9pin->25-pin serial cable
> Modem
> power supply
> phone line
> analogue port on our Mitel 3300 controller
>
> I was wondering if there a better way?
>
> I've done lots of Googling and there is a lot of conflicting - and
> mostly very old - information out there.
>
> Does anyone have any more up-to-date opinions or advice on doing this?
>
> Most of the concerns about reliability were based on IP latency,
> but my fax server and my Mitel controller are both on the same
> Procurv Gigabit switch so hopefully that would be quick enough
>
>

We run Hylafax+ and use a Digium TDM800P analogue card in a Atom based
Supermicro 1u running Asterisk to connect to our fax lines using
standard RJ11 plugs. On the Asterisk host we run iaxmodem to listen to
the analogue ports.  Hylafax+ talks to the iaxmodem instances.  This
can be a network connection so it is not necessary to have Hylafax
running on the host with the FXO connection.

We have been running this setup with Avantfax as the UI since summer
2013 without problems.  The load on the fax host is trivial.


-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
James B. Byrnemailto:byrn...@harte-lyne.ca
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
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What to do when you've been hacked?

[James B. Byrne]

On Mon, January 25, 2016 19:12, Benjamin Smith wrote:

>
> Which I'd consider "best practices" and we do them.
> They are specifically asking about what to do *after* a
> breach. Despite all the best practices in
> place, there's *still* some risk.
>

If someone wants in to your network then they will get in.  There is
no point in deluding yourself or your clients on that point.

The first thing that you must do after a breach is detected, or even
suspected, is to notify all affected parties.  There is an
institutional bias against revelation of security incidents because of
the fear of embarrassment.  This is often couched in terms using the
word 'premature'.  Failure to disclose at the earliest opportunity is
unethical and ultimately self-defeating.  You will never regain trust
thereafter.

The second thing to do, concurrently with the first, is to isolate the
affected systems from the rest of your network.  If that means
physically pulling wires and putting the things on their own switch
and LAN segment blocked from the rest of your networks then do it. If
it means shutting down the affected hosts then do it.  If if means
disconnecting from the network at your gateway then do it. They are in
and they are looking for ways to expand their foothold.  Delaying
containment is pointless.

The third thing to do is to involve the authorities.  Unauthorised
computer access is an indictable offence in Canada and the UK.  It is
a federal felony in the U.S.A.  If you have an incident then report
it. That means you should have computer emergency response contact
information and reporting protocols already in place.

Now, with your clients and the authorities notified and the suspect
systems isolated, you begin to map out your recovery strategy.  The
basic bones of which you have already written down and implemented in
your backup and disaster recovery plan.  A security breach is a
disaster.  You need to start with that point clearly in mind and
proceed on that basis.

Once corporate and client services are restored on clean hosts and
reconnected to the Internet then begin your investigation. Use your
AIDE and syslog records to determine the point of entry, the length of
compromise and the extent of penetration.  If possible identify the
nature of the attackers and their target.  Where possible keep the
compromised hosts' disk drives unaltered for further technical
analysis.  Where warranted bring in forensic investigators to examine
them.

It will likely prove impossible to positively identify them but you
should be able to glean some inkling if this was a targeted breach or
an opportunistic one.  If the former then they will be back and you
will need to consider how to deal with the next assault.


-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
James B. Byrnemailto:byrn...@harte-lyne.ca
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
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Sylvain CANOINE]

> * insure that when something is stopped, it's actually stopped. (If
>  you've ever managed an HPC cluster and had processes escape the
>  scheduler, you know this problem is real.)

# systemctl list-units | grep -c abandoned
453
# uptime
 15:53:58 up 11 days, 21:03,   1 user,  load average, 0,01, 0,02, 0,05

> 
> * track process lifecycle, and restart (or take other action) on
>  failure. (If software were perfect, this wouldn't be needed, but as
>  is, this can save you being paged in the middle of the night.)

No. A software which falls down is buggy, and needs to be fixed. Period.
Masking the problem is the best way to never fix it. With this "feature", 
systemd (and other init systems providing it) will just make GNU/linux more 
unstable.

> 
> * actually securely connect output to the process it came from for
>  logging -- both stdout/stderr and actual log messages. (This is why
>  journald is closely integrated.)

Driving sysadmins unable to read logs just because the file is corrupted, or to 
send logs to a dedicated server, is a real security improvement, indeed.

> 
> There are other advantages (real dependency ordering, resource
> management/reservation with cgroups, etc.), but process supervision is
> the big deal. There are other alternative systems which _also_ do this,
> but overall, Fedora, openSUSE, Arch, Debian, Ubuntu, and others
> eventually decided that systemd was the technically best choice.

Redhat employs Lennart Poettering. Redhat derivates have to follow.
Ubuntu and Debian choose systemd, on one hand, because more and more softs 
depend on systemd (Gnome 3, for example), and on the other hand, to save 
maintainers time, dropping their own init system.
The technically best choice, you say ?

Sylvain.
Pensez ENVIRONNEMENT : n'imprimer que si ncessaire

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Valeri Galtsev]

On Tue, January 26, 2016 9:01 am, Johnny Hughes wrote:
> On 01/26/2016 05:51 AM, Peter Duffy wrote:
>> On Mon, 2016-01-25 at 08:05 -0600, Chris Adams wrote:
>>> Once upon a time, Peter Duffy  said:
 The thing which always gets me about systemd is not the thing itself,
 but the way it was rolled out. When I first installed Red Hat 7, if a
 window had appeared telling me about systemd and asking me if I wanted
 to use it, or stick with the old init framework, I'd have opted for
 the
 latter (as I was interested primarily in continuity from the previous
 version.)
>>>
>>> That's not really practical for something as core as the init system.
>>> Trying to support two init systems in parallel, especially for as long
>>> as Red Hat supports a RHEL release, would require a massive amount of
>>> work.  A distribution is about making choices and implementing them in
>>> the best way possible; for "leaf" packages like an editor or a web
>>> browser, it is easy to have multiple options (where they don't
>>> conflict), but core stuff like the kernel and init system don't leave
>>> lots of room for choice.
>>>
>>
>> Ultimately it's all software, and software can be
>> written/changed/updated to do anything required - all that's needed is
>> the skill and the motivation. If systemd is so "core" that it can't be
>> unplugged and plugged easily, and glues together a lot of otherwise
>> unrelated components,  then it's just bad software - end of story (the
>> problems with tightly-coupled components were first identified over 40
>> years ago, and modularization has been the watchword ever since.)
>>
>> In my view, it's high time someone independently analysed systemd down
>> to basic code level, and understood why it's so invasive (if it actually
>> is.) Then the way forward would be clear - fork it, and produce a new
>> version which wasn't so invasive, and which could be swapped in/out. I'm
>> not saying it would be easy! ("We do not do these things because they
>> are easy - we do them because they are hard!")
>>
>>> I remember people complaining about SysV-style init too, "what's with
>>> all these scripts" and "why can't I just add a line to /etc/rc".
>>> systemd is a different way of thinking, but it isn't exactly original
>>> (Sun and Mac have similar launchers); practical experience has shown
>>> that this can be a better way of managing services.
>>
>> No one is saying that sysvinit is perfect. What I can't grasp is why
>> replace it with something which is no less imperfect, and is almost
>> certainly worse in at least some respects - and to make that replacement
>> unavoidable and mandatory.
>>
>> I'm also still trying to figure out in what way systemd is supposed to
>> be "better". I've seen the following things claimed for it:
>>
>> - faster boot time (this was apparently the main motivation behind it.)
>> My experience with systemd-managed systems has been limited - but so
>> far, I've not noticed faster boot times with systemd (maybe because the
>> boxes booted fast enough previously.)
>>
>> - parallel startup of services. Not sure that I'd want that anyway - too
>> much risk of two services trying to grab the same resource at the same
>> time - I'm absolutely happy with the sysvinit approach of one service
>> startup completing/failing before the next one happens. That way, things
>> are nice and orderly.
>>
>> - better handling of hot-plug devices. I've not yet seen that in action,
>> but that is the one thing which makes me inclined to investigate systemd
>> in more detail.
>>
>>> Nobody is forcing you to run systemd; you can continue to run CentOS 6
>>> and earlier for years.  But if you are a system administrator, your job
>>> is about learning and adapting, not trying to keep a static setup for
>>> life.  systemd is different (just like SELinux was years ago), but I
>>> suggest you learn it.  It can make your admin life easier.  Is it
>>> perfect?  No, nothing ever is; I do think it is a big improvement
>>> though.
>>>
>>
>> My job as a system administrator is to serve the users who use the
>> servers I manage and administer, and to keep those servers and services
>> in suitable condition for the users to do their work and earn their
>> daily bread.
>>
>> As we all know (don't we just?) sysadmin work and responsibilities are
>> heavy, and frequently eat into evenings, nights, weekends and
>> (so-called) holidays. Anything which increases the sysadmin workload -
>> e.g. suddenly faced with a vertical learning curve just to do the tasks
>> they did yesterday, or a GUI which leaves them unable to find anything
>> on their screens - is a major issue, and prejudicial not only to the
>> sysadmin's own work, but also to that of the users to whom he/she is
>> responsible. And when you're talking about systems used by hundreds and
>> thousands of users, that's a big problem.
>
> So don't use it then .. EL6 has support until 30 Nov 2020.
>
> SystemD is not 

Re: [CentOS] Just need to vent

[Matthew Miller]

On Tue, Jan 26, 2016 at 04:20:39PM +0100, Sylvain CANOINE wrote:
> Redhat employs Lennart Poettering. Redhat derivates have to follow.

It is true that Red Hat employs Lennart. But, the rest is false. It's
not the way Red Hat works, and it's not the way Fedora works.

-- 
Matthew Miller

Fedora Project Leader
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Chris Adams]

Once upon a time, Peter Duffy  said:
> Ultimately it's all software, and software can be
> written/changed/updated to do anything required - all that's needed is
> the skill and the motivation.

Well sure, and I can build a rig to replace a wheel on your car while
you're driving down the highway; doesn't mean it is practical to do so.
You could also build a distribution with both Linux and FreeBSD kernels
(and IIRC somebody tried with Debian), but that doesn't mean it is a
practical thing, especially for a comercially-supported, long-term
distribution like RHEL.

> If systemd is so "core" that it can't be
> unplugged and plugged easily, and glues together a lot of otherwise
> unrelated components,  then it's just bad software - end of story

Nope.  I said "the init system" is core, not "systemd".  Someone
building a coherent distribution has to make choices about what is
practical to support (and nobody has unlimited man-hours to build magic
tools that can swap out init systems with zero outside impact).  And
once you include systemd, there are features that it makes sense to take
advantage of, rather than ignore because somebody has a "multiple init
systems" requirement.

Sun and Apple already figured out that a "know nothing" super-simple
init didn't handle all that was really needed for a modern OS.  The
Linux world had some earlier attempts, like Upstart (used in RHEL 5 and
6 IIRC), but it never got the critical mass to use its functionality
(and IIRC fairly early on, it became apparent it took some wrong
approaches).

The init system being PID 1 does have a bunch of "magic" abilities on a
Unix-like system, so trying to strip it down to a minimal thing turns
out to not be the best approach.  Of course, a lot of the crap that is
in systemd-the-package (and there is a bunch, although RHEL ignores some
of that at least for now) is not in PID 1.

> - parallel startup of services. Not sure that I'd want that anyway - too
> much risk of two services trying to grab the same resource at the same
> time - I'm absolutely happy with the sysvinit approach of one service
> startup completing/failing before the next one happens. That way, things
> are nice and orderly.

So, the parallel startup has shown a few issues along the way, where
there were undefined dependencies.  There have always been dependency
issues with SysV-style init - service deps can't always be described
properly as an ordered list, more of a directed graph (which systemd's
unit files allow and handle).  Was it annoying if you encountered such a
bug?  Yes, but those types of bugs came up with SysV-style init
repeatedly over the years anyway.  You had poor solutions like init
scripts calling other init scripts to make sure they had the things they
needed (and "soft" deps, like on a database server, were really a mess).

For example, AFAIK it is still the case that RHEL 6 and before don't
enable quotas on a filesystem on an iSCSI device.  The only way to "fix"
that would be to copy all the quota code from rc.sysinit to another,
post-netfs, script.  With systemd, I'm pretty sure the same quota unit
can re-trigger after new filesystems are "discovered".

On the flip side, when I need to add a new one-off service, I can write
a dozen line (or more often less) systemd unit file much easier than
writing an init script.  All the odd corner cases are handled for me, I
don't have to worry about something like daemontools if I want the
service restarted on fail (one line in the unit file), standard out
and/or error can be redirected to log files (without having to pipe to
logger), etc.

> As we all know (don't we just?) sysadmin work and responsibilities are
> heavy, and frequently eat into evenings, nights, weekends and
> (so-called) holidays. Anything which increases the sysadmin workload -
> e.g. suddenly faced with a vertical learning curve just to do the tasks
> they did yesterday

Okay, but change is the only constant in this business.  I agree you
should not be running into the learning curve significantly on
production systems, but if you are running systems with thousands of
users, you should always be looking ahead to new technologies all the
time.  I've always worked in the Internet service provider "world"; when
I started, a T1 and a router you could fit in a backpack made you an
ISP.  Now we have a router that is a third of a rack, requires a lift to
move, with a couple of 10 gig ethernet links to the world, and that's
still considered a "small" ISP.

It is so much easier now to lab up new versions for testing and learning
(just fire up some VMs).  If you want to have an idea of "what is
coming", run some Fedora releases now and then.  I personally have used
Fedora on my desktop since the project started (and Red Hat Linux for
many years before that).

It is called professional education; lots of jobs require you to learn
new skills on an on-going basis.

I've been running CentOS 7 on all my new server installs for a year 

Re: [CentOS] vpn - xl2tpd and routing to a net?

[John R Pierce]

On 1/26/2016 5:37 AM, lejeczek wrote:


I'm having a, I'd like to think a "regular" VPN with IPsec/xl2tpd and 
it all works OK, except..
One thing that I never needed but now I do and I wonder is it my 
iptables, or/and routing or maybe VPN server config..?


vpn clients with established tunnels can get to VPN server's NICs/IPs 
but cannot get through to the net behind the server.
Well... they can, but only if on a host (eg. 192.168.2.33) on VPN 
server's net I do:


route add -host 192.168.2.10 gw 192.168.2.100# 192.168.2.10 is VPN 
client


I thought this I'd not need since that local net (eg. 192.168.2.33) 
use VPN server's 192.168.2.100 as the default gw.


is it by design and nature of that VPN solution it works this way or I 
actually have missed/messed up something?
I hope the latter and adding routing on per "to host" basis is redundant. 



your VPN client shouldn't be on the same subnet as your LAN.your LAN 
hosts expect 192.168.2.10 to be a local address and not to have to use 
the gateway. you probably could make this work with some sort of 
proxy arp but ugh, bridged VPNs are problematic.




--
john r pierce, recycling bits in santa cruz

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Always Learning]

On Tue, 2016-01-26 at 09:11 -0500, Matthew Miller wrote:

> Definitely. But please don't show up ranting about systemd unless you
> genuinely have something new and insightful to add. We have literally
> been discussing moving to an improved init system since 2005:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/Y6PUIY3HOPVKA5IUJQ5TL6WAVTE3G4KY/
> and in that decade, pretty much everything to be said _has_ been said
> and considered. That is, we've *been through* the independent analysis
> of systemd.

Is systemd the beneficial, reliable, useful and workable "improved init
system" or something with circa 275,000 lines of coding compared to
init's circa 10,000 lines ?  Things I have learned in programming
include modular is better than monolithic, and less code better than
M$-style bloatware which systemd appears to be.

Just what is Fedora's and Red Hat's Plan B when the revolt against
systemd escalates ?   Whom is going to apologise for fouling-up Red
Hat's EL and our beloved Centos ?



-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Johnny Hughes]

On 01/26/2016 10:33 AM, Always Learning wrote:
> 
> On Tue, 2016-01-26 at 09:11 -0500, Matthew Miller wrote:
> 
>> Definitely. But please don't show up ranting about systemd unless you
>> genuinely have something new and insightful to add. We have literally
>> been discussing moving to an improved init system since 2005:
>> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/Y6PUIY3HOPVKA5IUJQ5TL6WAVTE3G4KY/
>> and in that decade, pretty much everything to be said _has_ been said
>> and considered. That is, we've *been through* the independent analysis
>> of systemd.
> 
> Is systemd the beneficial, reliable, useful and workable "improved init
> system" or something with circa 275,000 lines of coding compared to
> init's circa 10,000 lines ?  Things I have learned in programming
> include modular is better than monolithic, and less code better than
> M$-style bloatware which systemd appears to be.
> 
> Just what is Fedora's and Red Hat's Plan B when the revolt against
> systemd escalates ?   Whom is going to apologise for fouling-up Red
> Hat's EL and our beloved Centos ?
> 
> 
> 

There is no plan B .. use it or use something else.  Its not like
Debian, Ubuntu, SUSE have decided to not use systemd.

EL6 is good for 4 more years, it does not have systemd.

BSD doesn't use systemd.

systemd is even more important with containers.

That's just how it is.  If people don't like what Linux does to the
kernel .. they can fork it and do something else.  If people don't like
systemd .. they can fork it and do something else.  That's what open
source is all about.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Matthew Miller]

On Tue, Jan 26, 2016 at 04:33:49PM +, Always Learning wrote:
> Is systemd the beneficial, reliable, useful and workable "improved init
> system" or something with circa 275,000 lines of coding compared to
> init's circa 10,000 lines ?  Things I have learned in programming
> include modular is better than monolithic, and less code better than
> M$-style bloatware which systemd appears to be.

This is a typical comment which clearly indicates very little actual
knowledge of systemd. There's really not much to say other than that.


> Just what is Fedora's and Red Hat's Plan B when the revolt against
> systemd escalates ?   Whom is going to apologise for fouling-up Red
> Hat's EL and our beloved Centos ?

Well, that's certainly dramatic.

But the answer is simple: show us the code. If it "escalates" to the
point where we have better options, that's a huge win for everyone.

-- 
Matthew Miller

Fedora Project Leader
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] vpn - xl2tpd and routing to a net?

[lejeczek]

On 26/01/16 16:26, John R Pierce wrote:

On 1/26/2016 5:37 AM, lejeczek wrote:


I'm having a, I'd like to think a "regular" VPN with 
IPsec/xl2tpd and it all works OK, except..
One thing that I never needed but now I do and I 
wonder is it my iptables, or/and routing or maybe VPN 
server config..?


vpn clients with established tunnels can get to VPN 
server's NICs/IPs but cannot get through to the net 
behind the server.
Well... they can, but only if on a host (eg. 
192.168.2.33) on VPN server's net I do:


route add -host 192.168.2.10 gw 192.168.2.100# 
192.168.2.10 is VPN client


I thought this I'd not need since that local net (eg. 
192.168.2.33) use VPN server's 192.168.2.100 as the 
default gw.


is it by design and nature of that VPN solution it works 
this way or I actually have missed/messed up something?
I hope the latter and adding routing on per "to host" 
basis is redundant. 



your VPN client shouldn't be on the same subnet as your 
LAN. your LAN hosts expect 192.168.2.10 to be a local 
address and not to have to use the gateway. you 
probably could make this work with some sort of proxy arp 
but ugh, bridged VPNs are problematic.




after I mailed my message I did play around with it this 
exact way, it works and is the simplest way, most likely the 
proper way.

thanks
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Chris Adams]

Once upon a time, Always Learning  said:
> Is systemd the beneficial, reliable, useful and workable "improved init
> system" or something with circa 275,000 lines of coding compared to
> init's circa 10,000 lines ?  Things I have learned in programming
> include modular is better than monolithic, and less code better than
> M$-style bloatware which systemd appears to be.

You should also have learned in programming the lines of code is a
virtually useless measuring stick.  OMG, the kernel has over four
million lines of code!  BREAK IT UP!

There is always a trade-off between modularity and functionality.
Sometimes modularity comes with a functionality and/or complexity cost.
PID 1 on a Unix-like system really does have special properties, and so
some functionality can only be implemented (at least in a practical
fashion) in PID 1.

Would you rather a bunch of that "magic" of PID 1 that systemd handles
get shoved into the kernel (so that PID 1 isn't so special)?

> Just what is Fedora's and Red Hat's Plan B when the revolt against
> systemd escalates ?   Whom is going to apologise for fouling-up Red
> Hat's EL and our beloved Centos ?

Yawn.  I haven't seen that there's a "revolt" except for a vocal
minority.  Some of the "no change" arguments sound very much similar to
the SELinux, xfs/ext4/ext3, Apache 2, gcc/egcs, glibc, ELF, etc.
arguments over the years.  A vocal group doesn't like change, argues
against it, and presents itself as the voice of the silent majority
(that somehow keep upgrading to new versions with all the terrible
changes).

-- 
Chris Adams 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Matthew Miller]

On Tue, Jan 26, 2016 at 10:40:13AM -0600, Johnny Hughes wrote:
> There is no plan B .. use it or use something else.  Its not like
> Debian, Ubuntu, SUSE have decided to not use systemd.

Or, to put it another way, systemd _is_ plan B. Plan A was upstart. If
plan C comes along and is even better, that's pretty much what Fedora
is all about. If you want to put the work into making it so, make
something, and come to Fedora and advocate for it -- just like Lennart
did six years ago.


-- 
Matthew Miller

Fedora Project Leader
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Johnny Hughes]

On 01/26/2016 10:49 AM, Matthew Miller wrote:
> On Tue, Jan 26, 2016 at 10:40:13AM -0600, Johnny Hughes wrote:
>> There is no plan B .. use it or use something else.  Its not like
>> Debian, Ubuntu, SUSE have decided to not use systemd.
> 
> Or, to put it another way, systemd _is_ plan B. Plan A was upstart. If
> plan C comes along and is even better, that's pretty much what Fedora
> is all about. If you want to put the work into making it so, make
> something, and come to Fedora and advocate for it -- just like Lennart
> did six years ago.
> 
> 

Right.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] bash: Samba: command not found

[Johnny Hughes]

On 01/24/2016 01:05 PM, Henry McLaughlin wrote:
> I have installed Sernet Samba however after installation I cannot confirm
> the version:
> 
> samba -V
> bash: samba: command not found

While some people on this list might use the sernet same packages .. and
some of the sernet guys MIGHT even be on this message list, I wouldn't
necessarily expect to find the best answers here for that question.

That software is not provided by CentOS, so you should expect to get
much better answers for it from their community resources.




signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] vpn - xl2tpd and routing to a net?

[Gordon Messmer]

On 01/26/2016 05:37 AM, lejeczek wrote:
vpn clients with established tunnels can get to VPN server's NICs/IPs 
but cannot get through to the net behind the server.
Well... they can, but only if on a host (eg. 192.168.2.33) on VPN 
server's net I do:


route add -host 192.168.2.10 gw 192.168.2.100# 192.168.2.10 is VPN 
client 


If the VPN isn't hosted on the device with the default gateway, then 
that route should be added to the gateway device.  Proxy arp is an 
option if you use addresses in the same broadcast domain, but adding a 
route in the gateway device should work for all configurations.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] vpn - xl2tpd and routing to a net?

[John R Pierce]

On 1/26/2016 9:14 AM, Gordon Messmer wrote:

On 01/26/2016 05:37 AM, lejeczek wrote:
vpn clients with established tunnels can get to VPN server's NICs/IPs 
but cannot get through to the net behind the server.
Well... they can, but only if on a host (eg. 192.168.2.33) on VPN 
server's net I do:


route add -host 192.168.2.10 gw 192.168.2.100# 192.168.2.10 is 
VPN client 


If the VPN isn't hosted on the device with the default gateway, then 
that route should be added to the gateway device.  Proxy arp is an 
option if you use addresses in the same broadcast domain, but adding a 
route in the gateway device should work for all configurations.



not in this case, because a random host like 192.168.2.33 thinks the 
remote VPN client 192.168.2.10 is on the same LAN, so it wouldn't even 
forward the packet to the gateway unless the gateway responds to the ARP 
for 192.168.2.10


--
john r pierce, recycling bits in santa cruz

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Always Learning]

On Tue, 2016-01-26 at 10:47 -0600, Chris Adams wrote:

> Would you rather a bunch of that "magic" of PID 1 that systemd handles
> get shoved into the kernel (so that PID 1 isn't so special)?

Why should the systemd monolithic bloatware be shoved into the kernel,
especially when you claim the kernel has "over four million lines of
code!" ?

Seems like a tactical diversion to deflect genuine concerns about the
vast plethora of alleged systemd advantages.

When something new is proposed and it is substantially and conspicuously
superior, then everyone wants it. Never noticed that enthusiasm with
systemd's imposition - an imposition nurtured and promoted by the
non-everyday business work environment of experimental Fedora.

Most dedicated users of RHEL and Centos, Scientific Linux too, want
stability which includes not changing everything every 6 months (á la
Fedora) or learning alternative methods of doing well mastered tasks (á
la Systemd - does the 'd' stand for dunce ?)

Good things quickly and easily attract supporters yet systemd lacks the
hordes of anxious and eager users demanding systemd replaces the
fundamentals of their smooth working computer systems. 

Instead we have a few systemd-ers, avoiding the contentious absence of
adequate discussion before the systemd imposition, trying to hypnotise
us into loving their systemd. Meanwhile those who adore stability and
dislike bloatware worry about convoluting systemd tentacles protruding
into their well-running systems.  One dreads a systemd malfunctioning
especially when everything could become inoperable.

> A vocal group doesn't like change, argues against it, and presents
>  itself as the voice of the silent majority (that somehow keep
>  upgrading to new versions with all the terrible changes).

I genuinely and consistently embrace improvements. I remain unconvinced
system-dunce fulfils my change-advantage criteria.



-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[Warren Young]

On Jan 26, 2016, at 8:20 AM, Sylvain CANOINE  
wrote:
> 
>> * track process lifecycle, and restart (or take other action) on
>> failure. (If software were perfect, this wouldn't be needed, but as
>> is, this can save you being paged in the middle of the night.)
> 
> No. A software which falls down is buggy, and needs to be fixed. Period.

What makes you think that having a supervisor makes you ignore problems?

First off, a restarted daemon process is likely going to lose some kind of 
runtime state.  Logged in users will be bounced out, work may be lost, etc.  
You will get calls about this.

Second, it’s not like systemd invented this idea and is now trying to convince 
the rest of the world that it’s a good one.  systemd was preceded by launchd, 
xinetd, inetd, Erlang supervisors…  My company has prior art on that, for that 
matter, and I assure you, we don’t just ignore spontaneously restarting servers.

All a supervisor does is replace human working time — “service badboy restart” 
— with a tiny slice of computer time, reducing the impact of the downed 
service.  If the daemon doesn’t immediately fail again, the total downtime 
charged against that daemon might be a fraction of a second.

Yes, you still have to fix the underlying problem.  But are you saying it would 
be better if your users were completely shut out while emails made their way 
through the tech support loop?

> will just make GNU/linux more unstable.

Then explain why Ericsson’s Erlang-based AXD301 telephone switching system 
achieved *nine* nines of uptime, in large part due to a supervisory process 
restarting framework:

  https://pragprog.com/articles/erlang

If the supervisors were just restarting frequently-dying processes, don’t you 
think all the Ericsson based telephone systems in the world would be noticeably 
less reliable than, say, the AT ones?

>> * actually securely connect output to the process it came from for
>> logging -- both stdout/stderr and actual log messages. (This is why
>> journald is closely integrated.)
> 
> Driving sysadmins unable to read logs just because the file is corrupted, or 
> to send logs to a dedicated server, is a real security improvement, indeed.

Well, in fact, mirroring logs to a trapdoor log server *is* a good security 
practice.  It makes auditing a pwned system much less uncertain.

I’m no huge systemd defender.  It reeks of second system effects, god modules, 
and other antipatterns of software design.  However, this is not the place to 
fix it or replace it.

I’m here because I have no intention of fixing it or replacing it.

Archimedes said he could move the world given a long enough lever and a firm 
place to stand.  Maybe you think this mailing list is your lever of change, but 
you’ve forgotten that you also need a firm place to stand.  All the force you 
put on that level will just push you out of position, rather than move your 
target.

You need a firmer place to stand.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] system refuses to install monit.

[Jason Welsh]

_**_So I have epel enabled on this centos 6 server, but
yum -y install monit will not install monit.
yum search monit does not show monit as available to be installed.


[root@lb1 ~]# yum install monit
Loaded plugins: fastestmirror, presto
Setting up Install Process
Loading mirror speeds from cached hostfile
 * base: mirror-centos.hostingswift.com
 * epel: reflector.westga.edu
 * extras: mirrors.usinternet.com
 * updates: mirrors.usinternet.com
No package monit available.
Error: Nothing to do

If I download the rpm manually and try to localinstall it, it will not 
install..


[root@mb1 ~]# cat /etc/centos-release
CentOS release 6.7 (Final)
[root@lb1 ~]# rpm -qa | grep monit
[root@lb1 ~]# uname -m
x86_64
[root@lb1 ~]# ls -al monit-5.14-1.el6.x86_64.rpm
-rw-r--r-- 1 root root 267556 Sep 13 13:45 monit-5.14-1.el6.x86_64.rpm
[root@lb1 ~]# yum -v  localinstall monit-5.14-1.el6.x86_64.rpm
Loading "fastestmirror" plugin
Loading "presto" plugin
Config time: 0.036
Yum Version: 3.2.29
Setting up Local Package Process
rpmdb time: 0.000
Examining monit-5.14-1.el6.x86_64.rpm: monit-5.14-1.el6.x86_64
Excluding monit-5.14-1.el6.x86_64
Nothing to do
[root@lb1 ~]#

???!?!?

I did a rpm -i of the file and that seems to install the file.. but why 
will it not install with  yum?


Jason


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Enable_extended_ACL_support_in_smb.conf

[Henry McLaughlin]

I am not 100% clear as to when the following is required in smb.conf on a
member server:

   vfs objects = acl_xattr
   map acl inherit = yes
   store dos attributes = yes

https://wiki.samba.org/index.php/Shares_with_Windows_ACLs#Enable_extended_ACL_support_in_smb.conf

I have confirmed Samba is compiled with ACL support:
[root@centos7member ~]# smbd -b | grep HAVE_LIBACL
   HAVE_LIBACL
[root@centos7member ~]#
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] system refuses to install monit.

[Frank Cox]

On Tue, 26 Jan 2016 14:06:37 -0500
Jason Welsh wrote:

>  did a rpm -i of the file and that seems to install the file.. but why 
> will it not install with  yum?

Check /etc/yum.conf.  You probably have that listed on an exclude line.

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Enable_extended_ACL_support_in_smb.conf

[Henry McLaughlin]

On 27 January 2016 at 06:06, Henry McLaughlin  wrote:

> I am not 100% clear as to when the following is required in smb.conf on a
> member server:
>
>vfs objects = acl_xattr
>map acl inherit = yes
>store dos attributes = yes
>
>
> https://wiki.samba.org/index.php/Shares_with_Windows_ACLs#Enable_extended_ACL_support_in_smb.conf
>
> I have confirmed Samba is compiled with ACL support:
> [root@centos7member ~]# smbd -b | grep HAVE_LIBACL
>HAVE_LIBACL
> [root@centos7member ~]#
>

Apologies. Wrong list.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] system refuses to install monit.

[Jason Welsh]

guilty as charged... ugh.. thanks! ;)

Jason


Check /etc/yum.conf.  You probably have that listed on an exclude line.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] vpn - xl2tpd and routing to a net?

[Gordon Messmer]

On 01/26/2016 09:19 AM, John R Pierce wrote:

not in this case


You're right, of course.  Someday I'll learn to just stay quiet when I'm 
tired. :)

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS-es] [VirtualBox] No aparece boton de apagar Windows

[angel jauregui]

Buenas.

Uso CentOS 6 y he montado Windows 7 en una VirtualBox en la cuenta del
usuairio "admin", y al iniciarla me topo conque no puedo apagar el equipo
desde el entorno de Windows :S, no me sale el "inicio / Apagar". Es un
fastidio porque siempre que el de soporte se conecta via RemoteDesktop al
Windows en la VirtualBox y pone alguna actualizacion me pide que la
reinicie porque no da la opcion :S

Alguien que sepa como habilitar el boton ?



-- 
M.S.I. Angel Haniel Cantu Jauregui.

Celular: (011-52-1)-899-871-17-22
E-Mail: angel.ca...@sie-group.net
Web: http://www.sie-group.net/
Cd. Reynosa Tamaulipas.
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

[CentOS-es] odoo

[Mauricio Pastorini]

Buenas tardes, tengo un VPS con Centos 6.7 y WHM estoy tratando de instalar
odoo v 9 y tengo problemas con python 2.7 y nodejs-clean-css

alguna experiencia al respecto. ?

gracias

-- 
*Mauricio Pastorini Torres*
Ingeniero Civil Informático
*Sistemas de Gestión Online Ltda.*
http://www.gestion-online.cl
twitter: *@mauricio1964*
E-Mail: mpastor...@soporte-online.cl 
*+56 9  7439*
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS-es] [VirtualBox] No aparece boton de apagar Windows

[Oscar Osta Pueyo]

Hola,
Siendo un tema windows, www.google.com.
El dia 26/01/2016 9:39 p. m., "angel jauregui"  va
escriure:

> Buenas.
>
> Uso CentOS 6 y he montado Windows 7 en una VirtualBox en la cuenta del
> usuairio "admin", y al iniciarla me topo conque no puedo apagar el equipo
> desde el entorno de Windows :S, no me sale el "inicio / Apagar". Es un
> fastidio porque siempre que el de soporte se conecta via RemoteDesktop al
> Windows en la VirtualBox y pone alguna actualizacion me pide que la
> reinicie porque no da la opcion :S
>
> Alguien que sepa como habilitar el boton ?
>
>
>
> --
> M.S.I. Angel Haniel Cantu Jauregui.
>
> Celular: (011-52-1)-899-871-17-22
> E-Mail: angel.ca...@sie-group.net
> Web: http://www.sie-group.net/
> Cd. Reynosa Tamaulipas.
> ___
> CentOS-es mailing list
> CentOS-es@centos.org
> https://lists.centos.org/mailman/listinfo/centos-es
>
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS-es] [VirtualBox] No aparece boton de apagar Windows

[David González Romero]

Porque usas VirtualBox que no es nativo de Linux aunque tenga una
versión Linux??? Porque no usar kvm o qemu??

Saludos,
David

El día 26 de enero de 2016, 17:39, angel jauregui
 escribió:
> Buenas.
>
> Uso CentOS 6 y he montado Windows 7 en una VirtualBox en la cuenta del
> usuairio "admin", y al iniciarla me topo conque no puedo apagar el equipo
> desde el entorno de Windows :S, no me sale el "inicio / Apagar". Es un
> fastidio porque siempre que el de soporte se conecta via RemoteDesktop al
> Windows en la VirtualBox y pone alguna actualizacion me pide que la
> reinicie porque no da la opcion :S
>
> Alguien que sepa como habilitar el boton ?
>
>
>
> --
> M.S.I. Angel Haniel Cantu Jauregui.
>
> Celular: (011-52-1)-899-871-17-22
> E-Mail: angel.ca...@sie-group.net
> Web: http://www.sie-group.net/
> Cd. Reynosa Tamaulipas.
> ___
> CentOS-es mailing list
> CentOS-es@centos.org
> https://lists.centos.org/mailman/listinfo/centos-es
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS-es] [VirtualBox] No aparece boton de apagar Windows

[Rhamyro Alcoser A.]

De pronto, Reinicia al Windows Vía comando. mas rápido. shutdown -r -f -t 0

El 26 de enero de 2016, 16:49, Oscar Osta Pueyo
escribió:

> Hola,
> Siendo un tema windows, www.google.com.
> El dia 26/01/2016 9:39 p. m., "angel jauregui"  va
> escriure:
>
> > Buenas.
> >
> > Uso CentOS 6 y he montado Windows 7 en una VirtualBox en la cuenta del
> > usuairio "admin", y al iniciarla me topo conque no puedo apagar el equipo
> > desde el entorno de Windows :S, no me sale el "inicio / Apagar". Es un
> > fastidio porque siempre que el de soporte se conecta via RemoteDesktop al
> > Windows en la VirtualBox y pone alguna actualizacion me pide que la
> > reinicie porque no da la opcion :S
> >
> > Alguien que sepa como habilitar el boton ?
> >
> >
> >
> > --
> > M.S.I. Angel Haniel Cantu Jauregui.
> >
> > Celular: (011-52-1)-899-871-17-22
> > E-Mail: angel.ca...@sie-group.net
> > Web: http://www.sie-group.net/
> > Cd. Reynosa Tamaulipas.
> > ___
> > CentOS-es mailing list
> > CentOS-es@centos.org
> > https://lists.centos.org/mailman/listinfo/centos-es
> >
> ___
> CentOS-es mailing list
> CentOS-es@centos.org
> https://lists.centos.org/mailman/listinfo/centos-es
>



-- 

*Rhamyro Alcoser A.*

*ITIL & Systems Development*

*Mailto1:* rhamyr...@gmail.com

*Mailto2:* rhamyr...@icloud.com 

*Skype: *rhamyr...@outlook.com 

*Quito - Ecuador *


*¿Qué, pues, diremos a esto? Si Dios es por nosotros, ¿quién contra
nosotros?, Rm 8:31*
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS-es] [VirtualBox] No aparece boton de apagar Windows

[angel jauregui]

Gracias por su respuesta, pero debido a que los que dan uso de los
programas que estan en el Windows 7 virtualizado dentro de CentOS no puedo
forzarlos a que hagan algo que para mi gusto lo haria por comando. Ya
saben, lo primero que me dicen "porque no esta el boton de apagar en inicio
?? podrias ponerselo es que no puedo apagar el equipo"

Asi que vuelvo a preguntarles, alguien de casualidad sabe como colocar ese
boton ??? porque me imagino es por culpa del VirtualBox, no creo que sea
por el lado de Windows !???



El 26 de enero de 2016, 16:02, Rhamyro Alcoser A. 
escribió:

> De pronto, Reinicia al Windows Vía comando. mas rápido. shutdown -r -f -t 0
>
> El 26 de enero de 2016, 16:49, Oscar Osta Pueyo
> escribió:
>
> > Hola,
> > Siendo un tema windows, www.google.com.
> > El dia 26/01/2016 9:39 p. m., "angel jauregui" 
> va
> > escriure:
> >
> > > Buenas.
> > >
> > > Uso CentOS 6 y he montado Windows 7 en una VirtualBox en la cuenta del
> > > usuairio "admin", y al iniciarla me topo conque no puedo apagar el
> equipo
> > > desde el entorno de Windows :S, no me sale el "inicio / Apagar". Es un
> > > fastidio porque siempre que el de soporte se conecta via RemoteDesktop
> al
> > > Windows en la VirtualBox y pone alguna actualizacion me pide que la
> > > reinicie porque no da la opcion :S
> > >
> > > Alguien que sepa como habilitar el boton ?
> > >
> > >
> > >
> > > --
> > > M.S.I. Angel Haniel Cantu Jauregui.
> > >
> > > Celular: (011-52-1)-899-871-17-22
> > > E-Mail: angel.ca...@sie-group.net
> > > Web: http://www.sie-group.net/
> > > Cd. Reynosa Tamaulipas.
> > > ___
> > > CentOS-es mailing list
> > > CentOS-es@centos.org
> > > https://lists.centos.org/mailman/listinfo/centos-es
> > >
> > ___
> > CentOS-es mailing list
> > CentOS-es@centos.org
> > https://lists.centos.org/mailman/listinfo/centos-es
> >
>
>
>
> --
>
> *Rhamyro Alcoser A.*
>
> *ITIL & Systems Development*
>
> *Mailto1:* rhamyr...@gmail.com
>
> *Mailto2:* rhamyr...@icloud.com 
>
> *Skype: *rhamyr...@outlook.com 
>
> *Quito - Ecuador *
>
>
> *¿Qué, pues, diremos a esto? Si Dios es por nosotros, ¿quién contra
> nosotros?, Rm 8:31*
> ___
> CentOS-es mailing list
> CentOS-es@centos.org
> https://lists.centos.org/mailman/listinfo/centos-es
>



-- 
M.S.I. Angel Haniel Cantu Jauregui.

Celular: (011-52-1)-899-871-17-22
E-Mail: angel.ca...@sie-group.net
Web: http://www.sie-group.net/
Cd. Reynosa Tamaulipas.
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

[CentOS-announce] CESA-2016:0067 Important CentOS 6 java-1.6.0-openjdk Security Update

[Johnny Hughes]

CentOS Errata and Security Advisory 2016:0067 Important

Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-0067.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
8df06a899e26a7520bdeb3b4db31a8fe4c4686e10b2fefde977664de9c7fb658  
java-1.6.0-openjdk-1.6.0.38-1.13.10.0.el6_7.i686.rpm
b645b00280c6b2df08eff4b3ea35f7c5dadffd5c261cfab385aaf9b1b9f37c39  
java-1.6.0-openjdk-demo-1.6.0.38-1.13.10.0.el6_7.i686.rpm
1a3a289f87f54ac2e0b351171f969e10c18f2b7f9068b37ffb962ecf3e5f2480  
java-1.6.0-openjdk-devel-1.6.0.38-1.13.10.0.el6_7.i686.rpm
bcae5c7e8520c7462c383d629d5e74047e2ce5991b7ac22f36ac035f0fc33000  
java-1.6.0-openjdk-javadoc-1.6.0.38-1.13.10.0.el6_7.i686.rpm
30a96ce89d2188f1ee96309dfd9ba72f37c77d3d8cc924baf3dcd25ae786d5f7  
java-1.6.0-openjdk-src-1.6.0.38-1.13.10.0.el6_7.i686.rpm

x86_64:
dc8020c01029080793f7a80ee11ff7b8aa692ee3e5d27b36281d54f5e1a3  
java-1.6.0-openjdk-1.6.0.38-1.13.10.0.el6_7.x86_64.rpm
8090ed5219f8f569c4fb0dc94242b0fcfe62415de1089b1a99ade591102ba088  
java-1.6.0-openjdk-demo-1.6.0.38-1.13.10.0.el6_7.x86_64.rpm
7f3c15ee1836066bad87abca524b4af50cc449f51f7ef5a248f4f3db2b2d62af  
java-1.6.0-openjdk-devel-1.6.0.38-1.13.10.0.el6_7.x86_64.rpm
4ac324c5649d25af27d90af2b6310924c029ac7063f922a43e946969051cc92b  
java-1.6.0-openjdk-javadoc-1.6.0.38-1.13.10.0.el6_7.x86_64.rpm
0b05e4b8e47cf5c7e6d7daf23c9eb8ab620ac85840dbc6d4d50bf5c4a4aa9743  
java-1.6.0-openjdk-src-1.6.0.38-1.13.10.0.el6_7.x86_64.rpm

Source:
5caca590014371e8066406ef364651473a52b86e7fc56f33acbef9d9b9aa2d80  
java-1.6.0-openjdk-1.6.0.38-1.13.10.0.el6_7.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

[CentOS-announce] CESA-2016:0067 Important CentOS 5 java-1.6.0-openjdk Security Update

[Johnny Hughes]

CentOS Errata and Security Advisory 2016:0067 Important

Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-0067.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
a564cd9490be5ab97d050c1a1cee2090f315dc6e8993c3bb57fac0c732c6a3d3  
java-1.6.0-openjdk-1.6.0.38-1.13.10.0.el5_11.i386.rpm
1e6e6102a88e6f8d1d99ba513f5d5bd27445c08ac35606126330dcb7eb309d8b  
java-1.6.0-openjdk-demo-1.6.0.38-1.13.10.0.el5_11.i386.rpm
5c5f8fed0f9e6ea7f009fa5db9f1d8517160a68470d5fa42d3b5964c730e1e12  
java-1.6.0-openjdk-devel-1.6.0.38-1.13.10.0.el5_11.i386.rpm
e3a65df6870d94b0be2553dabb647892d44564fc25ce7f091a50e711fb1bb6a3  
java-1.6.0-openjdk-javadoc-1.6.0.38-1.13.10.0.el5_11.i386.rpm
7596230198a5fc3d7149f94becde9cc1166f03b7d664500df33bae23ea67  
java-1.6.0-openjdk-src-1.6.0.38-1.13.10.0.el5_11.i386.rpm

x86_64:
65e34e63b9a6d16a8019e1e7027d41438ae81722373d5847c94a0ee879a5478b  
java-1.6.0-openjdk-1.6.0.38-1.13.10.0.el5_11.x86_64.rpm
3018d3ea3b1a291928891409ac60be0120863848ded1f271cc2b6a332a45b102  
java-1.6.0-openjdk-demo-1.6.0.38-1.13.10.0.el5_11.x86_64.rpm
276a82950dbe20324ce1322cf2cd781466b8a0b8a155b6d7f7f46a0bce2e76d9  
java-1.6.0-openjdk-devel-1.6.0.38-1.13.10.0.el5_11.x86_64.rpm
dc3173332668d4a3a75894c73ed938cf558592d49cc3e18c86e03a92ad776ba8  
java-1.6.0-openjdk-javadoc-1.6.0.38-1.13.10.0.el5_11.x86_64.rpm
e14622d70222762fad88e2f2238e6ae27c8f630e0ed29dbd78c19e0d2d0fb329  
java-1.6.0-openjdk-src-1.6.0.38-1.13.10.0.el5_11.x86_64.rpm

Source:
67daf7f23cfdf1dc5aecdd9d6e1fdaedf77d3863445da21200f52628ec412953  
java-1.6.0-openjdk-1.6.0.38-1.13.10.0.el5_11.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

[CentOS-announce] CESA-2016:0067 Important CentOS 7 java-1.6.0-openjdk Security Update

[Johnny Hughes]

CentOS Errata and Security Advisory 2016:0067 Important

Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-0067.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
6d2a9fcd8c0047fbf75850d6f87916da874d826cd045fd282624d4e2c9027e2a  
java-1.6.0-openjdk-1.6.0.38-1.13.10.0.el7_2.x86_64.rpm
fc340ba9fdf41498a57f1e855c5ef4d914b1bf02dda5c3532efecdb721fbb64b  
java-1.6.0-openjdk-demo-1.6.0.38-1.13.10.0.el7_2.x86_64.rpm
d20b7ecea5d222dd53a8795dd24ef962e6fea3e12169dabaa09408fb99c6f96f  
java-1.6.0-openjdk-devel-1.6.0.38-1.13.10.0.el7_2.x86_64.rpm
88daac1696331dc127050b86ead11f1e1311b630f2e8cb0105e09c54293b2a22  
java-1.6.0-openjdk-javadoc-1.6.0.38-1.13.10.0.el7_2.x86_64.rpm
a2e0e4314c57c089bd5a0269b43dd4f90225f689c3cf31ade4445959c8d44c72  
java-1.6.0-openjdk-src-1.6.0.38-1.13.10.0.el7_2.x86_64.rpm

Source:
93a4207025786c507681644aeb2d0b477bc7ff567c95a7275df008576d8a61dc  
java-1.6.0-openjdk-1.6.0.38-1.13.10.0.el7_2.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

Re: [CentOS] Just need to vent

[John Hodrien]

On Tue, 26 Jan 2016, Peter Duffy wrote:


No one is saying that sysvinit is perfect. What I can't grasp is why
replace it with something which is no less imperfect, and is almost
certainly worse in at least some respects - and to make that replacement
unavoidable and mandatory.


Distros weighed up the advantages and disadvantages, and made a decision as to
what they thought was best.  They even shared their reasoning.


I'm also still trying to figure out in what way systemd is supposed to
be "better".


https://wiki.debian.org/Debate/initsystem/systemd#Why_Debian_should_default_to_systemd

jh
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Just need to vent

[John Hodrien]

On Tue, 26 Jan 2016, Peter Duffy wrote:


On Tue, 2016-01-26 at 11:57 +, John Hodrien wrote:

On Tue, 26 Jan 2016, Peter Duffy wrote:

https://wiki.debian.org/Debate/initsystem/systemd#Why_Debian_should_default_to_systemd


Might be more convincing if they stuck to reasoned argument, rather than
propaganda. "Systemd is straightforward"; "systemd is incredibly fast (1
second to boot)" - reminds me of first installing windows 95 (by the choice
of my then employer, not me!) and seeing the message that it would
completely change the way I related to my computer.


Skip on by to the functionality arguments.

jh
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos