Re: [CentOS] CentOS 7.5 (1804) and NetworkManager

[James Hogarth]

On 15 May 2018 at 16:55, Michael Lampe  wrote:
> Gnome's control-center now requires NetworkManager-wifi. But it's only a
> soft requirement, no shared libs involved.
>
> To keep your workstation NM-free, you want to install a dummy package that
> provides NetworkManager-wifi but actually contains nothing, ideally before
> updating to 7.5. Here's a script to create such a dummy:
> https://github.com/larsks/fakeprovide
>
> If you do this, control-center shows a sad face and some text (Oops, blah,
> blah, ...) in the WiFi tab. Just the same you always got in the network tab
> without NM. That's all.
>

Note that the 'network' service is considered legacy and gets just basic fixes.

It's not been recommended to disable NetworkManager for years at this point.

Unless you have a really tricky setup with openvswitch or something
like that it's a bad idea to disable NetworkManager at this point in
time.

As yourself why you are doing it, and what you are really hoping to gain.

Have a read of this to get a better grasp on NM:
https://www.hogarthuk.com/?q=node/18
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ansible repository shenanigans in EL7

[James Hogarth]

On 11 April 2018 at 16:11,  <m...@tdiehl.org> wrote:
>
> On 11 Apr 2018 09:48 Fabian Arrotin wrote:
>
>> On 11/04/18 13:58, James Hogarth wrote:
>> > For those not aware ansible has been deprecated in RHEL7 from the extras
>> > repository.
>> > > In the RHEL specific world it's now in an optional "product"
>> > > (basically an
>> > optional subscription) that is part of any RHEL subscription, but it's
>> > opt
>> > in.
>> > > As a result ansible is back in the EPEL7 repository for 2.5.0+ ,
>> > > having
>> > been removed for  ansible 2.4.2 when it got introduced to the  RHEL
>> > extras
>> > repo.
>> > > I have no idea what, if anything, the CentOS team will do with the
>> > > ansible
>> > in the CentOS7 extras repository.
>>
>> That's a good question, as "orphaning" it would be an issue for all
>> people now getting it directly from Extras, if they don't have epel
>> added (also "opt-in")
>>
>> AFAICS, nothing is pushed to git.centos.org anymore for it :
>> https://git.centos.org/summary/rpms!ansible.git
>>
>> So I guess it would be a question for the centos-devel list :
>> - either we orphan it (and the other pkgs required for it) from extras
>> - or we try to build those and continue to provide ansible
>
>
> Does it really matter which repo it comes from?
>
> I would expect the users of ansible to be smart enough to get it from epel
> or extras. As long as we know how to get it I do not see this as a big deal.
>
> It seems that since it is already being built for EPEL, that would be the
> path
> of least resistance for the Centos devs.
>
> Just my $.02
>
> Regards,
>

Copying from the EPEL development list as this is likely to be helpful
to many here, and well be a relief as well:

On 11 April 2018 at 20:32, Dylan Silva <thau...@gmail.com> wrote:
> I am very afraid I am jumping into a lion's den here... However, I am going 
> to try to alleviate some concerns.
>
> Our move from EPEL to Extras was actually to solve for the needs of RHEL and 
> the RHEL System Roles.  We needed to be in a channel that customers could 
> consume from that wasn't EPEL.
>
> Upon our move to Extras, we immediately identified a problem.  That problem 
> was, we Ansible, were not able to release as often as we preferred/needed for 
> our customers.  We also were facing confusion about what did support mean 
> once a package was inside of Extras.
>
> As such, we made the decision to two things.
>
> 1. Deprecate Ansible from Extras.
> 2. Provide access to Ansible via a Red Hat trusted delivery mechanism.
>
> For #2, EPEL obviously is not the route to take for some customers.  So, we 
> decided that all RHEL customers would have full access to the Subscription 
> channel.  We also specified that if a customer wanted support, they would 
> still need to purchase a subscription.
>
> We had a very delicate situation here.  There were a lot of check and 
> balances that had to be met before we could make any announcement. So that's 
> why it has been "a little quiet."
>
> The security advisory link posted above, and this link 
> <https://access.redhat.com/articles/3359651> attempt to cover the bulk of the 
> possible questions that may arise.
>
> That being said, we still aim to provide our customers/users the ability to 
> obtain Ansible any way they choose.  So if the user does not want to use the 
> channel or cannot use it for any reason, they still have the ability to pull 
> from EPEL or our releases.ansible.com pages. As far as we're concerned, it is 
> functionally the same application no matter where it comes from.. If a 
> customer has a subscription; they will be supported.
>
> I, the Product Manager of Ansible Engine, am staying on top of these concerns 
> as they come by.  So far, no huge customer/user concerns have caused any 
> alarm.  Most users have embraced the moves, and have continued to automate.

Source: 
https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/message/PFQDMUDCKUU6RLL4SVQP3ENU6I7RYRQO/
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ansible repository shenanigans in EL7

[James Hogarth]

On 11 April 2018 at 15:39, Leon Fauster  wrote:
>
>> Am 11.04.2018 um 15:48 schrieb Fabian Arrotin :
>> ...
>> - or we try to build those and continue to provide ansible
>
> +1
>

Honestly I think that would get even more confusing at that point if
CentOS Extras has it when RHEL Extras no longer will ... and "RHEL
Ansible Engine" exists as a product subscription for RHEL users ...
and upstream have their own repos ... and over in Fedora-land we're
building it for EPEL again.

If there really is a desire (understandable) to have a "CentOS
Ansible" then I'd suggest centosplus as the appropriate repo for it
out of the base possibilities.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Ansible repository shenanigans in EL7

[James Hogarth]

For those not aware ansible has been deprecated in RHEL7 from the extras
repository.

In the RHEL specific world it's now in an optional "product" (basically an
optional subscription) that is part of any RHEL subscription, but it's opt
in.

As a result ansible is back in the EPEL7 repository for 2.5.0+ , having
been removed for  ansible 2.4.2 when it got introduced to the  RHEL extras
repo.

I have no idea what, if anything, the CentOS team will do with the ansible
in the CentOS7 extras repository.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Allowing non-root users to reboot a workstation

[James Hogarth]

On 2 February 2018 at 18:13,   wrote:
> Felipe Westfields wrote:
>> I would like to be able to allow regular users that don't have admin
>> privileges to be able to reboot their workstation. (they're software
>> developers so rebooting their workstation doesn't affect anybody else)
>>
>> I tried changing the ownership of /sbin/reboot and /sbin/shutdown to
>> root:users and permissions to 550, but that didn't work - it's still
>> asking
>> for root privileges.
>>
>> Possibly the problem might be that there's centralized LDAP
>> authentication, not local, so the changes I made only apply to
>> local accounts?
>>
>> Any suggestions?
>
> Um, I take it that a three-finger kill doesn't work?
>
>mark
>

You;ll want to look at polkit configuration as that's what is used by
systemd, and by gnome as a result, to determine what actions are
permitted

https://www.hogarthuk.com/?q=node/10
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[James Hogarth]

On 28 November 2017 at 16:06, Johnny Hughes <joh...@centos.org> wrote:
> On 11/28/2017 08:20 AM, James Hogarth wrote:
>> On 28 November 2017 at 13:48, Mark Haney <mark.ha...@neonova.net> wrote:
>>> On 11/28/2017 08:06 AM, Joseph L. Casale wrote:
>>>>
>>>> With a few exceptions, I see most admins treat CentOS as a single
>>>> rolling release and rely on the ABI commitment assuming things
>>>> just work between point releases. On the other hand I see the
>>>> opposite with RHEL where admins constrain installations to the
>>>> point release.
>>>>
>>>> What is the case with users on this list who support both?
>>>
>>>
>>> I can't really speak for anyone else, but for me, a lot depends on the use
>>> of the systems.  I typically treat RHEL and CentOS the same way as far as
>>> updating to the latest point release.  It's never bit me in the past that I
>>> am aware of.
>>>
>>> The only exception to that is with the SGI Altix 4300/4400s I used to
>>> manage.  We migrated from SLES to RHEL and in those cases, barring a serious
>>> enough bug, those boxes were left alone until time came to refresh them,
>>> such as the move from RHEL5 to RHEL6.
>>>
>>>
>>
>>
>> Note that RHEL is a special case as there's some situations companies
>> will pay out for the Extended Update Support (EUS)[0] in order to stay
>> on a particular milestone for longer.
>>
>> In addition there is the slight bonus of access to beta of the next
>> milestone or major release which may affect your workflow if you have
>> a suitable test environment, and of course you'll get the milestone
>> quicker on release so that needs to be paid attention to for testing.
>>
>> Outside of this area the two can be, and should be, treated
>> identically in terms of update policies.
>>
>>
>>
>> [0] https://access.redhat.com/support/policy/updates/errata
>
> And also note that Red Hat does not publicly release the SRPMs for their
> EUS packages.  The CentOS Project therefore can not build those, so
> there is NO EUS in CentOS Linux.  The only way to get Security updates
> in CentOS Linux is to be on the current (latest) point release.
>
> Also, since all updates are built against the current (latest) release
> as they are released, there is no way to get only security updates in
> CentOS Linux.  You could TRY to only install security updates on your
> own .. however, since there are rebases during point releases, things
> that are built against the newer openssl will not work with older ssl's
> OR things build against the newer gnome will not work with older
> gnome's, etc.
>
> The only tested way to run CentOS Linux is with all the updates
> installed together.
>
>
>

Even Red Hat technically on RHEL doesn't "support" only installing
updates marked security as they always have an assumption all previous
errata are applied.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[James Hogarth]

On 28 November 2017 at 13:48, Mark Haney  wrote:
> On 11/28/2017 08:06 AM, Joseph L. Casale wrote:
>>
>> With a few exceptions, I see most admins treat CentOS as a single
>> rolling release and rely on the ABI commitment assuming things
>> just work between point releases. On the other hand I see the
>> opposite with RHEL where admins constrain installations to the
>> point release.
>>
>> What is the case with users on this list who support both?
>
>
> I can't really speak for anyone else, but for me, a lot depends on the use
> of the systems.  I typically treat RHEL and CentOS the same way as far as
> updating to the latest point release.  It's never bit me in the past that I
> am aware of.
>
> The only exception to that is with the SGI Altix 4300/4400s I used to
> manage.  We migrated from SLES to RHEL and in those cases, barring a serious
> enough bug, those boxes were left alone until time came to refresh them,
> such as the move from RHEL5 to RHEL6.
>
>


Note that RHEL is a special case as there's some situations companies
will pay out for the Extended Update Support (EUS)[0] in order to stay
on a particular milestone for longer.

In addition there is the slight bonus of access to beta of the next
milestone or major release which may affect your workflow if you have
a suitable test environment, and of course you'll get the milestone
quicker on release so that needs to be paid attention to for testing.

Outside of this area the two can be, and should be, treated
identically in terms of update policies.



[0] https://access.redhat.com/support/policy/updates/errata
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] ebtables bug

[James Hogarth]

On 22 November 2017 at 10:00, Andrew Radygin  wrote:
> Hi guys!
> I need to deploy this bugfix -
> https://bugzilla.redhat.com/show_bug.cgi?id=1495893 on my servers, but I
> don't want to compile own package. It'll be nice to use official package
> from centos repo.
> Could you please tell me, when this fix will be approved and added to main
> line package ebtables, so I can update it on my systems.
> Thanks!
>


Logging in to the Red Hat portal the most recent ebtables is still
ebtables-2.0.10-15.el7 whereas the bug says it is fixed in
ebtables-2.0.10-16.el7 and is listed as ON_QA.

That usually means it'll be part of the next milestone, 7.5, which
isn't even in beta yet.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to encourage maintainers to update their software

[James Hogarth]

On 29 October 2017 at 13:40, vychytraly .  wrote:
> Frank please could you explain how to create rpms for el7 from fedora
> src.rpms?
>
>

You may find this a useful read:

https://www.hogarthuk.com/?q=node/11
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] which group for running docker as a regular user on CentOS 7

[James Hogarth]

On 26 October 2017 at 10:20, soko.tica  wrote:
> Hi,
>
> I have installed docker and would like to run the containers without sudo.
>
> I have placed myself in dockerroot group, but still to no avail. Centos
> doesn't have the operator group.
>
> What should I do?
>
>

For security reasons the Red Hat and Fedora builds do not enable this
by default.

Accepting the risks and the consequences, you need to update the
DOCKER_OPTS in /etc/sysconfig/docker to include '-G dockerroot' so
that the docker socket gets created with the group dockerroot.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Unable to apply mysqld_db_t to mysql directory

[James Hogarth]

On 23 October 2017 at 19:18, Bernard Fay  wrote:
> Thanks, I managed to fix /var/lib/mysql
>
> # ls -ldZ /var/lib/mysql
> drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
>
> To fix it, I tried:
> semanage fcontext -d -e /var/lib/mysql
> this command returned:
> KeyError: /var/lib/mysql
> I tried restorecon anyway:
> restorecon -Rv /var/lib/mysql
> But not better:
> ls -ldZ /var/lib/mysql
> drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0   /var/lib/mysql
>
> So I did the following:
> semanage fcontext -d -t var_lib_t /var/lib/mysql
> It started to look better:
> ls -ldZ /var/lib/mysql
> drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0   /var/lib/mysql
> Then I ran restorecon
> restorecon -Rv /var/lib/mysql
> I got a lot of :
> restorecon reset /var/lib/mysql/...
>
> And then I got the proper context on /var/lib/mysql.
>
>
> I think there are still many things I do not understand about SELinux.
>
> I thought the equivalence thing I did with the command below was going to
> assign the context of /var/lib/mysql.old to /var/lib/mysql. Obviously not!
> semanage fcontext -a -e /var/lib/mysql.old /var/lib/mysql
>
>

I think you have a slight misconception over how labels are determined.

There's no relation between what is presently on the filesystem when
you do ls -lZ and what the policy database thinks it ought to be.

This is why you can chcon to change the label of something but a
relabelling will change it back.

When you run restorecon to relabel a path what happens is it takes the
absolute (full) path and compares it against the regexes in the
selinux policy database (see it with semanage fcontext -l for some,
but now all, context matches) ...

Then for the most specific match it will apply whatever label is in
that database.

When you do semanage fcontext -a -e /foo /bar to do an alias what you
are telling selinux is that for every time that /bar is run through
the regex replace bar with foo and check that instead.

This is why when adding custom labelling you need to do a full regex
path to match files under that directory too.

When you moved /var/lib/mysql to /var/lib/mysql.old the labels moved
with the files (this is the default unless you cross filesystems, you
can force labelling as the destination with mv -Z).

The selinux database still has /var/lib/mysql(/.*)? as being type
mysqldb_db_t even if that directory doesn't exist.

When the directory is created and put in place then it will get what
policy says is right for that path.

The point of using equivalence is when you move a default location -
such as /home to /data/home or /var/lib/mysql to /data/mysql

In that situation the default selinux policy doesn't know anything
about /data or the contents of it so it'll end up with a default_t
label ... not very useful.

Now you could semanage fcontext -a -t mysqldb_db_t /data/mysql(/.*)?
but quite often the 'story' of a directory tree isn't about just one
label and it'd be tedious trying to match them all ...

For the craziness that is $HOME for instance...

CentOS7: cat /etc/selinux/targeted/contexts/files/file_contexts.homedirs
Fedora: cat /usr/share/selinux/targeted/default/active/homedir_template

There's a lot of different contexts depending on the file in that tree
... trying to mimic them all to move /home to /data/home would be a
nightmare ...

But this is made trivial with semanage fcontext -a -e /home /data/home
to ensure ~/.ssh and ~/.gpg and ~/public_html and so on all get the
right contexts.

So based on that I hope you understand why the equivalence lines you
have left are effectively meaningless - they are not absolute paths
and so can't match a tree to do the labelling replacement.

Does that help make things a bit clearer on your file contexts?

TL:DR; there was no need to "assign" as you were still using the
default mysql DB path, just a restorecon would have solved it.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Unable to apply mysqld_db_t to mysql directory

[James Hogarth]

On 23 Oct 2017 5:26 pm, "Bernard Fay" <bernard@gmail.com> wrote:

Interesting to see the Equivalence. As a first thing, I tried:

semanage fcontext -a -e /var/lib/mysql.old /var/lib/mysql
then
restorecon -R /var/lib/mysql


# semanage fcontext -lC
SELinux fcontext   type
Context

/home/users(/.*)?  all files
system_u:object_r:user_home_dir_t:s0
/var/lib/mysql all files
system_u:object_r:mysqld_db_t:s0
/var/lib/mysql(/.*)?   all files
system_u:object_r:mysqld_db_t:s0

SELinux Local fcontext Equivalence

./mysql = ./mysql.old
/var/lib/mysql = /var/lib/mysql.old
mysql = ./mysql.old




On Mon, Oct 23, 2017 at 10:27 AM, James Hogarth <james.hoga...@gmail.com>
wrote:

> On 23 October 2017 at 13:33, Bernard Fay <bernard@gmail.com> wrote:
> > Hello,
> >
> > A server was configured in /var/lib/myslq in the root fs.  I added a LV
> > specifically for mysql.  I stopped myql and renamed /var/lib/mysql to
> > /var/lib/mysql.old.  I created a new dir /var/lib/mysql and mounted the
> LV
> > on /var/lib/mysql.  I then copied with "cp -prZ" all mysql files in
> > /var/lib/mysql.old to /var/lib/mysql.
> >
> > But then I got a selinux problem:
> > # ls -ldZ mysql.old/ mysql
> > drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0   mysql
> > drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql.old/
> >
> > I tried to changed the context on mysql with the following commands:
> >
> > # semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"
> > # restorecon -R -v /var/lib/mysql
> >
> > But the /var/lib/mysql directory didn't take the change as you can see
> > below:
> > # ls -ldZ mysql.old/ mysql
> > drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0   mysql
> > drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql.old/
> >
> >
> > How can I fix the wrong context on mysql directory?
> > Thanks,
> >
>
> /var/lib/mysql is already in default policy - no need to add anything
there
>
> can you please provide the output of 'semanage fcontext -lC' so that
> we can see any local selinux modifications made?
>
> From base policy with nothing added, for that directory, you *should*
> be able to just restorecon -Rv /var/lib/mysql and have the correct
> labelling.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


The equivalence is what has broken things for you then.

Remember that the source of Truth for labels don't follow the files
themselves.

Looking at that it appears you told selinux that your local config should
have /var/lib/mysql match /var/lib/mysql.old ... note well the ordering
there.

The system policy for the latter will inherit from /var/lib as mysql.old is
not a directory that is in the normal config.

This "local config" making /var/lib/mysql in the policy match
/var/lib/mysql.old is now overriding the default system config ... which is
why restorecon is setting it to var_lib_t and not the mysql type.

If you restorecon on /var/lib/mysql.old this will be evident.

The fix is to semanage fcontext -d -e /var/lib/mysql to remove that
incorrect local equivalence overriding base policy and then to restorecon
-Rv /var/lib/mysql to put in place the correct labels.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Unable to apply mysqld_db_t to mysql directory

[James Hogarth]

On 23 October 2017 at 13:33, Bernard Fay  wrote:
> Hello,
>
> A server was configured in /var/lib/myslq in the root fs.  I added a LV
> specifically for mysql.  I stopped myql and renamed /var/lib/mysql to
> /var/lib/mysql.old.  I created a new dir /var/lib/mysql and mounted the LV
> on /var/lib/mysql.  I then copied with "cp -prZ" all mysql files in
> /var/lib/mysql.old to /var/lib/mysql.
>
> But then I got a selinux problem:
> # ls -ldZ mysql.old/ mysql
> drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0   mysql
> drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql.old/
>
> I tried to changed the context on mysql with the following commands:
>
> # semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"
> # restorecon -R -v /var/lib/mysql
>
> But the /var/lib/mysql directory didn't take the change as you can see
> below:
> # ls -ldZ mysql.old/ mysql
> drwxr-xr-x. mysql mysql system_u:object_r:var_lib_t:s0   mysql
> drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql.old/
>
>
> How can I fix the wrong context on mysql directory?
> Thanks,
>

/var/lib/mysql is already in default policy - no need to add anything there

can you please provide the output of 'semanage fcontext -lC' so that
we can see any local selinux modifications made?

>From base policy with nothing added, for that directory, you *should*
be able to just restorecon -Rv /var/lib/mysql and have the correct
labelling.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Null deference panic in CentOS-6.5

[James Hogarth]

On 18 October 2017 at 15:34, wuzhouhui  wrote:
> Fine, it seems that upgrade kernel is the only effective solution.
>
>

To be as abundantly clear as possible on the matter ... it is not just kernel.

You need to do a full update against the CentOS 6 repositories.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Null deference panic in CentOS-6.5

[James Hogarth]

On 18 October 2017 at 09:50, wuzhouhui  wrote:

> I googled this issue and found so many people have encountered, but most
> of them just said "the newer kernel doesn't have this problem, so upgrade
> kernel". We can't upgrade kernel easily, so we need to *really* solve this
> problem.
>
>
>
No, you really need to rebase your work on current CentOS as you're so far
behind on critical security issues it's just not funny. It also mitigates
any ability for someone to actually help and for any fix to reach you.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemctl reboot -- server not accessible after reboot

[James Hogarth]

On 15 October 2017 at 12:20, Mike <1100...@gmail.com> wrote:

> On Sat, Oct 14, 2017 at 2:29 PM, Vitalino Victor 
> wrote:
> >
> > Try:
> >
> > # shutdown -r now
> >
>
> I'll have to try this late one evening.
> It's a production Samba Active Directory Domain Controller in
> production so it's difficult to do this without warning to users.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

Don't bother ... it makes no difference to how the shutdown happens, this
was nonsense "advice".

The shutdown 'command' is a symlink to systemctl which knows that it is
being called that way and will act on it ... the same as if you did
systemctl reboot

The issue surrounding remote syslog and gathering data on shutdown is that
depending on where the freeze you are experiencing occurs there may not be
any logs at all.

If it occurs before a sync to disk then any logs generated will be lost, if
it occurs after the pivot-root when /var/log is no longer mounted then
similarly any logs generated will be lost.

Of course if it is a *kernel* freeze issue then it is also likely that
whatever is occurring never gets to generate a log event ... as that's hard
to do with a frozen kernel ;)

I assume you've checked for BIOS/firmware updates and applied any pending?

Can you add IPMI (remote/out-of-band access) to that server? You may get
something through hardware event then ... this is why I prefer HP or Dell
kit over picking cheaper options when dealing with corporate needs ...
their iLO and iDRAC implementations are robust and can provide better
diagnosis on things like this with the built in hardware testing etc ...
and avoid a need to walk to a server and plug in a monitor ;)

If you can't set up remote syslog for some reason, or if there's no logs
found to help doing this, then I'd suggest removing rhgb and quiet from
your kernel command line, having a monitor attached at the time you do the
shutdown and monitor the console as you attempt the reboot.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CUDA tools?

[James Hogarth]

On 6 Oct 2017 8:34 am, "John Hodrien"  wrote:

On Fri, 6 Oct 2017, Pete Biggs wrote:

I suppose the epel kmod-nvidia might count - it will allow CUDA apps to
> run but you can't develop with it.
>

The ELRepo drivers are just the drivers, not the SDK.  That said, my
experience is they're packaged much better than the ones nVidia releases as
part of the CUDA repo.

The approach I've gone with is to use ELRepo for the drivers, and then use
environment modules to provide the CUDA SDK to users.  That for me offers
little downsides.  You easily get to provide multiple releases of the SDK
for
users, and you get to use the best packaged drivers.

jh


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


Mark why are you so determined to take the most difficult, fragile and high
maintenance route?

Just use the Negativo Nvidia repo which includes CUDA etc

https://negativo17.org/nvidia-driver/
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[James Hogarth]

On 4 Oct 2017 6:51 pm, <m.r...@5-cent.us> wrote:

James Hogarth wrote:
> On 4 Oct 2017 3:13 pm, "Kenneth Porter" <sh...@sewingwitch.com> wrote:
>
> On 10/3/2017 8:14 PM, Phil Manuel wrote:
>
>> systemd-networkd doesn't use those files at all.
>>
>> If you look at the appropriate ifcfg files eg
>> /etc/sysconfig/network-scripts/ifcfg-em1 do you see
>> IPV6_FAILURE_FATAL=no
>> ?
>>
>
> Where does systemd-networkd store its settings, then?
>
>
>
> Files in /etc/systemd/network if I'm remembering right... been awhile
> since
> I played with it and it's not in a standard rhel install. You use .network
> files to do network configuration and .link for link level stuff like mac
> address.

Nope. And find /etc/systemd -name network gives zilch.

 mark

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


As I said it's not even installed by default and I think it's only in the
extras repo too...

So given this is the first time you've chimed in on this thread and that I
don't recall you ever mentioning using networkd in tiger past I would not
expect to see any .network files for you or a network directory.

Here's some documentation to read:

https://www.freedesktop.org/software/systemd/man/systemd.network.html
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[James Hogarth]

On 4 Oct 2017 3:13 pm, "Kenneth Porter"  wrote:

On 10/3/2017 8:14 PM, Phil Manuel wrote:

> systemd-networkd doesn't use those files at all.
>
> If you look at the appropriate ifcfg files eg
> /etc/sysconfig/network-scripts/ifcfg-em1 do you see IPV6_FAILURE_FATAL=no
> ?
>

Where does systemd-networkd store its settings, then?



Files in /etc/systemd/network if I'm remembering right... been awhile since
I played with it and it's not in a standard rhel install. You use .network
files to do network configuration and .link for link level stuff like mac
address.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[James Hogarth]

On 4 October 2017 at 07:20, Phil Perry  wrote:

> On 04/10/17 03:46, Phil Manuel wrote:
>
>> Hi,
>>
>> If I disable ipv6 via the kernel command line, ipv6.disable=1, then
>> systemd-networkd fails to bring up any interfaces.
>>
>> Removing the option and networking works as expected.
>>
>> Phil.
>>
>
> How are you controlling your network interfaces? I am using NM.
>
> Whilst not answering your question directly, I disable ipv6 in
> /etc/sysctl.conf.
>
> cat  /etc/sysctl.conf
> # sysctl settings are defined through files in
> # /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
> #
> # Vendors settings live in /usr/lib/sysctl.d/.
> # To override a whole file, create a new file with the same in
> # /etc/sysctl.d/ and put new settings there. To override
> # only specific settings, add a file with a lexically later
> # name in /etc/sysctl.d/ and put new settings there.
> #
> # For more information, see sysctl.conf(5) and sysctl.d(5).
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
>
> After updating, run 'sysctl -p' and 'dracut -f'
>
>
>
>
He's using systemd-networkd as he stated.

Best advice? Don't disable IPv6 ... configure your firewall properly.

Too much now depends on IPv6 to play silly buggers with a key component of
the network stack (eg default binds and network bonding).
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] owncloud on CentOS - I have problems installing/updating recently

[James Hogarth]

On 22 September 2017 at 06:28, Sorin Srbu  wrote:

> > -Original Message-
> > From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Valeri
> > Galtsev
> > Sent: den 21 september 2017 17:25
> > To: CentOS mailing list 
> > Subject: Re: [CentOS] owncloud on CentOS - I have problems
> > installing/updating recently
> >
> >
> > On Thu, September 21, 2017 1:00 am, Sorin Srbu wrote:
> > >> -Original Message-
> > >> From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Nicolas
> > >> Kovacs
> > >> Sent: den 20 september 2017 18:55
> > >> To: centos@centos.org
> > >> Subject: Re: [CentOS] owncloud on CentOS - I have problems
> > >> installing/updating recently
> > >>
> > >> > Does anybody have any suggestion? Am I the only one (thus, making my
> > >> > "pilot error"), or others have the same? Did someone find
> workaround?
> > >>
> > >> The SUSE repository works perfectly. There has been a transition
> period
> > >> with overlapping dependencies in this repository and EPEL. What I did
> > >> was simply remove all packages and reinstall the owncloud-client
> > >> package. This repository is also always up-to-date, whereas the EPEL
> > >> package is regularly lagging behind.
> > >
> > > Not just you Valeri. Thought it was a bit fishy as well, but figured
> I'd,
> > > as
> > > Nicolas mentions, doing a uninstall and then reinstall things might
> solve
> > > the
> > > problems.
> > >
> >
> > Thanks Nicolas and Sorin! Once I learned from you about another source of
> > owncloud packages (EPEL), I found my way out of suse repository timing
> out
> > on me...
> >
> > Valeri
>
> You're welcome.
>
> I also use the yum-priorities plugin. I find it sometimes plays tricks on
> me.
> You might want to look into that and shuffle the set priorities, if you use
> it as well
>
> --
> //Sorin
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

I know that many prefer EPEL packages but sometimes life gets ahead of us...

So far as owncloud in EPEL/CentOS is concerned it's not actually lagging
that badly ... the most recent 9.1.X release is 9.1.6 and it's only a few
minor bugfixes for the large part over the 9.1.5 in the EPEL repo.

https://owncloud.org/changelog/

Do note that when I push 9.1.6 (which will be soon now I have a little
time) it'll probably be close to the last owncloud package in EPEL7 at the
least ... I'll include an EOL/retirement notice in the package when I get
around to it and will mail here and epel-devel and epel-announce mailing
lists.

The 10.x release of owncloud bumps the minimum PHP version to 5.6 ... which
is obviously not in base repos and I'm not permitted to depend on packages
in SCL or 3rd party repos in EPEL.

The nextcloud package is in a worse state as things stand ... the version
that can be in EPEL is officially EOL ... I'll push out a 10.0.6 release
soon with the EOL notice and email about this. From 11 onwards they require
PHP5.6+ as well.

For now my recommendation for owncloud or nextcloud is to use their most
recent manual tarball/zip install and PHP 7.1 from your preferred choice of
IUS, RemiRepo or SCL ... or run their official containers.

I hope to have a container option soon(ish) as part of the Fedora Container
Service initiative that would allow you to run the Fedora based version
easily, which would bypass the PHP version issues but that needs me to
have time to get all the dependency issues sorted and carry out the Fedora
upgrades.

Reminder that I have a job and family and 2 year old daughter ... time to
do all this is precious and if you want to see this happen then help is
always welcome :)

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

Re: [CentOS] prevent users from fiddling with network?

[James Hogarth]

On 21 Sep 2017 17:10, "Valeri Galtsev"  wrote:

Dear Experts,

"this is system from the hell!"

Than was my first reaction when I realized that logged in with GUI (X11)
user can turn off (and on) network interfaces. Without being in sudoers
file. Wow, this is scary to see on workstations I manage centrally. Even
though I did consider local user to be able to execute the command
"shutdown" (which distinguished RedHat and CentOS from other Linux
flavors: after all local user can yank power cord off the wall).

Sorry about my little rant above. Could someone point me into right
direction as to how do I disable the ability of (local, logged in through
X11) users to fiddle with network interfaces. Even worse, they can create
new profile and define for interfaces to behave differently... In the past
I could just add

USERCTL="no"

into interface ifcfg-... file inside /etc/sysconfig/network-scripts which
doesn't seen to have any effect on latest CentOS 7. What is my pilot error
here? (Ignorant in new shiny extremely MS Windows like for _ignorant_
person - me - system).


Thanks a lot for all your help!

Valeri


On the commute home so access to resources to test is limited.

This will no doubt be handled through polkit policy.

This should at least set you on the right path to discover and configure
the appropriate bits...

https://www.hogarthuk.com/?q=node/10
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7: changes to php.ini

[James Hogarth]

On 21 September 2017 at 10:14, Sorin Srbu  wrote:

> > -Original Message-
> > From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Nicolas
> > Kovacs
> > Sent: den 21 september 2017 11:05
> > To: centos@centos.org
> > Subject: [CentOS] CentOS 7: changes to php.ini
> >
> > I'm hosting a few web apps like OwnCloud, Wordpress and Dolibarr on
> > CentOS 7 that require a handful of changes to php.ini. I have to define
> > some custom values for post_max_size, upload_max_filesize, etc.
> >
> > I don't know if I'm supposed to edit /etc/php.ini directly or if changes
> > should be put in a configuration file stub in /etc/php.d. For example, I
> > followed the recommendations of a fellow CentOS user and defined
> > date.timezone by edit /etc/php.d/date.ini like this.
> >
> > [Date]
> > ; Defines the default timezone used by the date functions
> > ; http://php.net/date.timezone
> > date.timezone = Europe/Paris
> >
> > Am I supposed to do something similar for other PHP variables?
>
> In the beginning I edited those values in php.ini.
> Got tired of having to remake the changes in php.ini, whenever php-updates
> were installed, so eventually began setting the needed values directly in
> the
> Owncloud-GUI.
>
> Dates however are a different thing. I really always want to see and use
> ISO-dates and times regardless of it's OC or whatever - so I edit the
> php.ini
> in that case.
>
>
>
>
When you have different applications with different needs it's best to
either use mod_php specific directives within that virtualhost such as here:

https://src.fedoraproject.org/rpms/owncloud/blob/master/f/owncloud-defaults.inc

Or honestly better still to not use mod_php and instead switch to php-fpm
with separate application pools which each have their own php settings like
this nginx based setup:

https://src.fedoraproject.org/rpms/owncloud/blob/master/f/owncloud-conf-nginx.conf

https://src.fedoraproject.org/rpms/owncloud/blob/master/f/owncloud-el7-php-fpm.conf
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS, PHP & OwnCloud/Nextcloud: the version dilemma

[James Hogarth]

On 19 September 2017 at 21:15,  wrote:

> Valeri Galtsev wrote:
> >
> > On Tue, September 19, 2017 1:42 pm, Nux! wrote:
> >> Unfortunately the same can be said about Ruby, RoR, Python etc etc etc.
> >
> > It is not as much true about languages themselves (though it is true, and
> > I for one call python "sneaky snake" just because of that ;-), as about
> 
> Yeah, in addition to my reaction to "you're using *whitespace* as a syntax
> element?!", I had an early dislike of python, when each new sub-release
> broke things that had worked in the previous.
>
>
>
For what it's worth at this time I'd use one of the PHP7 options with the
upstream

https://www.hogarthuk.com/?q=node/15

Getting the owncloud and nextcloud EPEL packages updated are on my to-do
list, but family and work matters have limited my time in the recent months.

The EPEL versions cannot go to the latest though due to the minimum PHP
version jump.

At this point I'd recommend you use the upstream archive (just untar/unzip
it) and the most recent PHP in either IUS, remi or SCL (depending which
repo you feel more comfortable with ... see my article for the differences
but they are all trustworthy).

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

Re: [CentOS] Apache 2.2 EOL - what is Red Hat's story for RHEL6?

[James Hogarth]

On 13 September 2017 at 14:10, Alan McKay  wrote:

> > I don't have any official knowledge, but I would suspect that they will
> > maintain httpd-2.2 throughout the lifetime of RHEL6.  Security issues
> > would be backported.  (If older versions of RHEL are any indication)
>
> The basic problem is though that there won't be any security fixes for 2.2
> How can they back port something that does not exist?
>
> Or do you mean you think they'll try to port a fix in 2.4 back to 2.2?
> Not even sure that will be possible.
>
> Is there some way to get an official statement from RHEL on this?
> Like if I bought a licensed copy of RHEL and used it to open a support
> case or something like that?
>


Yes they have engineers who, when a CVE is discovered, will analyse if it
applies to the httpd shipped in RHEL and if there is an issue will write
their own patch (if there is no longer an upstream to directly backport
from).

So long as you use the httpd shipped in RHEL/CentOS you will be protected
against all known CVEs that get discovered - of course ensuring that
mitigating factors such as selinux being enforce also assists with
protection from many/most vulnerabilities in something like httpd.

You will want to read up on:

https://access.redhat.com/support/policy/updates/errata/

and possibly:

https://access.redhat.com/articles/rhel-top-support-policies

and certainly:

https://access.redhat.com/security/updates/backporting

So yes if there is a security issue found in the httpd 2.2 shipped with EL6
after December of this year RHEL engineers will develop a patch to
mitigate/fix it and include it in their build of httpd they ship.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemctl poweroff

[James Hogarth]

On 11 September 2017 at 07:49, Nicolas Kovacs  wrote:

> Hi,
>
> I've been using CentOS since versions 4.x, and I see a weird trend in
> recent Linux distributions.
>
> Under CentOS 4.x, 5.x and 6.x, shutting down a server (workstation,
> laptop) simply meant issuing 'shutdown -h now' (or choosing 'Shutdown'
> from the GUI menu), and the machine would simply shut down. Whatever
> crazy process went haywire, shutting down the system meant exactly that.
> No questions asked.
>
> Now with CentOS 7.x, sometimes the machine would simply hang during the
> shutdown process, or I would get a message like "a stop job is running",
> and I would end up having to hit the Reset button to stop the system, as
> I did when I used Microsoft Windows (before 2001).
>
>
>
>
Have patience - the default is for systemd to give processes 90 seconds to
stop gracefully before forcefully killing them ( the 30 sec / 1 min 30 sec
bit)

With the older sysv scripts things were not so graceful ...

If there's a service that frequently takes ages to stop you may want to
investigate why (eg is it missing a dependency on a network filesystem and
then gets stuck when the network filesystem goes before it does).
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] centos-7.4 elfutils

[James Hogarth]

On 10 September 2017 at 22:14, Jack Bailey  wrote:

> Hello,
>
> I'm taking 7.4 for a spin.  I did the minimal install, and ran into
> trouble with groupinstall base.  The trouble seems to stem from elfutils.
> One command claims elfutils-libs-0.166-2.el7.x86_64 is missing, and
> another one claims it's installed.  Not sure what's going on here.
>
> [root@ip-172-31-34-187 ~]# yum -y install elfutils.x86_64
> Loaded plugins: fastestmirror
> Loading mirror speeds from cached hostfile
>  * base: mirror.web-ster.com
>  * extras: mirror.chpc.utah.edu
>  * updates: mirrors.cat.pdx.edu
> Resolving Dependencies
> --> Running transaction check
> ---> Package elfutils.x86_64 0:0.166-2.el7 will be installed
> --> Processing Dependency: elfutils-libs(x86-64) = 0.166-2.el7 for
> package: elfutils-0.166-2.el7.x86_64
> --> Processing Dependency: elfutils-libelf(x86-64) = 0.166-2.el7 for
> package: elfutils-0.166-2.el7.x86_64
> --> Finished Dependency Resolution
> Error: Package: elfutils-0.166-2.el7.x86_64 (base)
>Requires: elfutils-libelf(x86-64) = 0.166-2.el7
>Installed: elfutils-libelf-0.168-8.el7.x86_64 (@anaconda)
>elfutils-libelf(x86-64) = 0.168-8.el7
>Available: elfutils-libelf-0.166-2.el7.x86_64 (base)
>elfutils-libelf(x86-64) = 0.166-2.el7
> Error: Package: elfutils-0.166-2.el7.x86_64 (base)
>Requires: elfutils-libs(x86-64) = 0.166-2.el7
>Installed: elfutils-libs-0.168-8.el7.x86_64 (@anaconda)
>elfutils-libs(x86-64) = 0.168-8.el7
>Available: elfutils-libs-0.166-2.el7.x86_64 (base)
>elfutils-libs(x86-64) = 0.166-2.el7
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
>
> [root@ip-172-31-34-187 ~]# yum -y install elfutils-libs.x86_64
> Loaded plugins: fastestmirror
> Loading mirror speeds from cached hostfile
>  * base: mirror.web-ster.com
>  * extras: mirror.chpc.utah.edu
>  * updates: mirrors.cat.pdx.edu
> Package matching elfutils-libs-0.166-2.el7.x86_64 already installed.
> Checking for update.
> Nothing to do
>
>
>
>
Enable the CR repo so that you have an appropriately matching version of
the libs package.

https://wiki.centos.org/AdditionalResources/Repositories/CR
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] selinux denial of cgi script with httpd using ssl

[James Hogarth]

On 4 September 2017 at 23:12, Alexander Dalloz  wrote:

> Am 04.09.2017 um 23:49 schrieb Gregory P. Ennis:
>
>> Thanks for your help.
>>
>> I did pick up an additional entry in the audit file :
>>
>>
>> type=AVC msg=audit(1504561395.709:10196): avc:  denied  { execute } for
>> pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi" dev="dm-0"
>> ino=537182029 scontext=system_u:system_r:httpd_t:s0
>> tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file
>>
>> Unfortunately, I am not sure how the above tells me what is wrong.
>>
>> Greg
>>
>
> From above log entry you see that the file object denied to execute
> ('/var/www/cgi-bin/name.of.script.cgi) has the SELinux context type
> httpd_sys_content_t.
>
> # semanage fcontext -l | grep '/var/www/cgi-bin'
> /var/www/cgi-bin(/.*)? all files
> system_u:object_r:httpd_sys_script_exec_t:s0
> [ ... ]
>
> The permitted type is httpd_sys_script_exec_t.
>
> `restorecon -Rv /var/www/cgi-bin/' can fix it. Or more targeted `chcon -t
> httpd_sys_script_exec_t /var/www/cgi-bin/name.of.script.cgi'.
>
> Both audit2why and audit2allow suggest to activate a boolean which you may
> not want to set as it disables a more fine grained priviledge separation in
> the context of httpd actions.
>
>
>
Don't ever use chcon unless you hate future you or random future team
member when they wonder why things break after a relabelling!
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] selinux denial of cgi script with httpd using ssl

[James Hogarth]

On 4 September 2017 at 22:49, Gregory P. Ennis  wrote:

> Thanks for your help.
>
> I did pick up an additional entry in the audit file :
>
>
> type=AVC msg=audit(1504561395.709:10196): avc:  denied  { execute } for
> pid=19163 comm="/usr/sbin/httpd" name="s.check.cgi" dev="dm-0"
> ino=537182029 scontext=system_u:system_r:httpd_t:s0
> tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file
>
> Unfortunately, I am not sure how the above tells me what is wrong.
>
>
Odd it was in the don't audit logs, as I think that should be logged
normally.

Executable scripts should be httpd_sys_script_exec_t rather than
 httpd_sys_content_t, as the latter is just read only content files rather
than something to be executed.

The default policy has the cgi-bin directory contents labelled correctly by
default though ...

Could you please post the output of 'semanage fcontext -lC' ... this will
list any local file context modifications.

You could try restorecon -Rv /var/www to see if that fixes your labelling,
if you've not made any local modifications.

If you have made local modifications to set the contents of cgi-bin to
httpd_sys_content_t then you should remove those with semanage fcontext -d
'/var/www/cgi-bin' or whatever the pattern for the local modification is as
that's incorrect labelling.

While you're checking selinux configuration do a quick
getsebool httpd_enable_cgi ... it's on by default but worth verifying :)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Syncronize systemctl status with reality?

[James Hogarth]

On 29 August 2017 at 21:52, Leroy Tennison <le...@datavoiceint.com> wrote:

> - Original Message -
> From: "James Hogarth" <james.hoga...@gmail.com>
> To: "centos" <centos@centos.org>
> Sent: Tuesday, August 29, 2017 2:03:44 PM
> Subject: Re: [CentOS] Syncronize systemctl status with reality?
>
> On 29 Aug 2017 17:58, "Leroy Tennison" <le...@datavoiceint.com> wrote:
>
> The particular issue is with puppetmaster (which admittedly takes 4 minutes
> to actually start, setting TimeoutStartSec=300 in it's unit file stopped
> the false timeout report) but I have seen it one other time (don't remember
> the details).
>
> systemctl status puppetmaster
> ● puppetmaster.service - Puppet master
> Loaded: loaded (/lib/systemd/system/puppetmaster.service; enabled; vendor
> preset: enabled)
> Active: failed (Result: resources) since Tue 2017-08-29 11:24:36 CDT; 22min
> ago
> Process: 897 ExecStart=/usr/bin/puppet master (code=exited,
> status=0/SUCCESS)
>
> Aug 29 11:22:39 puppetmaster02 systemd[1]: Starting Puppet master...
> Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Reopening log files
> Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Starting Puppet master
> version 3.8.5
> Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Could not run: Address
> already in use - listen(2)
> Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: PID 1233
> read from file /run/puppet/master.pid does not exist or is a zombie.
> Aug 29 11:24:36 puppetmaster02 systemd[1]: Failed to start Puppet master.
> Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: Unit
> entered failed state.
> Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: Failed
> with result 'resources'.
>
> However, ps -ef | grep puppet (run just after the above) returns
> puppet 1380 1 0 11:26 ? 00:00:08 Passenger RubyApp: /usr/share/puppet/rack/
> puppetmasterd
> root 2015 1341 0 11:48 pts/0 00:00:00 grep --color=auto puppet
>
> Earlier ps .. also reported
> puppet 1355 1166 3 11:26 ? 00:00:01 Passenger AppPreloader:
> /usr/share/puppet/rack/puppetmasterd
>
> And, the "bottom line", puppet agent -t on a client works. It reports
> finishing the catalog run and the client's yaml files on puppetmaster are
> up to date.
>
> Is there a command to tell systemd to re-scan running state and update its
> understanding on what it finds? I tried systemctl daemon-reload just to be
> sure that didn't solve the problem before posting this.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
>
> First glance ity looks like someone has started that puppetmaster manually
> at some point. As such it's not in a cgroup systemd is tracking so it isn't
> aware of it.
>
> Your attempts to start the service are failing because that manually
> started instance already has the port open.
>
> Kill it with pkill -f puppet and then use ss -tnp to check for the port
> being freed (wait for any time_wait states to go... which is why I'm not
> filtering by listen).
>
> Once it's clear then try starting with systemctl
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
> OK, something weird is definitely going on here, I have the luxury of
> rebooting this system so it did.  Here's what I got, note the time stamps.
>
> ps -ef | grep puppet
> root   932 1  0 15:23 ?00:00:00 /usr/bin/ruby
> /usr/bin/puppet master
> root  1343  1327  0 15:24 pts/000:00:00 grep --color=auto puppet
> (immediately afterward as fast as I could type:) uptime
>  15:24:56 up 1 min,  1 user,  load average: 0.16, 0.07, 0.02
> systemctl status puppetmaster
> ● puppetmaster.service - Puppet master
>Loaded: loaded (/lib/systemd/system/puppetmaster.service; enabled;
> vendor preset: enabled)
>Active: activating (start) since Tue 2017-08-29 15:23:44 CDT; 1min 24s
> ago
>   Control: 932 (puppet)
> Tasks: 1
>Memory: 2.4M
>   CPU: 4ms
>CGroup: /system.slice/puppetmaster.service
>└─932 /usr/bin/ruby /usr/bin/puppet master
>
> Aug 29 15:23:44 puppetmaster02 systemd[1]: Starting Puppet master...
>
>
>
> After a short delay:
> systemctl status puppetmaster
> ● puppetmaster.service - Puppet master
>Loaded: loaded (/lib/systemd/system/puppetmaster.service; enabled;
> vendor preset: enabled)
>Active: failed (Result: resources) since Tue 2017-08-29 15:25:11 CDT;
> 11s ago
>   Process: 932 ExecStart=/usr/bin/puppet master (code=exited,
> status=0/SUC

Re: [CentOS] Syncronize systemctl status with reality?

[James Hogarth]

On 29 Aug 2017 17:58, "Leroy Tennison"  wrote:

The particular issue is with puppetmaster (which admittedly takes 4 minutes
to actually start, setting TimeoutStartSec=300 in it's unit file stopped
the false timeout report) but I have seen it one other time (don't remember
the details).

systemctl status puppetmaster
● puppetmaster.service - Puppet master
Loaded: loaded (/lib/systemd/system/puppetmaster.service; enabled; vendor
preset: enabled)
Active: failed (Result: resources) since Tue 2017-08-29 11:24:36 CDT; 22min
ago
Process: 897 ExecStart=/usr/bin/puppet master (code=exited,
status=0/SUCCESS)

Aug 29 11:22:39 puppetmaster02 systemd[1]: Starting Puppet master...
Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Reopening log files
Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Starting Puppet master
version 3.8.5
Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Could not run: Address
already in use - listen(2)
Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: PID 1233
read from file /run/puppet/master.pid does not exist or is a zombie.
Aug 29 11:24:36 puppetmaster02 systemd[1]: Failed to start Puppet master.
Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: Unit
entered failed state.
Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: Failed
with result 'resources'.

However, ps -ef | grep puppet (run just after the above) returns
puppet 1380 1 0 11:26 ? 00:00:08 Passenger RubyApp: /usr/share/puppet/rack/
puppetmasterd
root 2015 1341 0 11:48 pts/0 00:00:00 grep --color=auto puppet

Earlier ps .. also reported
puppet 1355 1166 3 11:26 ? 00:00:01 Passenger AppPreloader:
/usr/share/puppet/rack/puppetmasterd

And, the "bottom line", puppet agent -t on a client works. It reports
finishing the catalog run and the client's yaml files on puppetmaster are
up to date.

Is there a command to tell systemd to re-scan running state and update its
understanding on what it finds? I tried systemctl daemon-reload just to be
sure that didn't solve the problem before posting this.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


First glance ity looks like someone has started that puppetmaster manually
at some point. As such it's not in a cgroup systemd is tracking so it isn't
aware of it.

Your attempts to start the service are failing because that manually
started instance already has the port open.

Kill it with pkill -f puppet and then use ss -tnp to check for the port
being freed (wait for any time_wait states to go... which is why I'm not
filtering by listen).

Once it's clear then try starting with systemctl
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] C7 and spoofed MAC address

[James Hogarth]

On 30 June 2017 at 18:58,   wrote:
> Got a problem: a user's workstation froze. He wound up rebooting, without
> calling me in first, so I dunno. But, and this is a show-stopper, when it
> came up, it came up with the firmware MAC, not the spoofed one. In
> /etc/sysconfig/network-scripts/ifcg-eth0, I've got the spoofed MAC
> address, and a UUID. In the grub.conf, I've got net.ifnames=0
> biosdevname=0. But when I logged onto his machine, ip a showed eth0... but
> with the firmware MAC.
>
> And I'm wondering if it went to renew its IP address, and lost the spoofed
> MAC. That might explain his freezes.
>
> Anyway, does anyone have any idea if there's some networkmangler or
> systemd configuration that would force it to pay attention?
>
> Note that my hack to fix it was ifdown eth0/ifup eth0, and it's fine.
>


Not much to go on here 

Your ifcfg-* configs would be helpful.

There was a slight change to MAC spoof behaviour in the NM 1.4.0 that
was part of EL7.3 compared to the older NM as I recall

https://www.hogarthuk.com/?q=node/18

That may or may not be affecting you.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Virtual IP

[James Hogarth]

On 6 July 2017 at 15:41, Scott Robbins  wrote:
> On Thu, Jul 06, 2017 at 08:17:17AM -0400, Jonathan Billings wrote:
>> On Thu, Jul 06, 2017 at 11:17:12AM +0300, Amine Tengilimoglu wrote:
>> >i need your helps on setting the virtual ip. I am trying to setup static
>> > virtual ip on CenOS7.  but I want my VIP to should not open when rebooting.
>>
>> It looks like you're trying to add the second IP on an aliased
>> interface, something that you used to have to do in older releases of
>> CentOS.
>>
>> In C7, you just add multiple IPs to the interface, no need to use
>> eth0:1 style names.
>>
>> In the ifcfg-, you can just put in IPADDR1=1.2.3.4 and
>> NETMASK1=255.255.255.0, and PREFIX1=1.2.3.0.
>>
>> The documentation is in
>> /usr/share/doc/initscripts-9.49.37/sysconfig.txt (part of the
>> initscripts package), which says:
>
> There's a clearer explanation, IMHO, with examples, here.
> https://community.spiceworks.com/topic/545859-add-secondary-ip-to-one-interface-in-centos-7
>
> I don't see mention of it in the RHEL-7 release notes, they just say NM is
> better than it was, and perhaps there's an easy way to do it with NM.
>
> I've left the text that J.Billings kindly included, in below.
>
>
>>
>>
>>   Base items:
>> NAME=
>>   Most important for PPP.  Only used in front ends.
>> DEVICE=>   devices where it is the "logical name")>
>> IPADDRn=
>> PREFIXn=
>>   Network prefix.  It is used for all configurations except aliases
>>   and ippp devices.  It takes precedence over NETMASK when both
>>   PREFIX and NETMASK are set.
>> NETMASKn=
>>   Subnet mask; just useful for aliases and ippp devices.  For all other
>>   configurations, use PREFIX instead.
>>
>> The "n" is expected to be consecutive positive integers starting from 0.
>> It can be omitted if there is only one address being configured.
>>
>> So, you can have IPADDR0, IPADDR1, IPADDR2, etc.
>>
>> All of these will configure an IP on the device named in the DEVICE
>> line.  No need to have multiple alias interfaces.
>>
>> --
>> Jonathan Billings 


Don't even go near an aliased interface on EL7 ... it's the most
painful way to handle this and not NM compatible.

Here's an article I wrote way back on handling this:

https://www.hogarthuk.com/?q=node/6

Note that with NM in use (as should be the case on EL7) it's as simple
as: nmcli con mod  +ipv4.addr "10.0.0.2/24"

https://www.hogarthuk.com/?q=node/8
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd order help?

[James Hogarth]

On 13 June 2017 at 13:27, Matthew Miller <mat...@mattdm.org> wrote:
> On Tue, Jun 13, 2017 at 06:34:54AM +0100, James Hogarth wrote:
>> Depending on your setup, you many want to look at converting your
>> automatic mounts into systemd mounts, and depend on that directly,
>> rather than on the autofs service.
> [...]
>> Just one little thing to note here that many don't realise. All mounts in
>> the system (ie not manually via the mount command) are systemd mounts.
>
> This isn't true for autofs, is it?
>
>> Finally autofs is made even easier with systemd as all you need to do to
>> declare a mount autofs is x-systemd.automount in the options field and then
>> it'll only be mounted on demand rather than at boot.
>
> I mean, autofs using the traditional autofs
>

I've not actually tested that tbh Matt ...

I expect that indeed that case it wouldn't work

But unless you need a complicated map arrangement I'd argue on EL7
you'd be better off using the fstab option to make the mount automount
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd order help?

[James Hogarth]

On 12 Jun 2017 17:03, "Matthew Miller"  wrote:

On Mon, Jun 12, 2017 at 03:47:46PM +, James Pearson wrote:
> I'm guessing I could use something like:
>
>   After=autofs.service
>   Before=graphical.target
>
> Is this correct?
>
> However, I would like to use the same systemd unit file on servers that
> won't run X - will the above work? Or is there a better/another way of
> doing this?

You probably want "display-manager.service" instead of
"graphical.target".

You also will want "Requires=autofs.service". The distinction between
"After/Before" and "Requires" is exactly for the reason you give; the
ordering directives don't require anything, so without
display-manager.service enabled, Before=display-manager.service is just
a no-op. Actually, you might even want "BindsTo=autofs.service", which
is stronger.

Depending on your setup, you many want to look at converting your
automatic mounts into systemd mounts, and depend on that directly,
rather than on the autofs service.


Just one little thing to note here that many don't realise. All mounts in
the system (ie not manually via the mount command) are systemd mounts.

There's a generator that makes mount units from fstab and it is the actual
runtime mount unit that gets used.

So with things in fstab you can still have a service require something like
data.mount ... There's even a directive RequiresMountsFor to ensure that a
path is mounted before that unit is started.

Finally autofs is made even easier with systemd as all you need to do to
declare a mount autofs is x-systemd.automount in the options field and then
it'll only be mounted on demand rather than at boot.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] C7, systemd, say what?!

[James Hogarth]

On 8 June 2017 at 13:02, Bruce Ferrell  wrote:
> On 06/08/2017 04:59 AM, John Hodrien wrote:
>>
>> On Thu, 8 Jun 2017, Bruce Ferrell wrote:
>>
>>> Yes, 7 does track upstream.  upstream 6 uses systemd also and Scientific
>>> Linux 6 does not.  I would say that indicates a solution.
>>
>>
>> Upstream 6 uses systemd?
>>
>> jh
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
> yes, 6.6 and above
>
>

Uh I'd urge you to recheck your sources as EL6 has never in any part
of its lifespan made use of systemd
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] C7, systemd, say what?!

[James Hogarth]

On 7 June 2017 at 16:13,   wrote:
> Matthew Miller wrote:
>> On Wed, Jun 07, 2017 at 10:10:14AM -0400, m.r...@5-cent.us wrote:
>>> I just updated a system - as in minutes ago, and log back in after it
>>> reboots, and this is in dmesg:
>>> [   88.202272] systemd-readahead[484]:
>>> open(/var/tmp/dracut.fP4yj1/initramfs/usr/bin/loginctl) failed: Too many
>>> levels of symbolic links
>>> [   88.202515] systemd-readahead[484]:
>>> open(/var/tmp/dracut.fP4yj1/initramfs/usr/lib/systemd/system/dracut-emergency.service)
>>> failed: Too many levels of symbolic links
>>> Anyone know what this is - some weird bug, a garbage message?
>>
>> systemd-readahead is just trying to pre-cache stuff into memory so boot
>> time is faster. I'm not sure eaxctly what's going on here but that
>> message is typical of having a loop in your symbolic links (which can
>> easily happen with relative links).
>>
>> I'm not quite sure what *exactly* is going on, but it looks like maybe
>> dracut temp files didn't get cleaned up properly and that they contain
>> such a loop. I bet you can just rm -rf /var/tmp/dracut.fP4yj1.
>>
> Thanks for the info. Now, why it shouldn't have cleaned itself up when I
> gave it the reboot command... I see too many (that's defined as more than
> zero) cases where systemd WANTS TO BOOT FAST, and doesn't wait for things
> to finish - sush as not getting the hostname from dhcp, and so having to
> hardcode the name instead.
>
> Systemd, as I've said before, seems to be targeted towards laptops. Not
> servers. Not workstations. *bleah*
>


Mark stop with the flame baiting please.

This is nothing systemd specific - and keep in mind /var/tmp is a
persistent temp area unlike /tmp which as it's tmpfs by default is of
course emptie don boot.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] yum install does not downgrade

[James Hogarth]

On 2 Jun 2017 1:28 pm, "Mark Haney"  wrote:

Personally, I would do one of three things:

1. Use the -m command to run 'yum install ' which /might/ work.

2. Uninstall the newer package and install the version you want. (Check the
'state' directive to do this.)

3. Pin that package version when creating the server/VM so as not to be
updated.

#3 is useful to us as we kickstart all our servers and VMs, and this
eliminates the problem going forward.  Then, when we're ready to upgrade
the pinned package, we have an ansible playbook that unpins that version,
installs the new version (even if not latest), then re-pins.

HTH.



On 06/01/2017 03:46 PM, Anand Buddhdev wrote:

> We're using ansible to configure our CentOS 6 servers, and we have a
> task to install a specific version of a package:
>
> - name: install thrift2
>yum: name=ripencc-thrift2-{{ version }}
>
> In this ansible task, the "version" variable is set by the operator.
> When we want to upgrade, it works. But today we had to downgrade, and
> noticed that ansible wasn't downgrading it. So we tried by hand (the
> installed version was 1.0.8):
>
> # yum install ripencc-thrift2-1.0.3
>
> I don't have the output handy, because a colleague was working on it,
> but basically, yum said something like "package already installed" and
> refused to downgrade it, even though the package is in our repository.
>
> I have a strong sense that yum _used to_ downgrade packages if asked to
> install an older version, but perhaps I am misremembering.
>
> Nevertheless, I want to ask: is this a bug in yum? If asked to install a
> specific version, should it not upgrade OR downgrade as needed?
>
> Regards,
> Anand
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

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


The present version of ansible can't handle downgrades with the yum module

There's been a few discussions of this over time but this is the most
recent I think, and it looks like it might get fixed on 2.4 perhaps

https://github.com/ansible/ansible/issues/21516

If you want to do a specific version you are better off not using the yum
module at present but rather shell/command to do so instead.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upgrade 6 to 7

[James Hogarth]

On 2 Jun 2017 09:45, "Gianluca Cecchi"  wrote:

Il 01 Giu 2017 10:13 PM, "Jerry Geis"  ha scritto:

I found this site https://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool

Is this still the case - there is no upgrade path from 6 to 7 ?

I have a few remote servers I'd like to upgrade (if possible).

Thanks,

Jerry


It is supported, with some limitations, in rhel, so the same I think
applies to CentOS.
See here for rhel
https://access.redhat.com/documentation/en-US/Red_Hat_
Enterprise_Linux/7/html/Migration_Planning_Guide/chap-
Red_Hat_Enterprise_Linux-Migration_Planning_Guide-
Upgrading.html#chap-Red_Hat_Enterprise_Linux-Migration_
Planning_Guide-Upgrading_from_RHEL6
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos



I suggest you pay attention to the big bold warning text stating that the
tool is not supported on CentOS:

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

Re: [CentOS] IPv6 addresses order (CentOS6)

[James Hogarth]

On 30 May 2017 at 08:26, Walter H.  wrote:
> Hello,
> in /etc/sysconfig/network-scripts/ifcfg-eth0 I have this
> 
> ...
> IPV6INIT=yes
> IPV6ADDR=prefix::5
> IPV6ADDR_SECONDARIES="prefix::2 prefix::3 prefix::4"
> IPV6_AUTOCONF=no
> IPV6_DEFAULTGW=prefix::1
> IPV6_DEFAULTDEV=eth0
> 
> when I enter ifconfig the IPv6 addresses are in a different order
> 
> eth0 Link encap:Ethernet HWaddr ...
> inet addr:... Bcast:... Mask:...
> inet6 addr: fe80::.../64 Scope:Link
> inet6 addr: prefix::4/64 Scope:Global
> inet6 addr: prefix::3/64 Scope:Global
> inet6 addr: prefix::5/64 Scope:Global
> inet6 addr: prefix::2/64 Scope:Global
> 
> is there a way to influence the order?
> or how can I tell e.g. ssh to use a specific IPv6 address?
> (as it seems ssh uses the first one listed in ifconfig and not the one
> defined with IPV6ADDR)
>


Okay so the other comments appear to be directing you towards
unhelpful territory.

It would be of help if you provided more detail about what you are after.

Is this EL6 or EL7?

Either way stop using ifconfig and start with ip - especially in ipv6 territory.

There is no "order" as you seem to think, outside of the slight
differentiation between primary and secondary.

The primary address on an interface is the one that will be used as
the source address for an application, with the secondary addresses
being there to accept traffic.

When you mention ssh to you mean ssh the client application or ssh the
daemon server? If the latter then you can set ListenAddress to the IP
to listen to.

If the client then you need to use '-b' to define the address to
connect from, if wanting something other than what `ip route get
8.8.8.8` (or whatever destination address it is) lists as the src
address.

In principle you could use `ip rule` to set up rules directing to a
secondary routing table with a different src, but that's more complex.

If you want this address persistent for one or more hosts without
always having to add '-b ::' to define the source address then you can
use BindAddress in your /etc/ssh/ssh_config at a system level or
~/.ssh/config at a user level to always use that set source address.

man ssh and man ssh_config will help you here ... assuming this is
just about ssh
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 and MAC address munging

[James Hogarth]

On 17 May 2017 8:53 pm,  wrote:

Odd situation: I've mentioned before that I have several users for whom I
have to spoof the MAC address, due to a software license. Now, I've got
net.ifnames=0 biosdevname=0 on the grub2 command line, and I've got the
spoofed MAC address in /etc/sysconfig/network-sctipts/ifcfg-eth0.

But he had a serious problem - X froze, and he thought to reboot, rather
than call me. It came up with the actual MAC. I tried a number of things,
including reboots, but the only thing that worked was systemctl stop
NetworkManager, ifdown eth0, then ifup eth0, then start NetworkMangler,
and all was good.

Yeah, I know, afterwards, I remembered I should have use nmcli

But the real question is *why* did it fail on the reboot. I find no clues
in dmesg, or messages, or boot.log.

Clues for the poor?

   mark

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


Is this box fully updated? I ask as the NM since 7.3 has different
behaviour from release due to rebasing.

What does `nmcli con sh eth0 | grep clone` tell you?

It's that property you need to set.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] From Networkmanager to self managed configuration files

[James Hogarth]

On 4 May 2017 at 12:44, James Hogarth <james.hoga...@gmail.com> wrote:
> On 8 March 2017 at 11:19, James Hogarth <james.hoga...@gmail.com> wrote:
>> On 8 March 2017 at 11:15, Alice Wonder <al...@domblogger.net> wrote:
>>> On 03/08/2017 01:57 AM, Giles Coochey wrote:
>>>>
>>>>
>>>>> The recommended configuration for EL7 is to use NetworkManager unless
>>>>> you have a very specific edge case preventing you from doing so:
>>>>>
>>>> The truth is a lot of us run servers that don't need to have their
>>>> network "managed" by Networkmanager.
>>>>
>>>
>>> My experience was very difficult going to 7.2 to 7.3 because of a change in
>>> the behavior of NetworkManager with respect to IPv6 but once I had it
>>> figured out (thanks to people on this list) it worked out quite well and I
>>> kept NetworkManager.
>>>
>>> But I certainly understand why some don't want to do that.
>>
>>
>> That's fine Alice (and I remember your issue well with the minimally
>> documented change to stable-privacy by default for new systems ...
>> argh I still need to write up a blog article about that) but in this
>> case the person concerned isn't even using the network service, which
>> if legacy and semi-deprecated is still supported, but just doing a
>> ridiculous and unsupportable mini script (I'm guessing from rc.local?)
>> which doesn't handle pretty much any actual networking issue that may
>> come up - eg failed/delayed interface.
>
> Apologies for the slight necro but I felt this thread was the closest
> linked to the topic, and since it was of interest to Alice at the time
> may be of interest to others too.
>
> I've just finished up and published my NetworkManager rebased article
> covering the changes (focusing on behavioural ones):
>
> https://www.hogarthuk.com/?q=node/18
>
> I do like the idea of my wifi mac being able to be set to random by
> default now ... I may well enable that as a default (to handle
> trivially the use case of unknown public wifi) and toggle it to
> preserve or stable for my known standard connections.
>
> The master-slave style connections (whether vlan, bond, team or
> bridge) are much easier to deal with now as well at the command line,
> something I'm very happy to see.

And for those interested in the NM changes Fedora Magazine just published this:

https://fedoramagazine.org/networkmanager-changes-improvements/

I'm of reasonable confidence we'll see another bump in the NM version
at 7.4 when it eventually hits beta so it's worth looking out for the
NM 1.6.0 and 1.8.0 changes.

`nmcli -g  con sh ` will be lovely for
scripting for instance and MACsec may see some love on corporate
networks.

There doesn't look to be any behaviour level changes that will be
breaking like Alice faced before though ... some outputs to differ if
you are parsing specifically so check that.

One example that jumped out to me today was connection.zone (if using
NetworkManager to define the firewalld zone of a connection which is
not common yet) changes from "--" to "" when it's not defined.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd missing something?

[James Hogarth]

On 7 May 2017 at 16:30, Gordon Messmer  wrote:
> On 05/07/2017 07:22 AM, ken wrote:
>>
>> "Note that traditional init scripts continue to function on a systemd
>> system. An init script /etc/rc.d/init.d/foobar is implicitly mapped
>> into a service unit foobar.service during system initialization."
>> ...
>> However, what it implies doesn't seem to work out.
>
>
> It does not imply what you infer, because it explicitly says that the file
> in init.d is mapped to a systemd service unit.  The files in rc.d are not
> used, because systemd does not boot to runlevel 2, 3, 4, or 5.
>
> If you want "network" to start on boot, you would use "systemctl enable
> network".  (You would also want to "systemctl disable NetworkManager")
>

The two do not conflict and there is no need to to disable one to use the other.

In fact you shoudl leave network enabled when using NetworkManager or
you will get some odd behaviours, like missing loopback.

If you do 'nmcli d' to list devices you'll see that loopback is
unmanaged, ie it's handled by the network service.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] From Networkmanager to self managed configuration files

[James Hogarth]

On 8 March 2017 at 11:19, James Hogarth <james.hoga...@gmail.com> wrote:
> On 8 March 2017 at 11:15, Alice Wonder <al...@domblogger.net> wrote:
>> On 03/08/2017 01:57 AM, Giles Coochey wrote:
>>>
>>>
>>>> The recommended configuration for EL7 is to use NetworkManager unless
>>>> you have a very specific edge case preventing you from doing so:
>>>>
>>> The truth is a lot of us run servers that don't need to have their
>>> network "managed" by Networkmanager.
>>>
>>
>> My experience was very difficult going to 7.2 to 7.3 because of a change in
>> the behavior of NetworkManager with respect to IPv6 but once I had it
>> figured out (thanks to people on this list) it worked out quite well and I
>> kept NetworkManager.
>>
>> But I certainly understand why some don't want to do that.
>
>
> That's fine Alice (and I remember your issue well with the minimally
> documented change to stable-privacy by default for new systems ...
> argh I still need to write up a blog article about that) but in this
> case the person concerned isn't even using the network service, which
> if legacy and semi-deprecated is still supported, but just doing a
> ridiculous and unsupportable mini script (I'm guessing from rc.local?)
> which doesn't handle pretty much any actual networking issue that may
> come up - eg failed/delayed interface.

Apologies for the slight necro but I felt this thread was the closest
linked to the topic, and since it was of interest to Alice at the time
may be of interest to others too.

I've just finished up and published my NetworkManager rebased article
covering the changes (focusing on behavioural ones):

https://www.hogarthuk.com/?q=node/18

I do like the idea of my wifi mac being able to be set to random by
default now ... I may well enable that as a default (to handle
trivially the use case of unknown public wifi) and toggle it to
preserve or stable for my known standard connections.

The master-slave style connections (whether vlan, bond, team or
bridge) are much easier to deal with now as well at the command line,
something I'm very happy to see.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Apache + SSL: default configuration rated "C" by Qualys Labs

[James Hogarth]

On 26 April 2017 at 13:16, Steven Tardy  wrote:
>
>> On Apr 26, 2017, at 2:58 AM, Nicolas Kovacs  wrote:
>>
>> The site is rated "C"
>
> The RHEL/CentOS out-of-the-box apache tls is a little old but operational. 
> This Mozilla resource is excellent for getting apache tls config up-to-date.
>
> https://wiki.mozilla.org/Security/Server_Side_TLS

I'm not 100% on any differences in ciphers available, but I don't
think there should be much difference between EL7 and Fedora.

This config gets my an A+ rating on the sslabs test:

SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite "EECDH+aRSA+AESGCM EECDH+aRSA+SHA384 EECDH+aRSA+SHA256
EECDH+aRSA+RC4 EECDH EDH+aRSA !aNULL !eNULL !LOW !MEDIUM !SEED !3DES
!CAMELLIA !MD5 !EXP !PSK !SRP !DSS !RC4"


  Header always set Strict-Transport-Security "max-age=15768000;
includeSubDomains; preload"


https://www.ssllabs.com/ssltest/analyze.html?d=www.hogarthuk.com

IIRC the Red Hat defaults are somewhat conservative on their
limitations in order to simplify and maximise client connectivity - as
some stuff (especially java apps or older mobile devices) tend to
struggle otherwise with only a strict set of secure ciphers.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Best practices for docker setup on Centos 7?

[James Hogarth]

On 31 March 2017 at 07:11, Rafał Radecki  wrote:
> Hi All.
>
> I am currently running docker 1.13 on Centos 7 boxes with devicemapper
> storage plugin.
> I would like to know what are your experiences in regard to:
> - storage plugins
> - kernel versions
> - stability
>
> I consider upgrade to docker 17.03.1 and would like to choose most stable
> combination of kernel/storage plugin.
>


If you really want the most stable setup which is well tested with the
Red Hat environment I'd suggest to stop using upstream and use the
docker in the extras repo, which is the same as the docker in the RHEL
extras repo and is patched to work optimally with Red Hat and is
tested by them.

If you have plenty of block storage I'd use devicemapper with a thin
pool LVM setup.

We've recently switched to overlay2 as our graph driver, although that
is in a CI and nor prod environment ... you may want to carry out some
comparisons.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] firewalld management on a headless server

[James Hogarth]

On 30 March 2017 at 19:47, Mark Milhollan  wrote:
> On Wed, 29 Mar 2017, Robert Moskowitz wrote:
>>On 03/29/2017 07:38 AM, Leon Fauster wrote:
>
>>>We have good results with http://www.shorewall.net/ an iptables
>>>"abstraction".
>>>Despite its not a GUI, the streamlined configuration helps to be effective.
>>
> >From what I can determine, it is still iptables.  Not firewalld.
>
> That's what Leon said, shorewall is an iptables abstraction, and
> iptables is a command that manipulates netfilter.
>
> FirewallD is similar in that it abstracts and simplifies using netfilter
> without using the iptables command.  Which has a GUI that can be used
> remotely but it is not web based as requested.  Fedora's CoPilot
> probably has a module for it, but I don't know that it can be used with
> a CentOS based server.  Webmin likely has a module for it by now.
>
>

Minor correction here ... firewalld is an iptables abstraction like
shorewall and it doesn't link into netfilter directly.

You can see that here:

https://github.com/t-woerner/firewalld/blob/master/src/firewall/core/ipXtables.py
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] From Networkmanager to self managed configuration files

[James Hogarth]

On 9 March 2017 at 00:54, isdtor  wrote:
> Did I see an implicit "do as Red Hat says or else" there somewhere? Not 
> appropriate. Linux is not Windows (yet). In the heat of the moment it may 
> easily be forgotton that Linux is all about choice. We choose to run CentOS, 
> and we choose to run it the way we see fit. We appreciate the efforts that go 
> into the *Community* *Enterprise* OS, and if you have dealt with buggy crap 
> like Ubuntu or Fedora, you appreciate it even more. This does not imply 
> deference to upstream.
>
> That statement about "effectively [running] your own Linux distribution" is 
> scaremongering, at best. If there's one thing I've learned on this list, it's 
> realizing how many use cases, scenarios and solutions there are that can make 
> approaching the topic at hand without prejudice challenging at times.
>

You're reaching here.

It's simply there is good advice and sane management practices, and
there's bad advice and approaches to manage systems that have plenty
of clear issues and step way outside of the documented and supported
methods of handling things.

If you want to use a random script that has so many issues it's even
less supportable than the legacy network service, more power to you!
Just don't advise people entering into this area to do that and don't
expect much help from those more knowledgeable in those areas who
spend their own time assisting on the mailing list and IRC if you
insist on jumping off the cliff with your homemade parachute after
people have pointed out that patching it with small bits of cloth
wasn't the best of ideas ...
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] From Networkmanager to self managed configuration files

[James Hogarth]

On 8 March 2017 at 15:00, Giles Coochey  wrote:
>
>
> On 08/03/17 14:54, Jonathan Billings wrote:
>>
>>
>> If you'd like a really simple solution that avoids NetworkManager, I
>> suggest using systemd-networkd (both systemd-networkd and
>> systemd-resolved packages required).  I've used it to set up a bridge
>> on my workstattion for use with libvirtd/kvm, and it is just as simple
>> a text file but future compatible.  Heck, it probably even works on
>> other distros that use systemd.
>>
>> Here's a super-simple static configuration:
>>
>> # cat /etc/systemd/network/10-static-eno1.network
>> [Match]
>> name=eno1
>>
>> [Network]
>> Address=192.168.1.2
>> Gateway=192.168.1.1
>> DNS=192.168.1.1
>>
>> You need to make sure that /etc/resolv.conf is a symlink
>> /run/systemd/resolve/resolv.conf if you want the systemd-resolved
>> service to manage it.  Just disable NetworkManager and network
>> services and enable the systemd-networkd and systemd-resolved
>> services.
>>
>> Honestly, I've found systemd-networkd very useful for the more complex
>> networking on my workstation (bridged VMs to external network) but its
>> also useful for my tiny VMs that don't need extra daemons running.
>>
> That's interesting, I'll snapshot and perhaps take that tangent on the next
> build and see how it goes.
>

Incidentally as far back as NM 1.0 (part of the 7.1 milestone but not
part of the original 7.0 GA) it has supported a
'configure-and-quit=yes' option to just get the configuration right,
emit the events etc needed to tell services/system network is
configured and then get out of the way and not leave any running
daemon:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=1.0.0

I'll give that a test as part of my upcoming article looking at how NM
has changed since the original 7.0 release.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] From Networkmanager to self managed configuration files

[James Hogarth]

On 8 March 2017 at 13:16, Steve Clark  wrote:
> On 03/08/2017 07:39 AM, John Hodrien wrote:
>> On Wed, 8 Mar 2017, Steve Clark wrote:
>>
>>> Yes it is really hard!
>>>
>>> ip address add 192.168.0.1/24 dev enp0s25
>>> ip route add default via 192.168.0.254 dev enp0s25
>>> echo nameserver 8.8.8.8 > /etc/resolv.conf
>>> echo nameserver 8.8.4.4 >> /etc/resolv.conf
>> This is still a deliberately trivial case, as already said, with no
>> teaming/bonding/vlan type fun in the mix.
> Let us have a vote - how many of us do teaming/bonding/vlans on our servers?
> Our networking gear does that in our installation.
>
>

That makes little sense ...

Without cooperation of both endpoints (switch and host) LACP is not
possible (and this is generally the preferred teaming/bonding method).

Without cooperation of both endpoints (switch and host) trunking
multiple vlans (ie the time you would actually tag) is not possible.

That ridiculous "script" doesn't even handle the basic situation that
the NIC interface didn't come up for any reason ...
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] From Networkmanager to self managed configuration files

[James Hogarth]

On 8 March 2017 at 11:15, Alice Wonder  wrote:
> On 03/08/2017 01:57 AM, Giles Coochey wrote:
>>
>>
>>> The recommended configuration for EL7 is to use NetworkManager unless
>>> you have a very specific edge case preventing you from doing so:
>>>
>> The truth is a lot of us run servers that don't need to have their
>> network "managed" by Networkmanager.
>>
>
> My experience was very difficult going to 7.2 to 7.3 because of a change in
> the behavior of NetworkManager with respect to IPv6 but once I had it
> figured out (thanks to people on this list) it worked out quite well and I
> kept NetworkManager.
>
> But I certainly understand why some don't want to do that.


That's fine Alice (and I remember your issue well with the minimally
documented change to stable-privacy by default for new systems ...
argh I still need to write up a blog article about that) but in this
case the person concerned isn't even using the network service, which
if legacy and semi-deprecated is still supported, but just doing a
ridiculous and unsupportable mini script (I'm guessing from rc.local?)
which doesn't handle pretty much any actual networking issue that may
come up - eg failed/delayed interface.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] From Networkmanager to self managed configuration files

[James Hogarth]

On 8 March 2017 at 10:58, Giles Coochey  wrote:
>
>
> On 08/03/17 10:52, John Hodrien wrote:
>>
>>
>> It means you're stuck in your own hand crafted niche.  Which is fine, but
>> it's
>> up to you to maintain the niche, or you find yourself using obsolete tools
>> like ifconfig and route.
>>
>> I'd argue there's a gulf between keeping things simple and doing things
>> your
>> own way.
>>
> I'm sure there are drop in replacements for ifconfig and route, but even if
> deprecated I have not needed to revisit that script for many years, so I'm
> not changing it.
> When it does eventually break I have to look at four lines to discover where
> the problem might be, I can troubleshoot it by trying to run each line
> manually and see what is going on.
>
> When qw hit a bug in NetworkManager that breaks something specific that
> you're doing then you can try to raise a bug with upstream, or you could try
> to review the thousands of lines of code that make it up and try to fix the
> problem yourself.
>
> Or perhaps you'll do what I did, remove it and put in a 4 line script.
>


That's nice ... but what you've provided is terrible advice that
doesn't handle a wide range of scenarios such as teaming, bonding,
vlans, bridging, network interface changes, race conditions of things
dependent on networking or acting as part of the network.target or
network-online.target systemd units which declare when network is
ready ...

If you want to do something unsupportable in any sane environment that
is on you ... but really please don't suggest to those who don't know
better to carry out such activities.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] From Networkmanager to self managed configuration files

[James Hogarth]

On 8 March 2017 at 06:56, Andreas Benzler  wrote:
> Hello Guys,
>
> update my post, because of a route from ipv6 on same networkcard,
> with only ipv4 enabled
>
> Sincerely
>
> Andy
>
>

Please accept this as honest constructive criticism from someone who
also likes to blog.

On EL7 this is really bad advice:

> systemctl stop NetworkManager; systemctl disable NetworkManager; systemctl 
> mask NetworkManager

You may be interested in this article of mine:
https://www.hogarthuk.com/?q=node/8

The recommended configuration for EL7 is to use NetworkManager unless
you have a very specific edge case preventing you from doing so:

https://access.redhat.com/solutions/783533

The legacy network service is in effect deprecated, like net-tools
was, as no new features are being released for it and no RFE's are
being accepted. All future work is on NetworkManager.

Note as well this article was last updated in 2014 - NetworkManager
has been updated to handle more use cases than back then.

As always it's best to check with the upstream documentation:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/index.html

Finally there was nothing to do with IPv6 in your article.

That address was an IPv4 address and the zeroconf stuff configures the
169.254.0.0/16 network as a 'local link' network on that interface.

If it was IPv6 it would have an address like
fe80::33bb:5a14:be57:1690/64 ... which is an IPv6 link local address.

Regards,

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

Re: [CentOS] CentOS-5 End of Life

[James Hogarth]

On 3 March 2017 at 11:47, James Hogarth <james.hoga...@gmail.com> wrote:
> On 3 March 2017 at 11:34, John Hodrien <j.h.hodr...@leeds.ac.uk> wrote:
>> On Fri, 3 Mar 2017, Tony Mountifield wrote:
>>
>>> You mean just thrown away, or archived somewhere? Just thrown away would
>>> seem rather irresponsible...
>>
>>
>> Mirroring EPEL makes sense well before this point, as they don't keep old
>> versions of packages online either AFAIK.
>>
>> jh
>>
>>
>
> Indeed they aren't kept ... and since there hasn't been an EOL of EPEL
> before I honestly have no idea ... I've asked on the epel-devel
> mailing list as to whether it'll move to archive like old fedora
> releases do.

My mistake - I forgot there was an EPEL4 in the mists of time .. so
the last version of the repo is likely to end up here:

http://archive.fedoraproject.org/pub/epel/
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS-5 End of Life

[James Hogarth]

On 3 March 2017 at 11:34, John Hodrien  wrote:
> On Fri, 3 Mar 2017, Tony Mountifield wrote:
>
>> You mean just thrown away, or archived somewhere? Just thrown away would
>> seem rather irresponsible...
>
>
> Mirroring EPEL makes sense well before this point, as they don't keep old
> versions of packages online either AFAIK.
>
> jh
>
>

Indeed they aren't kept ... and since there hasn't been an EOL of EPEL
before I honestly have no idea ... I've asked on the epel-devel
mailing list as to whether it'll move to archive like old fedora
releases do.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS-5 End of Life

[James Hogarth]

On 2 Mar 2017 03:49, "John R Pierce"  wrote:

On 3/1/2017 7:28 PM, Tom Munro Glass wrote:

>
> Can you say exactly when in early April the tree will be moved? I have a
> number of installations that need to continue running CentOS 5 so I'd like
> to do a final update before the tree moves.
>

may I suggest building your own mirror well before then, update it with
rsync or lftp weekly (or even daily), from http://mirrors.xmission.com/ce
ntos/5  (pick your favorite mirror to make the mirror from), and replace
your CentOS-xxx.repo files with ones that point to your private repo

I use a command like this to mirror everything and incrementally update,
you could change the last centos to centos/5  if you want to just fetch and
update that...

   lftp -c 'open ftp://mirrors.sonic.net && lcd /mirrors && mirror
   --continue --verbose=1 -x SRPMS centos'

(yes, you do need to find a ftp mirror, i had issues mirroring from an http
server).


This is especially important if you use anything from EPEL as EPEL5 will be
removed when RHEL goes EOL.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Checksums for git repo content?

[James Hogarth]

On 23 February 2017 at 19:55, Lamar Owen  wrote:
> On 02/09/2017 03:12 PM, Johnny Hughes wrote:
>>
>> The patch files are in git as text files, right?  Why would you need
>> checksums of those? That is the purpose of git, right?
>>
> Not to stir up a hornets' nest, but how does Google's announcement at
> https://shattered.it affect this now?  (Executive summary: Google has
> successfully produced two different PDF files that hash to the same SHA-1.)
> There is a whole paragraph on 'How is GIT affected?'
>
>
>


To stave off another ridiculous thread - short version is simply "it isn't"
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] IPv6 broken on Linode

[James Hogarth]

On 16 February 2017 at 12:02, James Hogarth <james.hoga...@gmail.com> wrote:
> On 16 February 2017 at 11:46, James Hogarth <james.hoga...@gmail.com> wrote:
>> On 16 February 2017 at 11:35, Alice Wonder <al...@domblogger.net> wrote:
>>> On 02/16/2017 03:28 AM, James Hogarth wrote:
>>>>
>>>> On 16 February 2017 at 10:42, Alice Wonder <al...@domblogger.net> wrote:
>>>>>
>>>>> On 02/16/2017 02:32 AM, James Hogarth wrote:
>>>>>>
>>>>>>
>>>>>> On 16 February 2017 at 10:17, Alice Wonder <al...@domblogger.net> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 02/16/2017 02:03 AM, James Hogarth wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 16 February 2017 at 09:09, Alice Wonder <al...@domblogger.net>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In article <4cbb9dc4-f063-3434-b7a1-d4d0e6581...@domblogger.net>,
>>>>>>>>>> Alice Wonder <al...@domblogger.net> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://forum.linode.com/viewtopic.php?f=19=14570=72785
>>>>>>>>>>>
>>>>>>>>>>> I can not figure out what I need to do.
>>>>>>>>>>>
>>>>>>>>>>> Apparently according to linode support, the VM is trying to grab an
>>>>>>>>>>> IPv6
>>>>>>>>>>> address with some privacy stuff enabled by default causing it to
>>>>>>>>>>> not
>>>>>>>>>>> grab the IPv6 address that is assigned to me.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Does the accepted answer at the following link give you any useful
>>>>>>>>>> hints?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-when-using-ipv6
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>> Tony
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not really - I tried
>>>>>>>>>
>>>>>>>>> net.ipv6.conf.all.use_tempaddr = 0
>>>>>>>>>
>>>>>>>>> and it still fails to grab the proper IPv6
>>>>>>>>>
>>>>>>>>> -=-
>>>>>>>>>
>>>>>>>>> Just in case, I did ask Linode support to verify that my hardware
>>>>>>>>> address
>>>>>>>>> is
>>>>>>>>> what it is suppose to be. Still waiting to hear on that.
>>>>>>>>>
>>>>>>>>> ___
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> it still is key=value  ... it uses the ifcfg- files (via the rh
>>>>>>>> plugin) and they are all key=value
>>>>>>>>
>>>>>>>> It would be helpful if you could paste the journal output (journalctl
>>>>>>>> -u NetworkManager) from the time period of attempting to get an
>>>>>>>> address ...
>>>>>>>>
>>>>>>>> also the nmcli conn sh  information for the interface
>>>>>>>> along with your ifcfg- files
>>>

Re: [CentOS] IPv6 broken on Linode

[James Hogarth]

On 16 February 2017 at 11:46, James Hogarth <james.hoga...@gmail.com> wrote:
> On 16 February 2017 at 11:35, Alice Wonder <al...@domblogger.net> wrote:
>> On 02/16/2017 03:28 AM, James Hogarth wrote:
>>>
>>> On 16 February 2017 at 10:42, Alice Wonder <al...@domblogger.net> wrote:
>>>>
>>>> On 02/16/2017 02:32 AM, James Hogarth wrote:
>>>>>
>>>>>
>>>>> On 16 February 2017 at 10:17, Alice Wonder <al...@domblogger.net> wrote:
>>>>>>
>>>>>>
>>>>>> On 02/16/2017 02:03 AM, James Hogarth wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 16 February 2017 at 09:09, Alice Wonder <al...@domblogger.net>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In article <4cbb9dc4-f063-3434-b7a1-d4d0e6581...@domblogger.net>,
>>>>>>>>> Alice Wonder <al...@domblogger.net> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://forum.linode.com/viewtopic.php?f=19=14570=72785
>>>>>>>>>>
>>>>>>>>>> I can not figure out what I need to do.
>>>>>>>>>>
>>>>>>>>>> Apparently according to linode support, the VM is trying to grab an
>>>>>>>>>> IPv6
>>>>>>>>>> address with some privacy stuff enabled by default causing it to
>>>>>>>>>> not
>>>>>>>>>> grab the IPv6 address that is assigned to me.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Does the accepted answer at the following link give you any useful
>>>>>>>>> hints?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-when-using-ipv6
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> Tony
>>>>>>>>>
>>>>>>>>
>>>>>>>> Not really - I tried
>>>>>>>>
>>>>>>>> net.ipv6.conf.all.use_tempaddr = 0
>>>>>>>>
>>>>>>>> and it still fails to grab the proper IPv6
>>>>>>>>
>>>>>>>> -=-
>>>>>>>>
>>>>>>>> Just in case, I did ask Linode support to verify that my hardware
>>>>>>>> address
>>>>>>>> is
>>>>>>>> what it is suppose to be. Still waiting to hear on that.
>>>>>>>>
>>>>>>>> ___
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> it still is key=value  ... it uses the ifcfg- files (via the rh
>>>>>>> plugin) and they are all key=value
>>>>>>>
>>>>>>> It would be helpful if you could paste the journal output (journalctl
>>>>>>> -u NetworkManager) from the time period of attempting to get an
>>>>>>> address ...
>>>>>>>
>>>>>>> also the nmcli conn sh  information for the interface
>>>>>>> along with your ifcfg- files
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ifcfg-lo is the only one that exists on any of the servers - including
>>>>>> the
>>>>>> VMs that grab the correct IPv6 address.
>>>>>>
>>>>>> from /sbin/ifconfig -a :
>>>>>>
>>>>>
>>>>> For a start s

Re: [CentOS] IPv6 broken on Linode

[James Hogarth]

On 16 February 2017 at 11:35, Alice Wonder <al...@domblogger.net> wrote:
> On 02/16/2017 03:28 AM, James Hogarth wrote:
>>
>> On 16 February 2017 at 10:42, Alice Wonder <al...@domblogger.net> wrote:
>>>
>>> On 02/16/2017 02:32 AM, James Hogarth wrote:
>>>>
>>>>
>>>> On 16 February 2017 at 10:17, Alice Wonder <al...@domblogger.net> wrote:
>>>>>
>>>>>
>>>>> On 02/16/2017 02:03 AM, James Hogarth wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 16 February 2017 at 09:09, Alice Wonder <al...@domblogger.net>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> In article <4cbb9dc4-f063-3434-b7a1-d4d0e6581...@domblogger.net>,
>>>>>>>> Alice Wonder <al...@domblogger.net> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://forum.linode.com/viewtopic.php?f=19=14570=72785
>>>>>>>>>
>>>>>>>>> I can not figure out what I need to do.
>>>>>>>>>
>>>>>>>>> Apparently according to linode support, the VM is trying to grab an
>>>>>>>>> IPv6
>>>>>>>>> address with some privacy stuff enabled by default causing it to
>>>>>>>>> not
>>>>>>>>> grab the IPv6 address that is assigned to me.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Does the accepted answer at the following link give you any useful
>>>>>>>> hints?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-when-using-ipv6
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Tony
>>>>>>>>
>>>>>>>
>>>>>>> Not really - I tried
>>>>>>>
>>>>>>> net.ipv6.conf.all.use_tempaddr = 0
>>>>>>>
>>>>>>> and it still fails to grab the proper IPv6
>>>>>>>
>>>>>>> -=-
>>>>>>>
>>>>>>> Just in case, I did ask Linode support to verify that my hardware
>>>>>>> address
>>>>>>> is
>>>>>>> what it is suppose to be. Still waiting to hear on that.
>>>>>>>
>>>>>>> ___
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> it still is key=value  ... it uses the ifcfg- files (via the rh
>>>>>> plugin) and they are all key=value
>>>>>>
>>>>>> It would be helpful if you could paste the journal output (journalctl
>>>>>> -u NetworkManager) from the time period of attempting to get an
>>>>>> address ...
>>>>>>
>>>>>> also the nmcli conn sh  information for the interface
>>>>>> along with your ifcfg- files
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ifcfg-lo is the only one that exists on any of the servers - including
>>>>> the
>>>>> VMs that grab the correct IPv6 address.
>>>>>
>>>>> from /sbin/ifconfig -a :
>>>>>
>>>>
>>>> For a start stop using ifconfig ... it's broken at this point on
>>>> linux, especially on multi ip and ipv6 scenarios
>>>>
>>>> Use `ip -6 addr sh` for ipv6 specfic stuff, or just ip addr sh to see
>>>> all IP address stuff regardless of family
>>>>
>>>>> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>>>>> inet 178.79.185.217  netmask 255.255.255.0  broadcast
>>

Re: [CentOS] IPv6 broken on Linode

[James Hogarth]

On 16 February 2017 at 10:42, Alice Wonder <al...@domblogger.net> wrote:
> On 02/16/2017 02:32 AM, James Hogarth wrote:
>>
>> On 16 February 2017 at 10:17, Alice Wonder <al...@domblogger.net> wrote:
>>>
>>> On 02/16/2017 02:03 AM, James Hogarth wrote:
>>>>
>>>>
>>>> On 16 February 2017 at 09:09, Alice Wonder <al...@domblogger.net> wrote:
>>>>>
>>>>>
>>>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> In article <4cbb9dc4-f063-3434-b7a1-d4d0e6581...@domblogger.net>,
>>>>>> Alice Wonder <al...@domblogger.net> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://forum.linode.com/viewtopic.php?f=19=14570=72785
>>>>>>>
>>>>>>> I can not figure out what I need to do.
>>>>>>>
>>>>>>> Apparently according to linode support, the VM is trying to grab an
>>>>>>> IPv6
>>>>>>> address with some privacy stuff enabled by default causing it to not
>>>>>>> grab the IPv6 address that is assigned to me.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Does the accepted answer at the following link give you any useful
>>>>>> hints?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-when-using-ipv6
>>>>>>
>>>>>> Cheers
>>>>>> Tony
>>>>>>
>>>>>
>>>>> Not really - I tried
>>>>>
>>>>> net.ipv6.conf.all.use_tempaddr = 0
>>>>>
>>>>> and it still fails to grab the proper IPv6
>>>>>
>>>>> -=-
>>>>>
>>>>> Just in case, I did ask Linode support to verify that my hardware
>>>>> address
>>>>> is
>>>>> what it is suppose to be. Still waiting to hear on that.
>>>>>
>>>>> ___
>>>>
>>>>
>>>>
>>>>
>>>> it still is key=value  ... it uses the ifcfg- files (via the rh
>>>> plugin) and they are all key=value
>>>>
>>>> It would be helpful if you could paste the journal output (journalctl
>>>> -u NetworkManager) from the time period of attempting to get an
>>>> address ...
>>>>
>>>> also the nmcli conn sh  information for the interface
>>>> along with your ifcfg- files
>>>
>>>
>>>
>>> ifcfg-lo is the only one that exists on any of the servers - including
>>> the
>>> VMs that grab the correct IPv6 address.
>>>
>>> from /sbin/ifconfig -a :
>>>
>>
>> For a start stop using ifconfig ... it's broken at this point on
>> linux, especially on multi ip and ipv6 scenarios
>>
>> Use `ip -6 addr sh` for ipv6 specfic stuff, or just ip addr sh to see
>> all IP address stuff regardless of family
>>
>>> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>>> inet 178.79.185.217  netmask 255.255.255.0  broadcast
>>> 178.79.185.255
>>> inet6 fe80::a8ad:d312:4ef4:7272  prefixlen 64  scopeid 0x20
>>> inet6 2a01:7e00::825f:e564:ad53:72fc  prefixlen 64  scopeid
>>> 0x0
>>> ether f2:3c:91:18:8a:7e  txqueuelen 1000  (Ethernet)
>>> RX packets 9903  bytes 1088621 (1.0 MiB)
>>> RX errors 0  dropped 0  overruns 0  frame 0
>>> TX packets 7786  bytes 1087223 (1.0 MiB)
>>> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>>
>>> That hardware address - the 18:8a:7e corresponds with what the IPv6
>>> address
>>> is suppose to be. But that's not the address it is grabbing, despite the
>>> fact that net.ipv6.conf.all.use_tempaddr = 0 is set.
>>>
>>> I'm seriously wondering if the real issue is a mis-configured dhcp server
>>> in
>>> their London facility because nothing makes sense.
>>>
>>> journalctl -u NetworkManager
>>>
>>> reports no journal entries found.
>>>
>>
>> So are you not using NetworkManager then? there should be some logs 

Re: [CentOS] IPv6 broken on Linode

[James Hogarth]

On 16 February 2017 at 10:17, Alice Wonder <al...@domblogger.net> wrote:
> On 02/16/2017 02:03 AM, James Hogarth wrote:
>>
>> On 16 February 2017 at 09:09, Alice Wonder <al...@domblogger.net> wrote:
>>>
>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote:
>>>>
>>>>
>>>> In article <4cbb9dc4-f063-3434-b7a1-d4d0e6581...@domblogger.net>,
>>>> Alice Wonder <al...@domblogger.net> wrote:
>>>>>
>>>>>
>>>>> https://forum.linode.com/viewtopic.php?f=19=14570=72785
>>>>>
>>>>> I can not figure out what I need to do.
>>>>>
>>>>> Apparently according to linode support, the VM is trying to grab an
>>>>> IPv6
>>>>> address with some privacy stuff enabled by default causing it to not
>>>>> grab the IPv6 address that is assigned to me.
>>>>
>>>>
>>>>
>>>> Does the accepted answer at the following link give you any useful
>>>> hints?
>>>>
>>>>
>>>>
>>>> http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-when-using-ipv6
>>>>
>>>> Cheers
>>>> Tony
>>>>
>>>
>>> Not really - I tried
>>>
>>> net.ipv6.conf.all.use_tempaddr = 0
>>>
>>> and it still fails to grab the proper IPv6
>>>
>>> -=-
>>>
>>> Just in case, I did ask Linode support to verify that my hardware address
>>> is
>>> what it is suppose to be. Still waiting to hear on that.
>>>
>>> ___
>>
>>
>>
>> it still is key=value  ... it uses the ifcfg- files (via the rh
>> plugin) and they are all key=value
>>
>> It would be helpful if you could paste the journal output (journalctl
>> -u NetworkManager) from the time period of attempting to get an
>> address ...
>>
>> also the nmcli conn sh  information for the interface
>> along with your ifcfg- files
>
>
> ifcfg-lo is the only one that exists on any of the servers - including the
> VMs that grab the correct IPv6 address.
>
> from /sbin/ifconfig -a :
>

For a start stop using ifconfig ... it's broken at this point on
linux, especially on multi ip and ipv6 scenarios

Use `ip -6 addr sh` for ipv6 specfic stuff, or just ip addr sh to see
all IP address stuff regardless of family

> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> inet 178.79.185.217  netmask 255.255.255.0  broadcast 178.79.185.255
> inet6 fe80::a8ad:d312:4ef4:7272  prefixlen 64  scopeid 0x20
> inet6 2a01:7e00::825f:e564:ad53:72fc  prefixlen 64  scopeid
> 0x0
> ether f2:3c:91:18:8a:7e  txqueuelen 1000  (Ethernet)
> RX packets 9903  bytes 1088621 (1.0 MiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 7786  bytes 1087223 (1.0 MiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>
> That hardware address - the 18:8a:7e corresponds with what the IPv6 address
> is suppose to be. But that's not the address it is grabbing, despite the
> fact that net.ipv6.conf.all.use_tempaddr = 0 is set.
>
> I'm seriously wondering if the real issue is a mis-configured dhcp server in
> their London facility because nothing makes sense.
>
> journalctl -u NetworkManager
>
> reports no journal entries found.
>

So are you not using NetworkManager then? there should be some logs ...


> I think the problem must be on their end.
>
> It all was working fine until they migrated the VM because of a hardware
> issue, and I suspect now all the hardware address privacy stuff being the
> issue is barking up the wrong tree because all the reading I have done seems
> to indicate that with
>
> net.ipv6.conf.all.use_tempaddr = 0
>
> that a fake temporary hardware address would not be sent to their dhcp
> server when obtaining the address, but the real one, that should be fetching
> my assigned address.

Only if the kernel is doing SLAAC ... if other things (eg NM) are
handling it directly they may act differently ... but then from the
lack of logs is NM actually handling this?

Does systemctl status NetworkManager show it running and does nmcli
show anything?


>
> It's all very frustrating but I suspect now the problem isn't the CentOS
> network configuration.
>

Sounds likely ... depending on what there RA's say and how dhcpv6 is
being handled there (if at all) it could drastically affect things -
particularly if MAC changed on migration.

> Five other servers all configured the same (started from same CentOS 7 image
> and network stuff left alone) work properly - so I don't know.
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] IPv6 broken on Linode

[James Hogarth]

On 16 February 2017 at 09:09, Alice Wonder  wrote:
> On 02/16/2017 12:54 AM, Tony Mountifield wrote:
>>
>> In article <4cbb9dc4-f063-3434-b7a1-d4d0e6581...@domblogger.net>,
>> Alice Wonder  wrote:
>>>
>>> https://forum.linode.com/viewtopic.php?f=19=14570=72785
>>>
>>> I can not figure out what I need to do.
>>>
>>> Apparently according to linode support, the VM is trying to grab an IPv6
>>> address with some privacy stuff enabled by default causing it to not
>>> grab the IPv6 address that is assigned to me.
>>
>>
>> Does the accepted answer at the following link give you any useful hints?
>>
>>
>> http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-when-using-ipv6
>>
>> Cheers
>> Tony
>>
>
> Not really - I tried
>
> net.ipv6.conf.all.use_tempaddr = 0
>
> and it still fails to grab the proper IPv6
>
> -=-
>
> Just in case, I did ask Linode support to verify that my hardware address is
> what it is suppose to be. Still waiting to hear on that.
>
> ___


it still is key=value  ... it uses the ifcfg- files (via the rh
plugin) and they are all key=value

It would be helpful if you could paste the journal output (journalctl
-u NetworkManager) from the time period of attempting to get an
address ...

also the nmcli conn sh  information for the interface
along with your ifcfg- files
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, systemd, NetworkMangler, oh, my

[James Hogarth]

On 15 Feb 2017 16:40, "Always Learning" <cen...@u68.u22.net> wrote:


On Mon, 2017-02-13 at 16:49 +0000, James Hogarth wrote:



> On EL6 yes NM should be removed on anything but a wifi system but on
> EL7 unless you fall into a specific edge case as per the network docs:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_
Enterprise_Linux/7/html-single/Networking_Guide/index.html
>
> you really should be using NM for a variety of reasons.
>
> Incidentally Mark, this had nothing to do with systemd ... I wish you
> would pick your topics a little more appropriately rather than
> tempting the usual flames.

Mark actually gets his hands dirty running the systems (on C7). He has a
valid point which worries me - Red Hat's gradual imitation of Micro
$oft's aversion to ordinary people understanding and controlling their
systems.

Luckily some of us remain on C6 because we love simplicity and
stability. When C6 expires some will migrate to BSD rather than face
C7's persistent difficulties and confusion.


And no he doesn't have a point because that's nonsense

And course with the subject chosen this whole thread burned into flames
rather than being constructive

Can we just kill this now and if there is actually something wrong have a
fresh thread with diagnostics?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, systemd, NetworkMangler, oh, my

[James Hogarth]

On 13 February 2017 at 16:17, peter.winterflood
 wrote:
>
>
>
> there's a really good solution to this.
>
> yum remove NetworkManager*
>
> chkconfig network on
>
> service network start
>
> and yes thats all under fedora 25, and centos 7.
>
> works like a charm.
>
> sometimes removing NM leaves resolv.conf pointing to the networkmanager
> directory, and its best to check this, and replace your resolv.conf link
> with a file with the correct settings.
>
> sorry if this upsets the people who maintain network mangler, but its
> inappropriate on a server.
>
>

This is terribly bad advice I'm afraid ...

https://access.redhat.com/solutions/783533

The legacy network service is a fragile compilation of shell scripts
(which is why certain changes like some bonding or tagging alterations
require a full system restart or very careful unpicking manually with
ip) and is effectively deprecated in RHEL at this time due to major
bug fixes only but no feature work.

You really should have a read through this as well:

https://www.hogarthuk.com/?q=node/8

On EL6 yes NM should be removed on anything but a wifi system but on
EL7 unless you fall into a specific edge case as per the network docs:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Networking_Guide/index.html

you really should be using NM for a variety of reasons.

Incidentally Mark, this had nothing to do with systemd ... I wish you
would pick your topics a little more appropriately rather than
tempting the usual flames.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, systemd, NetworkMangler, oh, my

[James Hogarth]

On 13 February 2017 at 15:35,   wrote:
> My manager tells me a system in the datacenter is down. I go down there,
> and plug in a monitor-on-a-stick and keyboard. It's up, but no network. I
> try systemctl restart NetworkManager several times, and ip a shows *no*
> change.
>
> Finally, I do an ifdown, followed by an ifup, and everything's wonderful.
>
> My manager thinks that the NM daemon thinks everything's fine, and
> there've been no changes, so it does nothing. He suggests that it might
> have to be stopped, then started, rather than restarted.
>
> This is completely unacceptable behavior, since it leave the system with
> no network connection. Pre-systemd, as we all know, restart *RESTARTED*
> the damn thing.
>
> Is there some Magic (#insert "pixie-dust-sparkles") incantation, either
> restarting NetworkManager, or using nm-cli, to force it to perform the
> expected actions?
>


I'd be interested in the journal from the NetworkManager restart as
that's not the way it behaves ... it uses the netlink API to get state
and not it's own internal tracker of state (ie doing an ip link down
will reflect in nmcli output) ... a restart of NetworkManager should
not ignore interfaces but rather bring the system to the on disk
configured state ... and a quick check it doesn't override ExecRestart
in the unit file to do a reload or similar instead ...

And indeed a quick test in a VM shows nmcli device status correctly
changing between connected and unavailable when doing ip link set eth0
down/up

Do note that on a NM based system ifup and ifdown are effectively
aliases to nmcli conn down and nmcli conn up

nmcli conn down "connection name" will make it disconnected
nmcli conn up "connection mame" will bring it back to connected

there is a slight interesting difference between using nmcli and ip
link set though ...

with ip link set down  the interface is marked
administratively down (as if you've pulled the cable) but nmcli conn
down "connection name" will unconfigure the interface but leave it in
an UP state ... just without an IP address etc

anyway that's just an interesting diversion on behavioural differences

NM won't change an interface state without some sort of event though
(manual or virtual cable pulled etc), and if you have a case where it
*has* done that then you have found a bug that would be great to get
reported

TL;DR: cannot reproduce, need logs to determine what happened without
a working crystal ball
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] firewalld

[James Hogarth]

On 28 January 2017 at 13:44, Mike McCarthy, W1NR  wrote:
> firewalld isn't the only thing that will prevent services from accessing
> the internet. I found that I needed to do a relabel before postfix could
> access DNS and I have seen other issues as well. Have you tried
> disabling the firewall to see if you can get connections to work? Then
> try to disable SElinux and see if that works.
>
> # netstat --inet -l -n
>
> Is the service listening on port 143?
>


Just a side note here, since EL7 removed net-tools from the default
install (after all it has been deprecated for about a decade now) you
probably should get used to providing advice using the iproute2 suite
instead.

In this case `ss -tlnp` to list all tcp ports in a listening state,
showing the pid using the port and not resolving the ports to friendly
names.

For an example of why this is important think about using pacemaker or
keepalived to manage IPs migrating between systems. They won't be
visible using ifconfig but only via ip as they aren't exposed in the
kernel structures that ifconfig uses -
https://www.hogarthuk.com/?q=node/6

Another example is when you have multiple interfaces and you have
source policy routing (or similar advanced routing behaviour) that
makes use of rules and multiple routing tables. The older route
command is only capable of displaying the default main table, not the
rest of the tables in use, but `ip route show table all` will give you
all the routing tables in use on your system (even in a default
install it's a lot more than the route command shows) and ip rule
gives you the rules in use, if any.

On a similar note bridge-utils is also deprecated, though brctl is
ingrained into many minds!

https://fedoramagazine.org/build-network-bridge-fedora/
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] firewalld

[James Hogarth]

On 28 January 2017 at 12:01, TE Dukes <tdu...@palmettoshopper.com> wrote:
>
>
>> -Original Message-
>> From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of James
>> Hogarth
>> Sent: Saturday, January 28, 2017 4:18 AM
>> To: CentOS mailing list
>> Subject: Re: [CentOS] firewalld
>>
>> On 28 Jan 2017 3:02 am, "TE Dukes" <tdu...@palmettoshopper.com> wrote:
>>
>>
>>
>> > -Original Message-
>> > From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Gordon
>> > Messmer
>> > Sent: Friday, January 27, 2017 9:23 PM
>> > To: CentOS mailing list
>> > Subject: Re: [CentOS] firewalld
>> >
>> > On 01/27/2017 06:01 PM, TE Dukes wrote:
>> > > I telnet localhost 143, I get connection refused.
>> > >
>> > > What zone is used for the local network and what zone is used for
>> > > outside access?
>> >
>> > All traffic from localhost is allowed.  No zone is involved.
>> >
>> > The zone for "outside" access depends on which interface receives the
>> > packet, and what zone you've put that interface in.  I believe that
>> defaults to
>> > "public."
>>
>>  I'm telneting in from ssh on a machine on the local network, still
> getting
>> connection refused.
>>
>> The zone apparently means something because an interface can only be on
>> one.
>> Moving it to a different zone results in the same error (same
> services/ports
>> opened in each zone).
>>
>> I may as well disable firewalld and let my router handle the firewall.
>>
>> I don't plan to use my server as a workstation.
>>
>>
>> Have a read through this and then decide on if you want to use it or not.
>>
>> You can also switch to iptables-service and mask firewalld if you want the
>> same behaviour as in C6.
>>
>> 7.3 also has nftables as a tech preview, but I've not finished my article
> on that
>> yet.
>
> I saw something about that somewhere.
>
> Did you forget a link?
>
> Thanks
>

Oops you're right I did ...

https://www.hogarthuk.com/?q=node/9
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] firewalld

[James Hogarth]

On 28 Jan 2017 3:02 am, "TE Dukes"  wrote:



> -Original Message-
> From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Gordon
> Messmer
> Sent: Friday, January 27, 2017 9:23 PM
> To: CentOS mailing list
> Subject: Re: [CentOS] firewalld
>
> On 01/27/2017 06:01 PM, TE Dukes wrote:
> > I telnet localhost 143, I get connection refused.
> >
> > What zone is used for the local network and what zone is used for
> > outside access?
>
> All traffic from localhost is allowed.  No zone is involved.
>
> The zone for "outside" access depends on which interface receives the
> packet, and what zone you've put that interface in.  I believe that
defaults to
> "public."

 I'm telneting in from ssh on a machine on the local network, still getting
connection refused.

The zone apparently means something because an interface can only be on one.
Moving it to a different zone results in the same error (same services/ports
opened in each zone).

I may as well disable firewalld and let my router handle the firewall.

I don't plan to use my server as a workstation.


Have a read through this and then decide on if you want to use it or not.

You can also switch to iptables-service and mask firewalld if you want the
same behaviour as in C6.

7.3 also has nftables as a tech preview, but I've not finished my article
on that yet.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] disable/mask NetworkManager leads to unit startup fails

[James Hogarth]

On 17 January 2017 at 10:28, Oberdorfer Patrick
 wrote:
> Thank you very much James for your deep explaining answer!
> That cleared everything up for me and yes that helped a lot.
>
> Have a nice day :)
>
>

No problem, glad it was helpful.

Incidentally if there are services you need ordered after
network-online.target you don't need to (and shouldn't) edit the unit
files for the services directly.

Instead you should just provide an override with the additional
dependency so that systemd merges the two automatically and so future
updates of $package don't break on changes to the unit file in
/usr/lib/systemd/system and any changes to the unit file get picked up
for your system automatically, if the route you go down to resolve
your use case is via systemd dependency declaration rather than kernel
sysctl or application freebind behaviour.

In the case of nginx, for example, you'd do this:

mkdir /etc/systemd/systemd/nginx.service.d
cat > /etc/systemd/systemd/nginx.service.d/after-network-online.conf 

Re: [CentOS] disable/mask NetworkManager leads to unit startup fails

[James Hogarth]

On 16 January 2017 at 15:24, Oberdorfer Patrick
 wrote:
> Hello!
>
>
>
> For me it was best practice to disable "NetworkManager" on headless
> installations.
>
> Now suddenly I ran into an problem with several programs not starting
> correctly upon boot anymore.
>
> The problem seems to be that their unit files contain "After=network.target"
> but network.target wont wait till network is up and working, just waits for
> some low level network stuff.
>
>
>
> Now I read that it would be good practice to edit this and use
> "After=network-online.target" instead. But I don't want to touch several
> systemd unit files shipped via rpm packages.
>
>
>
> Software like unbound, postfix and so on which needs to bind to ip+port on
> startup fails on my systems now since I disabled NetworkManager.
>
>
>
> What solved the problem for me was to install "systemd-networkd" instead and
> enable it upon boot.
>
> It's system unit file pulls in "network.target" as "Wants" this way software
> that says "After=network.target" will start after network cards are
> configured. Why there is this behavior I haven't found out yet.
>
>
>
> Whats your best practice to archieve stable networking upon reboot? Do you
> use NetworkManager or systemd-networkd or maybe something exotic anyway?
>
>
>


Use NetworkManager ... it's the supported RH configuration tool.

This article is a little old (7.3 had a NM rebase and I've not
revisited it yet ... the prime gain in 7.3 though is arbitrary
layering of vlan/bridge/bond/etc negating the caveat at the end for
edge case).

https://www.hogarthuk.com/?q=node/8

As for the targets ... man systemd.special to get a better understanding:

https://www.freedesktop.org/software/systemd/man/systemd.special.html

By default services you install will listen on all interfaces, usually
a configuration with something like ListenAddress :: to indicate this
(there is an internal ipv6->ipv4 translation going on so you only
should listen on :: and not 0.0.0.0 as well) ... when a service binds
to a port on all addresses then the address does not need to exist yet
- the kernel just handles it.

If you configure your service to bind on a specific IP though then
they way the binding system call works it already needs to exist (by
default) which is why with the default configuration if the service
tries to start before the IPs are applied (quite likely given parallel
startup) you have a nice race condition and a fairly high likelihood
of failure.

There's two ways to handle this - and it depends on the service.

You can order it via after (and potential requires if you want no
attempt to start the service if the target fails to activate)
network-online.target (see referenced man page) which won't be
complete until at least one IP is on any interface.

If it's your own application and you can set the flags on the actual
bind then you can use so_freebind on the socket opened, some
applications may have this as a compile time or configurable option.

Another option is to enable net.ipv4.ip_nonlocal_bind and
net.ipv6.ip_nonlocal_bind which allows the kernel to bind a socket on
an IP it doesn't have (do note the caveat it may break some things).

https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

If it's a systemd socket being used by the service then you can enable
the freebind option via FreeBind=true

https://www.freedesktop.org/software/systemd/man/systemd.socket.html

Overall you may be interested in this:

https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

I really wouldn't use systemd-network on CentOS as a general thing as
it's basically undocumented/unsupported by Red Hat at this time, with
NM being their actual supported solution.

https://access.redhat.com/solutions/783533 <-- network Vs NetworkManager

https://access.redhat.com/solutions/876183 <-- no systemd alternative
for NM in EL7


Hope that helps and explains things!
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 7 dhcpd failure to allow a 2nd network over same interal nic

[James Hogarth]

On 14 Jan 2017 8:01 pm, "Gregory P. Ennis"  wrote:

Everyone,

I am trying to set up a second internal network  (192.168.0.0/24) and
have not been able to get dhcp to start when I have the following in my
dhcpd.conf file :

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.110 192.168.0.130;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;
option domain-name-servers 192.168.0.1;
}

When i remove the above from dhcpd.conf dhcpd works perfectly

I have my internal nic card set with two ip addresses one of which is
192.168.0.1. the other address is my standard internal network address.

I have also set up the domain server to allow access from
192.168.0.0/24, and the firewall allows internal access to the same
subnet.

The error that I get is the following :

Job for dhcpd.service failed because the control process exited with error
code. See "systemctl status dhcpd.service" and "journalctl -xe" for details.

When I evaluate journalctl -xe the following is obtained :

dhcpd[18763]: Internet Systems Consortium DHCP Server 4.2.5
dhcpd[18763]: Copyright 2004-2013 Internet Systems Consortium.
dhcpd[18763]: All rights reserved.
dhcpd[18763]: For info, please visit https://www.isc.org/software/dhcp/
dhcpd[18763]: Not searching LDAP since ldap-server, ldap-port and
ldap-base-dn were not specified in the config file
dhcpd[18763]: Internet Systems Consortium DHCP Server 4.2.5
dhcpd[18763]: Copyright 2004-2013 Internet Systems Consortium.
dhcpd[18763]: All rights reserved.
dhcpd[18763]: For info, please visit https://www.isc.org/software/dhcp/
dhcpd[18763]: Wrote 0 deleted host decls to leases file.
dhcpd[18763]: Wrote 0 new dynamic host decls to leases file.
dhcpd[18763]: Wrote 2 leases to leases file.
dhcpd[18763]: Interface enp0s29u1u2 matches multiple shared networks
dhcpd[18763]:
dhcpd[18763]: This version of ISC DHCP is based on the release available
dhcpd[18763]: on ftp.isc.org.  Features have been added and other
changes
dhcpd[18763]: have been made to the base software release in order to
make
dhcpd[18763]: it work better with this distribution.
dhcpd[18763]:
dhcpd[18763]: Please report for this software via the CentOS Bugs
Database:
dhcpd[18763]: http://bugs.centos.org/
dhcpd.service: main process exited, code=exited, status=1/FAILURE
dhcpd[18763]:
systemd[1]: Failed to start DHCPv4 Server Daemon.

When I review the information about dhcpd it appears that it can manage
the ip addresses for two networks on different nic cards, but is there a
problem in having it manage two networks on the same nic card?

Does anyone have any ideas?  Would sure appreciate your help.


Can you be a little clearer in what you're trying to do, as in the end goal
you are trying to reach?

Having dhcp for two different networks on the same physical network is just
not going to work in any sane fashion...

If you want to serve different dhcp pools to different physical networks
then you could do that via vlan and trunking from the switch to the server
or just ip-helper configuration on the router between the network
boundaries.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7 and systemd: SysV initscript: how detect boot vs. interactive use?

[James Hogarth]

On 18 Dec 2016 10:59, "whitivery"  wrote:

Moving from CentOS 5 to CentOS 7, discovered that a test in a SysV
initscript for whether it is running interactively, instead of at boot
time, no longer works.

Under CentOS 7 / systemd, is there some way for the initscript to know
this?


Generally "interactive" init scripts are not in any way supported under any
RHEL version and can't be done under systemd on EL7

What is it that it does and you are actually trying to achieve?

If it's a password or something like that it's possible to integrate with
the systemd-ask-password facility from a unit file, but it is quite complex
relatively speaking so it'd be useful to know the actual goal in mind
before going down this road.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] RHEL 7.3 released

[James Hogarth]

As a heads up RHEL 7.3 is released:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.3_Release_Notes/index.html

Pay careful attention when the CR repo starts churning out RPMs (if
you have CR enabled) as there have been a few rebases in this -
notably firewalld, NetworkManager, freeIPA, libreoffice, samba,
amongst others

If you have an ipv6 environment ping is now ipv6 aware and ping6 is
removed (with a symlink to ping for compatibility).

On the SSL side of things pycurl now handles TLS 1.1 and 1.2 and
openJDK8 can handle ECC.

With the NetworkManager rebase more complicated arbitrary layering of
interfaces is possible (eg physical -> team -> vlan -> bridge), which
I'll be revisiting my old NM article to investigate soon, and Wi-Fi
scanning will use a randomised MAC ... this may affect some people.
For a known BSSID the connect won't be a randomised MAC though just
when scanning.

The firewalld zones become a bit more usable with ipsets being usable
to define the zone making management of which networks go in which
zones a bit nicer - I'll be revisiting my old firewalld article to
investigate this too.

The deprecation of the old net-tools suite continues with bridge-utils
no longer required in many circumstances as iproute2 gets improved
bridge capabilties... this brings EL7 inline with the Fedora
behaviour:

https://fedoramagazine.org/build-network-bridge-fedora/

On the network side of things be aware of a potentially breaking
change to systems in how device names are created, this will only
affect systems that have exceptionally long device names:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/7.3_Release_Notes/index.html#bug_fixes_general_updates

For fresh installs using automatic partitioning the default /boot size
has been bumped to 1G ... for kickstarts and other automated installs
you may want to tweak your setups to match.

The NSS bug that caused problems with reusing SSL sessions and was
breaking owncloud setups has been resolved - I have not tested this
yet and will be doing so this weekend. The impending owncloud 9.1.1
EL7 release in EPEL7 will be removing my workaround and require this
for full correct functionality.

In the tech preview world nftables joins the testing group (I'll have
articles up exploring this new firewalling method in the coming weeks)
for networking. Whilst with storage overlayfs and btrfs remain in tech
preview status - with cephfs joining them... as notable pieces.
There's also new pNFS stuff.

This is only a small snippet of things that jumped out relevant to me
personally. As always make sure you read through the release notes in
full. to be ready once CentOS starts producing the RPMs, and keep in
mind this early in the lifecycle there are a fair few rebases and new
features implemented that should be tested... unlike later on in the
lifecycles (eg EL6) where no/minimal rebasing happens and changes at a
feature level don't happen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] rpmbuild question

[James Hogarth]

On 26 Oct 2016 6:17 pm, "Frank Cox"  wrote:
>
> On Wed, 26 Oct 2016 13:07:43 -0400
> m.r...@5-cent.us wrote:
>
> > I'm trying to build it in /root/rpmbuild.
>
> Don't do that.  Install rpmdevtools so you build it under your home
directory and avoid blowing up your system if there's an error.
>

First of all read up on how to properly build an RPM:

https://www.hogarthuk.com/?q=node/11

Since this is python look up the Fedora python guidelines and follow those.

Here's the spec for a recent python library I packaged:

https://pkgs.fedoraproject.org/cgit/rpms/python-ntlm3.git/tree/python-ntlm3.spec

If you don't need python3 you can strip that stuff out ...

The Fedora python guidelines have a decent spec template you can crib, keep
in mind the el6 caveats if you need to build for that with regards to macro
definitions
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] PHP vulnerability CVE-2016-4073

[James Hogarth]

On 21 September 2016 at 19:00, Alice Wonder  wrote:
>
>
> On 09/21/2016 05:43 AM, Прокси wrote:
>>
>> On 2016-Sep-21 14:35, Adrian Sevcenco wrote:
>>>
>>> On 09/21/2016 02:02 PM, Прокси wrote:

 Hello,

 My server with CentOS 6.8 just failed PCI scan, so I'm looking into
 vulnerable packages. PHP 5.3.3 have multiple vulnerabilities, some of
 them are fixed/patched or have some kind of workaround. But I can't find
 a way to fix this one. Red Hat state: under investigation.

 https://access.redhat.com/security/cve/cve-2016-4073

 This CVE is 6 months old, and it doesn't look like it will be fixed.
 Does anyone knows the way to go around this? Except blocking mb_strcut()
 function.
>>>
>>> you could try the unsupported php from remi repos... you can find there
>>> php 7.0 ..
>>
>>
>> I use CentOS because I need stable and patched packages, so I can be
>> sure that all applications work without unpleasant surprises. Going to
>> unsupported packages would be my last option.
>
>
> I feel the same way but I find that it is generally safe and beneficial to
> update the LAMP stack on servers and the multimedia stack on the desktop.
>
> Things like HTTP/2 are not available in the Apache that ships even with
> CentOS 7 and the PHP is so outdated that it causes problems when using third
> party projects because the developers of those projects aren't using
> anything that old anymore. And for the TLS stack, mobile really benefits
> from chacha20 ciphers.
>
> With respect to multimedia, there's the fluendo codec pack but interestingly
> FireFox won't play mp3 with the fluendo codec pack, it wants the libmad
> plugin.
>
> And even more bizarre, maybe they have fixed it, but GStreamer 1.x in CentOS
> 7 when it shipped was not capable of decoding the VP9 codec used in WebM2.
> CentOS 7 came with tools to encode VP9 but the GStreamer was too crusty to
> decode it, and the commercial fluendo plugins were of no help there -
> replacing the GStreamer 1.x packages with a modern build was the only
> option.
>
> Stability is pointless when it doesn't serve the intended purpose.
>
> PHP even in CentOS 7 should be updated for a production server.
>


Of course this is where Red Hat intends SCL to fill the gap of the
"supported" new httpd24 and php56 on RHEL ...

https://www.hogarthuk.com/?q=node/15

Unfortunately this is having a knock on effect in the EPEL world
where, since Fedora has no SCL packaging guidelines and RHSCL is not
included in repos EPEL can get built against, we can't package any
applications there that need the newer functionality from RHSCL ...

If, for example, ownCloud were to raise their minimum PHP requirements
from 5.4 to 5.6 (which honestly would be reasonable at this point) I'd
have no choice but to retire the ownCloud packages from EPEL7, just
like I had to retire it from EPEL6 with the PHP5.3 limitation there.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to build rpm

[James Hogarth]

On 29 July 2016 at 05:12, qw  wrote:

> Hi,
>
> For software development, projects are built through makefile. After
> building, I can run binary program. rpm is more convenient. Is there some
> tool that can build rpm?
>
> Thanks!
>
>
>
Rather than googling for articles, which unless you have the experience
already to filter the chaff from the wheat, here's a link the an article I
wrote a little while back.

https://www.hogarthuk.com/?q=node/11

It'll take you through building a minimal package, fedora guidelines (which
even for personal/internal stuff can help keep clean easier to maintain
spec files), usage of mock for clean builds and repo creation.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] firewall-config not functional

[James Hogarth]

On 7 Jun 2016 12:44, "Emmett Culley"  wrote:
>
> I have a number of machines (hardware and VMs) running CentOS 7.  I all
cases firewall-config is not functional.
>
> First, the service check boxes are not functional.  When you click on
one, it  don't change to "checked", and nothing changes on the firewall.
However you do see a "Changes applied"
>
> Sometimes, f you go to permanent mode and attempt to edit a zone, the
whole desktop locks up as soon as you click on the default target dropdown.
>
> When I run firewall-config from the command line I see the following:
>
> --
>
> org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.NetworkManager was not provided by any .service files
>
> (firewall-config:5079): Gtk-CRITICAL **: gtk_tree_view_get_path_at_pos:
assertion 'tree_view != NULL' failed
>
> --
> with the second line repeating many times and often while attempting to
interact with the GUI.
>
> We don't use NetworkManager except on laptops, and so do not install it.
Though we do install NetworkManager-glib, if only because some packages
require it.
>
> After seeing a similar bug on the RHEL I also installed
NetworkManager-libnm, but that did not make a difference.  That RHEL bug
also mentioned this problem only occurs on KDE, and not Gnome.  And we only
install KDE when a GUI is required, or desired.
>

I'd suggest you install and test with NetworkManager

Do note that the EL7 NM is a far cry from the one that shipped with EL6 and
unless you specifically need a facility not exposed by NM it is strongly
recommended you use it.

Take a look at my article on nmcli - it's rather lovely to use now:

https://www.hogarthuk.com/?q=node/8

As for the firewall tool... don't use it ... it's horrible

Either use firewall-cmd to configure at the CLI or switch to iptables and
configure that as you did EL6
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Fwd: Re: EPEL-ANNOUNCE Re: Upcoming OwnCloud changes in EPEL

[James Hogarth]

Please see the below if you are a CentOS user of the EPEL OwnCloud packages.

-- Forwarded message --
From: "James Hogarth" <james.hoga...@gmail.com>
Date: 3 Jun 2016 23:43
Subject: Re: EPEL-ANNOUNCE Re: Upcoming OwnCloud changes in EPEL
To: "EPEL Development List" <epel-de...@lists.fedoraproject.org>
Cc: <epel-annou...@lists.fedoraproject.org>

>
> On 22 Apr 2016 16:21, "James Hogarth" <james.hoga...@gmail.com> wrote:
> >
> >
> >
> > On 5 April 2016 at 09:22, James Hogarth <james.hoga...@gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> Following on the process of bringing OwnCloud up to date in Fedora
we're turning our attention to the EPEL users.
> >>
> >> Unfortunately EL6's use of php53 means we cannot update any further
there given the minimum requirement of php54.
> >>
> >> As such the maintenance update of 7.0.13 that is in epel-testing now
for EPEL6 will be the final one there to be followed by the retiring of the
package.
> >>
> >> If you wish to update from that please either migrate to an EL7 base
system or switch to the OwnCloud upstream packages which make use of SCL to
satisfy the php54+ requirement.
> >>
> >> On the EPEL7 side of things 8.1.6 is due to hit testing very shortly.
This is a mandatory update as a precursor to the 8.2.3 update in due
course. Once this reaches live please ensure that updates are carried out
and your OwnCloud installation is fully tested prior to the 8.2.3 update.
> >>
> >> This is due to a requirement from upstream that updates follow the
path 8.0 -> 8.1 -> 8.2 -> 9.0.
> >>
> >> Related to this when updating the EL6 install from the 7.0 version to
an EL7 or upstream SCL version please do make sure you follow the upgrade
chain correctly - it is not possible to skip a step.
> >>
> >> Once the 8.2 goal is reached a discussion will be had then for EPEL as
to whether to provide owncloud82 and owncloud90 packages or to just stay on
the current major update - but that discussion is some time away as of yet.
> >>
> >> The reason for picking owncloud82 as the possible base for this is
that this is the first version that has no php libraries bundled so will be
the easiest to provide the long term maintained base from in a clean
fashion complying to guidelines as closely as possible.
> >>
> >> Kind regards,
> >>
> >> James
> >>
> >>
> >
> > Following on from the previous message EPEL6 has it's final update with
the EOL message. Please arrange to move to the upstream SCL packages or to
migrate to EL7 if you are using owncloud on EPEL6 - be aware when you do
migrate off of this that it is important to follow the chain through
8.0->8.1->8.2 checking your installation at each step.
> >
> > EPEL7 has had some time in testing and received a positive test so the
8.1.6 update there is being pushed today.
> >
> > When that has gone stable an 8.2.3 update will be pushed to
epel-testing. Please ensure that your installation is updated to 8.1.6 and
fully tested before applying the 8.2.3 update.
> >
>
> OwnCloud 9.0.2 had been submitted to EPEL7 testing.
>
> Beyond the usual warning of ensuring your system is updated to 8.2 and
fully tested before applying the 9.0 update there is an additional caveat
for nginx users of OwnCloud.
>
> It became quickly apparent in testing recently that the nginx config
snippet shipped was broken out the box and couldn't possibly work.
>
> There is a new nginx snippet configuration being shipped as part of this
update so that nginx behaves like httpd for the path (ie it's under the
/owncloud namespace and not root) and so that an install of owncloud-nginx
will have working configuration without the need to craft an additional
custom config, removing the shipped one in the process.
>
> We have also moved the php-fpm configuration to its own pool to avoid any
conflicts of options.
>
> If using nginx for OwnCloud please carefully validate your config when
updating.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Fwd: EPEL-ANNOUNCE Re: Upcoming OwnCloud changes in EPEL

[James Hogarth]

On 22 May 2016 07:01, "John R Pierce"  wrote:
>
> On 5/21/2016 6:03 PM, John R Pierce wrote:
>>
>> i started to look at SCL and got lost pretty quickly.   I'm not running
OwnCloud but I've got some other php stuff thats getting increasingly
unhappy about the stock c6 php...
>
>
> ok, I've installed php54-1.1-5.el6.centos.alt.x86_64 ...if I run
`scl enable php54`, will that connect it up to my existing apache, so it
just works, or will that blow the heck out of everything on my host, or
something else?  I'm currently using php-5.3.3-46.el6_7.1.x86_64
>
>
>

Since this is becoming a recurring topic as EL6, and now EL7, begin to show
their age I did a write up on the options and how to use them today:

https://www.hogarthuk.com/?q=node/15
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] dnf replacing yum?

[James Hogarth]

On 26 May 2016 at 11:17, Johnny Hughes <joh...@centos.org> wrote:

> On 05/26/2016 04:31 AM, Yamaban wrote:
> > On Thu, 26 May 2016 08:00, James Hogarth wrote:
> >> On 26 May 2016 00:57, "SternData" wrote:
> >>> On 05/25/2016 06:43 PM, Always Learning wrote:
> >>>> On Wed, 2016-05-25 at 22:32 +0100, Timothy Murphy wrote:
> >>>>
> >>>>> Also, yum had associations which it was sad to lose.
> >>>>
> >>>> Perhaps the Fedora ("We love consulting all affected users")
> >>>> replacement
> >>>> could be named MUD.
> >>>>
> >>>> Now we await the System-D controlling interface ;-)
> >>>
> >>> There was much wailing and gnashing of teeth when these changes
> >>> rolled into Fedora.  After a while, I got used to it and now it seems
> >>> normal. Plus, if you type "yum update" it responds "what your really
> >>> should type is dnf update, but I'll do it for you anyway".
> >>
> >> There was a mail on the Fedora development list recently from one of the
> >> internal Red Hat RHEL yum guys.
> >>
> >> It implied that in RHEL the command would remain yum and not change to
> >> dnf,
> >> although the internals will no doubt do so at some point.
> >
> > Well, from what I've heard from some Red Hat RHEL Kernel guys, it will be
> > likely in RHEL 8.x as default with a yum compat cli, but unlikely to get
> > into RHEL 7.x as replacement for yum, and should stay confined to EPEL.
> > The reason given was: "(DNF is) not quite Enterprise ready, yet. Lets
> look
> > again during Fedora 25".
> >
>
> Based on previous RHEL history I would agree with Yamaban's take
> (probably in RHEL 8.x, likely not in RHEL 7).  But Red Hat has been a
> bit less conservative with making changes to RHEL 7 than they were the
> previous version of RHEL.
>
> Still, for them to make a change there would need to be some driving
> force for that change (IMHO).  For example, if there were new technology
> areas (containers, cloud) where dnf had major functionality advantages
> over yum, then they might consider a change.  Otherwise, I just don't
> see it.
>
> But, I have been wrong before .. a lot .. so take that with a grain of
> salt :)
>
>
>
To make it clear here is the specific link on the fedora-devel archives
discussing this:

https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/ALJVP7YTSEPC4HNH6JSFMFM6MCUP5HAT/

"Currently we're slated to keep yum as the primary name/command for package
management in RHEL. It may or may not be backed by dnf at some point; we're
still looking at the pros & cons and how to bring better compatibility if
we go down this path."

So my expectation is that RHEL8 will use dnf internally but the interface
will be called yum
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] dnf replacing yum?

[James Hogarth]

On 26 May 2016 00:57, "SternData"  wrote:
>
> On 05/25/2016 06:43 PM, Always Learning wrote:
> >
> > On Wed, 2016-05-25 at 22:32 +0100, Timothy Murphy wrote:
> >
> >> Also, yum had associations which it was sad to lose.
> >
> > Perhaps the Fedora ("We love consulting all affected users") replacement
> > could be named MUD.
> >
> > Now we await the System-D controlling interface ;-)
> >
> >
> >
> >
> There was much wailing and gnashing of teeth when these changes rolled
> into Fedora.  After a while, I got used to it and now it seems normal.
> Plus, if you type "yum update" it responds "what your really should type
> is dnf update, but I'll do it for you anyway".
>

There was a mail on the Fedora development list recently from one of the
internal Red Hat RHEL yum guys.

It implied that in RHEL the command would remain yum and not change to dnf,
although the internals will no doubt do so at some point.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] /etc/sysconfig/iptables syntax

[James Hogarth]

On 23 May 2016 21:03, "Mike" <1100...@gmail.com> wrote:
>
> The closest thing I could find to an iptables to firewalld conversion tool
> was Offline Configuation.
> The firewall-offline-cmd command was created to help setup firewall rules
> when Firewalld is not running.
>
> For instance, to open the tcp port 22, you would type in the
> /etc/sysconfig/iptables file:
>
> -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
>
> Instead, you can now execute the following command:
>
> # firewall-offline-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp
> -m state --state NEW -m tcp --dport 22 -j ACCEPT
>
> / / / / / / / / / / / / / / / / / / / / / / / / / //  /
>
> It's not that convenient for a rule-set of 250 lines, but with a
> little creative copying/pasting between the iptables rules and the
> "firewall-offline-cmd --direct -add-rule ipv4 filter"
> and "firewall-offline-cmd --direct -add-rule ipv4 nat " statements, I
> suppose a decent conversion can be completed.
>
> Of course, you'd still need to apply rules to the correct zones which
> I'm still trying to digest.
>
>

Using DIRECT bypasses all the zone and service stuff.

Frankly if your going to DIRECT everything then you really are better off
masking (and removing) firewalld and installing iptables-service and just
using the old traditional way.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upcoming OwnCloud changes

[James Hogarth]

On 23 May 2016 7:36 a.m., "Sorin Srbu"  wrote:
>
> > -Original Message-
> > From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On
> > Behalf Of Chuck Munro
> > Sent: den 22 maj 2016 17:11
> > To: centos@centos.org
> > Subject: Re: [CentOS] Upcoming OwnCloud changes
> >
> >
> > Just a FYI folks ...
> >
> > I am running OwnCloud 9.0.2 on CentOS 6.7 and php-7.0 with no issues.
> >
> > I installed the Webtatic repo which has several versions of PHP
> > available for CentOS 6 and 7.  I then used the official OwnCloud
> > ce:stable repo to add the cloud software.
> >
> > In a leap of faith, and because this CentOS VM doesn't run anything
> > other than OwnCloud, I used the 'php70w' PHP repo and have had no
> > problems at all.  The OwnCloud server is very lightly loaded so I have
> > not had an opportunity to stress test it and have not tried to use MySQL
> > (I configured it with the standard CentOS SQLite).
> >
> > YMMV of course, especially if you're running other PHP applications!
>
> Thanks for the info!
>
> I've been toying with the idea of stepping up to php7 as well, but haven't
> dared yet...
>
>

Note that Fedora has not made the change yet even.

Though I'm expecting that to happen in the F25 cycle.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Fwd: EPEL-ANNOUNCE Re: Upcoming OwnCloud changes in EPEL

[James Hogarth]

On 22 May 2016 07:01, "John R Pierce"  wrote:
>
> On 5/21/2016 6:03 PM, John R Pierce wrote:
>>
>> i started to look at SCL and got lost pretty quickly.   I'm not running
OwnCloud but I've got some other php stuff thats getting increasingly
unhappy about the stock c6 php...
>
>
> ok, I've installed php54-1.1-5.el6.centos.alt.x86_64 ...if I run
`scl enable php54`, will that connect it up to my existing apache, so it
just works, or will that blow the heck out of everything on my host, or
something else?  I'm currently using php-5.3.3-46.el6_7.1.x86_64
>

The scl enable stuff just affects the command passed. It has no system wide
level effect. This is why to get a terminal session with it in affect you
use scl enable php54 bash ... then that session will show php 5.4 when
running the php binary.

The documentation on how to actually use it for something like php in
Apache is terrible, and the general blogs on it are awful overall. Things
like doing source /opt/rh/foo/enable seem to be frequently mentioned
despite not being what the RH docs say.

There's also a lot of confusion between the CentOS SIG SCL stuff, the
official RHEL SCL stuff and the generic softwarecollections.org stuff.

As for mod_php from an SCL from my discussions with Remi on the topic he
prefers to use php-fpm in that situation rather than mod_php since that
then allows use of different php versions via passing that particular
application to a different pool and also allows you to move away from the
worker mpm and on top a more performant one since the thread safety issues
are then bypassed.

Do keep in mind that the repos only have the base php packages IIRC and
that still leaves the question of packages for all the other php libraries.
For something like upstream php that bundles everything is not a big deal,
but for other things it can be.

Personally I still prefer to use IUS in this use case due to the simpler
set up and larger repository of php libraries built against it.

Perhaps I'll dive into a blog post soon™ negotiating through this stuff
with decent examples of how to make use of the various methods, along with
their pros and cons. The question comes up frequently enough on #centos
that it'd be good to have a decent write up to refer to... and with a long
time till C6 EOL and RH relying heavily on SCL for PHP5.4+ (rather than
rebasing the php in the base distro) on it I'm sure it'll become an even
more common question than it already is.

Still none of the options (RH SCL, SIG SCL, SCL.org, IUS, RemiRepo) help us
EPEL since we can only depend on what's in base or EPEL for package
dependencies, and all efforts to get SCL approved in the Fedora Packaging
Guidelines have been rejected over the past few years.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Fwd: EPEL-ANNOUNCE Re: Upcoming OwnCloud changes in EPEL

[James Hogarth]

On 22 Apr 2016 18:11, "James Hogarth" <james.hoga...@gmail.com> wrote:
>
> In the event that there are CentOS users making use of the EPEL owncloud
packages, but not following the EPEL mailing lists, please read the mail
below with regards to your installations.
>
> Thanks
>
> James
>
> -- Forwarded message --
> From: "James Hogarth" <james.hoga...@gmail.com>
> Date: 22 Apr 2016 16:21
> Subject: EPEL-ANNOUNCE Re: Upcoming OwnCloud changes in EPEL
> To: "EPEL Development List" <epel-de...@lists.fedoraproject.org>
> Cc: <epel-annou...@lists.fedoraproject.org>
>
> >
> >
> > On 5 April 2016 at 09:22, James Hogarth <james.hoga...@gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> Following on the process of bringing OwnCloud up to date in Fedora
we're turning our attention to the EPEL users.
> >>
> >> Unfortunately EL6's use of php53 means we cannot update any further
there given the minimum requirement of php54.
> >>
> >> As such the maintenance update of 7.0.13 that is in epel-testing now
for EPEL6 will be the final one there to be followed by the retiring of the
package.
> >>
> >> If you wish to update from that please either migrate to an EL7 base
system or switch to the OwnCloud upstream packages which make use of SCL to
satisfy the php54+ requirement.
> >>
> >> On the EPEL7 side of things 8.1.6 is due to hit testing very shortly.
This is a mandatory update as a precursor to the 8.2.3 update in due
course. Once this reaches live please ensure that updates are carried out
and your OwnCloud installation is fully tested prior to the 8.2.3 update.
> >>
> >> This is due to a requirement from upstream that updates follow the
path 8.0 -> 8.1 -> 8.2 -> 9.0.
> >>
> >> Related to this when updating the EL6 install from the 7.0 version to
an EL7 or upstream SCL version please do make sure you follow the upgrade
chain correctly - it is not possible to skip a step.
> >>
> >> Once the 8.2 goal is reached a discussion will be had then for EPEL as
to whether to provide owncloud82 and owncloud90 packages or to just stay on
the current major update - but that discussion is some time away as of yet.
> >>
> >> The reason for picking owncloud82 as the possible base for this is
that this is the first version that has no php libraries bundled so will be
the easiest to provide the long term maintained base from in a clean
fashion complying to guidelines as closely as possible.
> >>
> >> Kind regards,
> >>
> >> James
> >>
> >>
> >
> > Following on from the previous message EPEL6 has it's final update with
the EOL message. Please arrange to move to the upstream SCL packages or to
migrate to EL7 if you are using owncloud on EPEL6 - be aware when you do
migrate off of this that it is important to follow the chain through
8.0->8.1->8.2 checking your installation at each step.
> >
> > EPEL7 has had some time in testing and received a positive test so the
8.1.6 update there is being pushed today.
> >
> > When that has gone stable an 8.2.3 update will be pushed to
epel-testing. Please ensure that your installation is updated to 8.1.6 and
fully tested before applying the 8.2.3 update.
> >

For any OwnCloud users on CentOS who utilise the EPEL packages please be
aware of important changes this week:

The EPEL6 package has now been retired as end of life. If using the EPEL6
packaging of OwnCloud please ensure you migrate to a supported version as
discussed above.

On the EPEL7 side of things 8.2.4 has just been submitted to stable. Please
ensure that the previous 8.1.6 update has been applied and fully tested
before carrying out the 8.2.4 update.

For those willing to do some early preliminary testing of 9.0.2 it has been
uploaded to my Fedora people space, along with its dependencies.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] one-shot yum command to match rpms between systems?

[James Hogarth]

On 18 May 2016 17:57, "Frank Cox" <thea...@melvilletheatre.com> wrote:
>
> On Wed, 18 May 2016 09:30:54 +0100
> James Hogarth wrote:
>
> > And of course as will be pointed out by many the only right answer is
yum
> > update anyway given cherry picking updates is not supported.
>
> The objective is not to cherry pick updates, but rather to install a
second system with packages that match the first system.  After fine-tuning
the installed packages and stripping out the unnecessary stuff, it would be
nice to just say "make that system look like this one" -- rsync for yum if
you will.  The specific package versions aren't important at that stage
since I can run yum update after the initial installation.
>

Well if you're planning on doing a yum update anyway just cat rpmlist |
xargs yum -y install

Better solution to this though is a basic ansible task list defining what
you need.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentosPlus

[James Hogarth]

On 17 May 2016 20:52, "Mauricio Tavares"  wrote:
>
> On Tue, May 17, 2016 at 3:04 PM,   wrote:
> > On 2016-05-17 12:09, jd1008 wrote:
> >> Has anybody enabled this repo?
> >> I understand that it can really mess up updates and upgrades
> >> as the dependencies are rather different.
> >
> > I've had the CentOSPlus repository enabled for CentOS6 for more
> > than a year with no problems. I don't recall reading anything on
> > this mailing list or IRC suggesting that enabling plus caused
> > issues with updates.
> >
> > The CentOS wiki warns "Enabling this repository makes CentOS
> > different from upstream. You should understand the implications
> > of this prior to enabling CentOSPlus". Essentially this is a
> > reminder that the CentOS community has no appetite for supporting
> > slightly non-standard configurations (a very reasonable stance).
> >
> > If you need the extra hardware driver modules available with
> > Plus this shouldn't stop you from running a Plus kernel.
> > Just be prepared to reproduce any problems using a stock
> > kernel (which you can still select at boot) if you need to
> > resolve an OS issue with help from others.
> >
> > The only vhanged packages in the CentOS Plus 6 repo are the
> > kernel (kernel, kernel-abi-whitelist, kernel-doc,
> > kernel-firmware, kernel-headers, kernel-devel), the kernel
> > performance utilities (perf, python-perf), and postfix.
> >
> > For detailed differences of the "Plus" kernel see:
> >
https://wiki.centos.org/AdditionalResources/Repositories/CentOSPlus?action=show=Repositories%2FCentOSPlus#head-a94637ae716c01023f633e8b5fb840f555f6d378
> >
>   Why not leave all the extra repos disabled, say
>
> sed -i -e 's/^enabled=1/enabled=0/' /etc/yum.repos.d/epel.repo
>
> and manually enable it when you need to get a package from said repo:
>
> yum install -y libmcrypt --enablerepo=epel
>

Doing this means you won't get notified of updates in that repo. This is
not a good idea.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] one-shot yum command to match rpms between systems?

[James Hogarth]

On 18 May 2016 07:55, "Frank Cox"  wrote:
>
> Given a list of rpms on one system (rpm -qa > list.txt), is there a
one-shot command that I can run on another system to remove all of the rpms
not listed and add any that are on the list and not present on the second
system?
>

If you had an internal repo of these packages you could yum distro-sync ...
otherwise there is no one shot command to do this given a list.

And of course as will be pointed out by many the only right answer is yum
update anyway given cherry picking updates is not supported.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd and VirtualBox

[James Hogarth]

On 17 May 2016 at 09:11, Rob Kampen  wrote:

> On 17/05/16 19:58, John Hodrien wrote:
>
>> On Tue, 17 May 2016, Rob Kampen wrote:
>>
>> No idea where to from here, so if there is anyone that has a working
>>> systemd autostart VirtualBox setup on a headless CentOS 7 server - please
>>> advise what you have done to get it working.
>>>
>>
>> I deliberately bailed on VirtualBox when we moved to C7, as KVM offered
>> everything I needed with less hassle.
>>
>> I take it you've considered switching?
>>
>> Considered, very briefly. I have had great success and stability with
> running VirtualBox on both CentOS 5 & 6 for the few Windoze apps that my
> clients need to run and have up on a server 24x7. The set ups I am using
> have been running reliably for over 8 years and remote manged with zero
> issues - HUGE thanks to the CentOS team for an awesome OS system delivery
> Thus, I have simply installed the latest VirtualBox on CentOS 7 and gone
> from there. I was aware that systemd existed and deliberately waited until
> this year to upgrade the hardware and OS, thinking issues like this should
> have been sorted by now.
> Are there any good tutorial / howtos for KVM? Although at this point I am
> back on another continent and reluctant to shift to KVM when over 20 hours
> fly time away from the server.
>
>
Why would that be an issue? It's not Xen where you have to boot into a
special kernel ... it's just the ordinary kernel. In fact I'd be surprised
if you had to reboot at all, you should just have to install the
virtualization group (along with virt-tools and virt-manager to make your
life easier, dont' forget to install fonts if using virt-manager over X
forward and wanting to avoid little boxes instead of characters) and be up
and running.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] ClamAV from EPEL

[James Hogarth]

On 15 May 2016 07:11, "Jon LaBadie"  wrote:
>
> On Sun, May 15, 2016 at 02:55:01AM +, Richard wrote:
> >
> > > Date: Saturday, May 14, 2016 16:20:41 -0700
> > > From: Alice Wonder 
> > >
> > > On 05/14/2016 01:22 PM, Walter H. wrote:
> > >> Hello,
> > >>
> > >> just curious;
> > >> since March 3rd, 2016 everdays logwatch-mail
> > >> shows this:
> > >>
> > >>   Last Status:
> > >>  WARNING: Your ClamAV installation is OUTDATED!
> > >>  WARNING: Local version: 0.99 Recommended version: 0.99.1
> > >>
> > >> do these warnings raise any problems?
> > >> could they be suppressed?
> > >>
> > > It's been awhile since I used ClamAV but when I did, I would
> > > rebuild the new version by modifying the src.rpm of the old version
> > > to the new version but using a 0 in the release tag so that it
> > > would be replaced by a repo maintained version as soon as it hit
> > > the repositories.
> > >
> >
> > It generally takes a week or so for an update to make it to epel.
> > They are still showing 0.99.1-1. You might want to check the
> > epel-testing repo in a couple of days.
> >
> > I think that that clamav warning message is a bit more dire sounding
> > than necessary.
> >
> Agreed.  As an observation, I don't update daily, but  more than
> once a week.  For the last two clamav updates, 0.98.7->0.99 and
> 0.99->0.99.1, the warnings lasted for 5 and 4 weeks.
>

Well it's not even been built for rawhide yet:

https://apps.fedoraproject.org/packages/clamav

I know nb has been pretty busy this week, letsencrypt rebranded to certbot
and we've been validating the package rename etc

Keep an eye on this bug for activity:

https://bugzilla.redhat.com/show_bug.cgi?id=1333949
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Openssl vulnerability

[James Hogarth]

On 12 May 2016 at 09:28,  wrote:

> Hi Team,
>
> I have a centos 7 running server with openssl version
> openssl-1.0.1e-51.el7_2.4.x86_64, I have received a set of vulnerability
> from security team, can anyone tell me as per below CVE do I need to update
> my openssl version to 1.0.1t? Or the current version which we have is safe.
>
> CVE-2016-0701, CVE-2015-3197
>
> CVE-2015-4000
>
> CVE-2015-0204
>
> CVE-2015-0286, CVE-2015-0287, CVE-2015-0289, CVE-2015-0293, CVE-2015-0209,
> CVE-2015-0288
>
> CVE-2015-0292, CVE-2014-8176
>
>
>
>
Send them this link about RHEL backports - 1.0.1t won't be in EL7.

https://access.redhat.com/security/updates/backporting

You can check the CVE database heer to see what RH has to say about an
issue and if it affects them:

https://access.redhat.com/security/security-updates/#/

Also don't underestimate the power of rpm -q --changelog  |
grep  ;)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Suggestions for Config Management Tool

[James Hogarth]

On 12 May 2016 at 08:22, Götz Reinicke - IT Koordinator <
goetz.reini...@filmakademie.de> wrote:

> Hi,
>
> we see a growing need for a better Configuration management for our
> servers.
>
> Are there any known good resources for a comparison of e.g. Puppet,
> Chef, Ansible etc?
>
> What would you suggest and why? :)
>
>
>

Puppet is great for central control with automatic runs making systems
right and keeping them in line, it's not an orchestration tool though -
however it's commonly supplemented with something like rundeck and/or
mcollective to assist here.

Chef is great for a ruby house - you'll need to brush up on your ruby as
writing cookbooks is heavily tied to the language. Historically it was very
debian focused with issues like selinux problems. I believe these have been
generally resolved though.

Ansible is a great orchestration tool and excellent for going from base to
a configured system. It is less of a tool to keep things inline with a base
however with no central automated runs (ignoring Tower which is not FOSS
yet).

Ansible is also much simpler to get into given the tasks are just like
following through a script for defining how to make a system, as opposed to
learning an actual DSL like required for understanding puppet modules.

There's a growing pattern of using ansible for orchestration alongside
puppet for definitions as well (there's a specific ansible module to carry
out a puppet run).

I've not looked at salt at all personally.

Came across this article a while back:
http://www.infoworld.com/article/2609482/data-center/data-center-review-puppet-vs-chef-vs-ansible-vs-salt.html
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] FirewallD and FTP passive mode

[James Hogarth]

On 5 May 2016 4:54 p.m., "Gordon Messmer"  wrote:
>
> On 05/05/2016 06:15 AM, Marcin Trendota wrote:
>>
>> Also this IP looks weird - shouldn't it be public IP?
>
>
>
> Yes, it should.  Are you using FTPS (FTP with TLS)?
>
> You probably need to set the pasv_address option.
>
>
>

Although of course FTPS (FTP over SSL) breaks the snooping required for the
related conntracking which makes firewall configuration hell.

Do yourself a favour and drop FTP, switching over to SFTP instead as that's
far easier to secure and you only have to care about the single TCP port
for firewalls.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] c6, drbd and file systems

[James Hogarth]

On 4 May 2016 09:11, "John R Pierce"  wrote:
>
> On 5/4/2016 12:41 AM, Patrick Begou wrote:
>>
>>
>> Any messages in /var/log/boot.log ?
>
>
> indeed, it appears it tries to mount local file systems BEFORE drbd is
started.  because /data isn't mounted, backuppc can't start either.
>
> so do I have to edit the chkconfig priorities in /etc/init.d and recreate
the rc3.d S** and K** scripts so drbd starts earlier?  ugh.
>
>
> # cat ore /var/log/boot.log
>Welcome to CentOS
> Starting udev: [  OK  ]
> Setting hostname hostname.mydomain.com: [  OK  ]
> Setting up Logical Volume Management:   5 logical volume(s) in volume
group "vg_sysdata" now active
>   3 logical volume(s) in volume group "vg_sys" now active
> [  OK  ]
> Checking filesystems
> /dev/mapper/vg_sys-lv_root: clean, 60004/3276800 files, 4432672/13107200
blocks
> /dev/sdb1: clean, 66/128016 files, 198283/512000 blocks
> /dev/mapper/vg_sys-lv_home: clean, 593694/129236992 files,
235674982/516925440 blocks
> [  OK  ]
> Remounting root filesystem in read-write mode: [  OK  ]
> Mounting local filesystems:  mount: special device /dev/drbd0 does not
exist
> [FAILED]
> Enabling local filesystem quotas: [  OK  ]
> Enabling /etc/fstab swaps: [  OK  ]
> Entering non-interactive startup
> Calling the system activity data collector (sadc)...
> Starting monitoring for VG vg_sys:   3 logical volume(s) in volume group
"vg_sys" monitored
> [  OK  ]
> Starting monitoring for VG vg_sysdata:   5 logical volume(s) in volume
group "vg_sysdata" monitored
> [  OK  ]
> Bringing up loopback interface: [  OK  ]
> Bringing up interface eth0:
> Determining IP information for eth0... done.
> [  OK  ]
> Starting auditd: [  OK  ]
> Starting system logger: [  OK  ]
> Enabling ondemand cpu frequency scaling: [  OK  ]
> Starting irqbalance: [  OK  ]
> Starting rpcbind: [  OK  ]
> Starting NFS statd: [  OK  ]
> Starting system message bus: [  OK  ]
> Starting Avahi daemon... [  OK  ]
> NFS filesystems queued to be mounted
> Mounting filesystems:  mount: special device /dev/drbd0 does not exist
> [FAILED]
> Starting acpi daemon: [  OK  ]
> Starting HAL daemon: [  OK  ]
> Starting lm_sensors: loading module ipmi-si adm1021 coretem[  OK  ]0
> Retrigger failed udev events [  OK  ]
>
>
>
> Rebuilding /boot/initrd-2.6.32-573.22.1.el6.x86_64kdump.img
> Warning: There might not be enough space to save a vmcore.
>  The size of UUID=2288bad6-ceb0-4984-bf3d-c5703495 should be
greater than 49416020 kilo bytes.
>
>
> Starting DRBD resources: [ d(main) s(main) n(main) ].
>
>
>
>
> Starting BackupPC: 2016-05-03 09:57:14 Can't create a test hardlink
between a file in /var/lib/BackupPC//pc and /var/lib/BackupPC//cpool.
Either these are different file system
> s, or this file system doesn't support hardlinks, or these directories
don't exist, or there is a permissions problem, or the file system is out
of inodes or full.  Use df, df -
> i, and ls -ld to check each of these possibilities. Quitting...
>
>

You might want to try adding _netdev to the options for /data ... Although
you're still likely to hit the race condition on EL6 ... This is much
simpler on EL7.

A custom init script to check the environment and only mount when ready (or
rc.local for initial testing) ... Set the options to noauto so you still
can have it listed in fstab to make life easier.

The alternative is to add the pacemaker framework and let the cluster stuff
handle it for you.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] C5: The Firefox ESR 45.1.0 Nighmare

[James Hogarth]

On 29 April 2016 at 09:55, isdtor  wrote:

> Always Learning writes:
> > However the time-wasting problem remains, so too do the down-loaded
> > extensions in /tmp, example tmp-xxx.xpi
>
> The reason behind this is the missing patch referenced by Johnny's posting
> that you referenced in a follow-up.
>
> What I would really like to see, talking about SIGs and such, is an rpm
> for palemoon, but I fear it can't be done on C5. Even C6 only would help,
> although I'm hesitating to move my main desktop off 5; the C6 desktop
> simply doesn't have the same stability and performance, and having to log
> off/log on just because PA behaves irratically is really annoying.
>


Given: RHEL5 goes end of life on 2017-03-31, which is 47 weeks, 6 days, 13
hours, 40 minutes, and 50 seconds from now

and that even now the updates are limited to critical (ie remote code
execution) pretty much might I suggest now is a good time to be thinking
about that future of that system and if not move to C7 at least move to C6?

I can't even imagine the pain of using C5 as a desktop in today's world ...
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Apache/PHP Installation - opinions

[James Hogarth]

On 26 Apr 2016 23:28, "Tim Dunphy"  wrote:
>
> Hey guys,
>
> I tend to work on small production environments for a large enterprise.
>
> Never more than 15 web servers for most sites.
>
> But most are only 3 to 5 web servers. Depends on the needs of the
> client.I actually like to install Apache and PHP from source and by
> hand. Although I know that's considered sacrilege in some shops.
>
> I do this because on RH flavored systems like CentOS the versions of
> Apache, php and most other software are a little behind the curve in
> terms of versions.
>
> And that's intentionally so! Because the versions that usually go into
> the various repos are tested and vetted thoroughly before going into
> the repos.
>
> I like to use the latest, stable versions of apache and php for my
> clients without having to create a custom RPM every time a new version
> comes out.
>
> So what I'd like to know is it better in your opinion to install from
> repos than to install by source as a best practice? Is it always
> better to use puppet, chef, ansible etc even if the environment is
> small? I'm sure this is a matter preference, but I would like to know
> what your preferences are.
>

Unless you are explicitly tracking upstream and religiously providing
builds as upstream release them taking upstream sources and building from
them is a disservice to your customers.

This goes doubly for just installing from source without making packages as
then it's impossible to audit the system for what is installed or properly
clean up after it.

You need to be aware that it's not only about "vetting" but rather that
auditing for a CVE becomes as simple as rpm -q --changelog | grep CVE ...
Security updates from RH don't alter functional behaviour reducing the need
for regression testing.

Unless you have a very specific requirement for a very bleeding edge
feature it's fundamentally a terrible idea to move away from the
distribution packages in something as exposed as a webserver ... And when
you do you absolutely need to have the mechanisms in place to efficiently
and swiftly build and deploy new versions, and deal with any fallout
yourself.

Finally keep in mind the CentOS project can only viably support what we
ship and not $random source. When you do need help and head to #centos on
irc or report something on the mailing list keep that in mind.

As for CM? Doesn't take any significant effort or time to knock together a
playbook to cover what you did by hand. Doesn't need to be high quality and
distro agnostic ready for galaxy (or forge or whatever chef does) but it
does mean you have "documentation in code" of how that system is without
having to maintain info on how to rebuild it anyway. And assume every
system may need a rebuild at some point - having CM in place makes that
trivial rather than "oh what was the special thing on this one" scenarios.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Fwd: EPEL-ANNOUNCE Re: Upcoming OwnCloud changes in EPEL

[James Hogarth]

In the event that there are CentOS users making use of the EPEL owncloud
packages, but not following the EPEL mailing lists, please read the mail
below with regards to your installations.

Thanks

James

-- Forwarded message --
From: "James Hogarth" <james.hoga...@gmail.com>
Date: 22 Apr 2016 16:21
Subject: EPEL-ANNOUNCE Re: Upcoming OwnCloud changes in EPEL
To: "EPEL Development List" <epel-de...@lists.fedoraproject.org>
Cc: <epel-annou...@lists.fedoraproject.org>

>
>
> On 5 April 2016 at 09:22, James Hogarth <james.hoga...@gmail.com> wrote:
>>
>> Hi all,
>>
>> Following on the process of bringing OwnCloud up to date in Fedora we're
turning our attention to the EPEL users.
>>
>> Unfortunately EL6's use of php53 means we cannot update any further
there given the minimum requirement of php54.
>>
>> As such the maintenance update of 7.0.13 that is in epel-testing now for
EPEL6 will be the final one there to be followed by the retiring of the
package.
>>
>> If you wish to update from that please either migrate to an EL7 base
system or switch to the OwnCloud upstream packages which make use of SCL to
satisfy the php54+ requirement.
>>
>> On the EPEL7 side of things 8.1.6 is due to hit testing very shortly.
This is a mandatory update as a precursor to the 8.2.3 update in due
course. Once this reaches live please ensure that updates are carried out
and your OwnCloud installation is fully tested prior to the 8.2.3 update.
>>
>> This is due to a requirement from upstream that updates follow the path
8.0 -> 8.1 -> 8.2 -> 9.0.
>>
>> Related to this when updating the EL6 install from the 7.0 version to an
EL7 or upstream SCL version please do make sure you follow the upgrade
chain correctly - it is not possible to skip a step.
>>
>> Once the 8.2 goal is reached a discussion will be had then for EPEL as
to whether to provide owncloud82 and owncloud90 packages or to just stay on
the current major update - but that discussion is some time away as of yet.
>>
>> The reason for picking owncloud82 as the possible base for this is that
this is the first version that has no php libraries bundled so will be the
easiest to provide the long term maintained base from in a clean fashion
complying to guidelines as closely as possible.
>>
>> Kind regards,
>>
>> James
>>
>>
>
> Following on from the previous message EPEL6 has it's final update with
the EOL message. Please arrange to move to the upstream SCL packages or to
migrate to EL7 if you are using owncloud on EPEL6 - be aware when you do
migrate off of this that it is important to follow the chain through
8.0->8.1->8.2 checking your installation at each step.
>
> EPEL7 has had some time in testing and received a positive test so the
8.1.6 update there is being pushed today.
>
> When that has gone stable an 8.2.3 update will be pushed to epel-testing.
Please ensure that your installation is updated to 8.1.6 and fully tested
before applying the 8.2.3 update.
>
> Kind regards,
>
> James
>
>
>
> ___
> epel-announce mailing list
> epel-annou...@lists.fedoraproject.org
>
http://lists.fedoraproject.org/admin/lists/epel-annou...@lists.fedoraproject.org
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What's the difference between nmcli fields ipv4.addresses and IP4.ADDRESS?

[James Hogarth]

On 15 April 2016 at 14:37, Joe Smithian  wrote:

> Hi All,
>
> nmcli tool in CentOS 7.1 uses same fields with upper and lower case with
> different meanings. What's the difference between pv4.addresses and
> IP4.ADDRESS in "nmcli con show" command?
>
> Where nmcli fields are documented? I searched online but didn't find nmcli
> documentation. RHEL 7 Networking Guide doesn't explain nmcli options in
> details.
>
>
Take a look at man nm-settings
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] selinux getsebool request

[James Hogarth]

On 13 April 2016 at 09:50, John Hodrien <j.h.hodr...@leeds.ac.uk> wrote:

> On Tue, 12 Apr 2016, John Jasen wrote:
>
> On 04/12/2016 02:31 PM, James Hogarth wrote:
>>
>>> For example:
>>>
>>> unless => "/usr/sbin/getsebool httpd_can_network_connect | /usr/bin/grep
>>> on
>>> &> /dev/null"
>>>
>>
>> D'oh! That's what I get for overcomplicating the whole darn thing. :)
>>
>>>
>>> Incidentally one nice trick if you're dealing with potentially changing
>>> multiple booleans and the policy compile time is to either skip -P and
>>> understand it's not persistent so puppet needs to fix at boot, or passing
>>> multiple booleans to setsebool at the same time so the compile only
>>> happens
>>> once.
>>>
>>
>> Huh. Stacking setsebool has a lot of potential. I should add remedial
>> man-page reading to my list of tasks.
>>
>> I'm of the camp that systems should come up in a ready state, regardless
>> of the immediate availability of puppet. So, using puppet to push
>> SELinux changes without committing to on-disk policy alarms me.
>>
>
> I'm not sure I entirely understand this discussion.  Isn't this what puppet
> does by default with selboolean?
>
> # puppet resource selboolean httpd_can_network_connect value=on
> persistent=true --debug
> Debug: Runtime environment: puppet_version=3.8.6, ruby_version=2.0.0,
> run_mode=user, default_encoding=UTF-8
> Debug: Loaded state in 0.15 seconds
> Debug: Selboolean[httpd_can_network_connect](provider=getsetsebool):
> Retrieving value of selboolean httpd_can_network_connect
> Debug: Executing '/usr/sbin/getsebool httpd_can_network_connect'
> Debug: Selboolean[httpd_can_network_connect](provider=getsetsebool):
> Enabling persistence
> Debug: Executing '/usr/sbin/setsebool -P httpd_can_network_connect on'
> Notice: /Selboolean[httpd_can_network_connect]/value: value changed 'off'
> to 'on'
> Debug: Finishing transaction 19351060
> Debug: Storing state
> Debug: Stored state in 0.20 seconds
> Debug: Selboolean[httpd_can_network_connect](provider=getsetsebool):
> Retrieving value of selboolean httpd_can_network_connect
> Debug: Executing '/usr/sbin/getsebool httpd_can_network_connect'
> selboolean { 'httpd_can_network_connect':
>   value => 'on',
> }
>
> Here you see it checking the value, deciding it's wrong, then setting it.
>
> # puppet resource selboolean httpd_can_network_connect value=on
> persistent=true --debug
> Debug: Runtime environment: puppet_version=3.8.6, ruby_version=2.0.0,
> run_mode=user, default_encoding=UTF-8
> Debug: Loaded state in 0.15 seconds
> Debug: Selboolean[httpd_can_network_connect](provider=getsetsebool):
> Retrieving value of selboolean httpd_can_network_connect
> Debug: Executing '/usr/sbin/getsebool httpd_can_network_connect'
> Debug: Finishing transaction 18309580
> Debug: Storing state
> Debug: Stored state in 0.18 seconds
> Debug: Selboolean[httpd_can_network_connect](provider=getsetsebool):
> Retrieving value of selboolean httpd_can_network_connect
> Debug: Executing '/usr/sbin/getsebool httpd_can_network_connect'
> selboolean { 'httpd_can_network_connect':
>   value => 'on',
> }
>
> Here it checks it, then leaves it alone as it's correct.
>
> What am I missing?
>
>
>
Nothing haha ... been awhile since I used puppet now (and last job where I
did had a policy of not enforcing selinux anyway)  ...

You are indeed correct that resource type is the better way to handle this
- totally forgot it existed.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos