Re: [CentOS] firewalld being stupid

[Marcelo Ricardo Leitner]

Em 17-11-2015 01:26, Dennis Jacobfeuerborn escreveu:

On 16.11.2015 22:58, Gordon Messmer wrote:

On 11/16/2015 01:39 PM, Nick Bright wrote:

This is very frustrating, and not obvious. If --permanent doesn't work
for a command, then it should give an error - not silently fail
without doing anything!


But --permanent *did* work.

What you're seeing is the documented behavior:
--permanent
The permanent option --permanent can be used to set options
permanently. These changes are not effective immediately, only
after service restart/reload or system reboot. Without the
--permanent option, a change will only be part of the runtime
configuration.

If you want to make a change in runtime and permanent
configuration, use the same call with and without the
--permanent
option.


That's fairly annoying behavior as it creates the potential for
accidentally diverging configurations.
Why not do the same as virsh an have two options for this? When I attach
a device I can specify --config to update the persistent configuration,
--live to update the runtime configuration and both if I want to change
both. That's a much better API in my opinion.


It's the same thing but with different names and a default, --config.
And I agree, it would be nice to be able to issue both options at once.
Would you open a BZ asking for this or should I?

  Marcelo

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

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

[centos-announce-request]

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

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

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

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


Today's Topics:

   1. CESA-2015:2065 Important CentOS 5 xen SecurityUpdate
  (Johnny Hughes)


--

Message: 1
Date: Mon, 16 Nov 2015 20:32:24 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2015:2065 Important CentOS 5 xen
SecurityUpdate
Message-ID: <20151116203224.ga10...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2015:2065 Important

Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-2065.html

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

i386:
388ec1332b1e2f675f67fdb8ad56c28811128e3c9e7f0093fd67b7180e12bf70  
xen-3.0.3-147.el5_11.i386.rpm
3c8e64bff83246ab9f8e361c248f4e473096ad5d0213631738082ed9c6db5d4d  
xen-3.0.3-147.el5_11.i686.rpm
b563a6f98a3c39f0a28ef6057e175c6d940e9c16f808877006803b6a6f1f83ca  
xen-devel-3.0.3-147.el5_11.i386.rpm
6ea1d0d1d4d9a76c7e9ab5c057a265fa162fec047d164ac818341e216dffa97c  
xen-devel-3.0.3-147.el5_11.i686.rpm
2469d3e25e7fe7135c69bcd43699b4ff5ea6e912ba1de5918c4041ec5b8ce223  
xen-libs-3.0.3-147.el5_11.i386.rpm
b3ee5a22722b9eca0d758746f85208abf66e05dcc30cbc38b20be3a12d8cbe8e  
xen-libs-3.0.3-147.el5_11.i686.rpm

x86_64:
489c2f01bb31c69c37aea0ce5a681e4a9a979c453ba87671040f882307afb7f0  
xen-3.0.3-147.el5_11.x86_64.rpm
b563a6f98a3c39f0a28ef6057e175c6d940e9c16f808877006803b6a6f1f83ca  
xen-devel-3.0.3-147.el5_11.i386.rpm
b71e966fd955b269897933773580ea8d37ba385a63545b323dd308b4063413b9  
xen-devel-3.0.3-147.el5_11.x86_64.rpm
2469d3e25e7fe7135c69bcd43699b4ff5ea6e912ba1de5918c4041ec5b8ce223  
xen-libs-3.0.3-147.el5_11.i386.rpm
c111fe7960da5cbc37c8f0f4804f2b762aadde878099f72c38b4e04ab689995f  
xen-libs-3.0.3-147.el5_11.x86_64.rpm

Source:
0e2ed9159d7d8a815c5483da3a802da4e05d229302f4446a6d5ce1915a22b669  
xen-3.0.3-147.el5_11.src.rpm



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



--

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


End of CentOS-announce Digest, Vol 129, Issue 8
***
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Problems with CentOS Advisory from August 2014

[Ian Stirling]

Regarding this announcement

[CentOS-announce] CESA-2014:1008 Important CentOS 6 samba Security  Update

*Johnny Hughes*  
johnny at centos.org 



/Tue Aug 5 20:09:29 UTC 2014/

Talks about this upstream Redhat problem -

https://rhn.redhat.com/errata/RHSA-2014-1008.html

When you read that errata it talks about RHEL 7 and in fact the filesets 
mentioned in the
CentOS announcement are for CentOS 7 which leaves us in a state of a CentOS 6 
system trying
to install CentOS 7 filesets (some examples)

x86_64:
157af858bf13ec971678a8bf3fc6cb649d577e671edadf3c860723a87c736eab  
libsmbclient-4.1.1-37.*el7*_0.i686.rpm
90ea2064837184635e7d718b854ced1482b78514c35b26a75125242b342316c8  
libsmbclient-4.1.1-37.*el7*_0.x86_64.rpm
8a02b8e75489ae6972d2dce9cdc641c303903e772913421ad5a0d18ba9b84ecc  
libsmbclient-devel-4.1.1-37.el7_0.i686.rpm
7fd666c9b7e9fcae08cfe87a1061de6f6bc70c1fe6f9e3b276e08281faaa74db  
libsmbclient-devel-4.1.1-37.el7_0.x86_64.rpm
6d227ef56d9c743db3ef6ca280232c92a7eac8b7ce831dd97d15eb34b4e456fc  
libwbclient-4.1.1-37.el7_0.i686.rpm
3b1c4905362c5bded2e3a6b700447adfa16c557a1bed8be96595598ff55f82a1  
libwbclient-4.1.1-37.el7_0.x86_64.rpm

--
Regards

Ian

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

Re: [CentOS] firewalld being stupid

[Dennis Jacobfeuerborn]

On 17.11.2015 15:18, James B. Byrne wrote:
> 
> On Mon, November 16, 2015 16:39, Nick Bright wrote:
>> On 11/6/2015 3:58 PM, James Hogarth wrote:
>>> I have a couple of relevant articles you may be interested in ...
>>>
>>> On assigning the zone via NM:
>>> https://www.hogarthuk.com/?q=node/8
>>>
>>> Look down to the "Specifying a particular firewall zone" bit ...
>>> remember that if you edit the files rather than using nmcli you must
>>> reload NM (or do nmcli reload) for that to take effect.
>>>
>>> If you specify a zone in NM then this will override the firewalld
>>> configuration if the zone is specified there.
>>>
>>> Here's some firewalld stuff:
>>> https://www.hogarthuk.com/?q=node/9
>>>
>>> Don't forget that if you use --permanent on a command you need to do
>>> a
>>> reload for it to read the config from disk and apply it.
>> Thanks for the articles, they're informative.
>>
>> Here's what's really irritating me though.
>>
>> firewall-cmd --zone=internal --change-interface=ens224 --permanent
>>
>> ^^ This command results in NO ACTION TAKEN. The zone IS NOT CHANGED.
>>
>> firewall-cmd --zone=internal --change-interface=ens224
>>
>> This command results in the zone of ens224 being changed to internal,
>> as
>> desired. Of course, this is not permanent.
>>
>> As such, firewall-cmd --reload (or a reboot, ect) will revert to the
>> public zone. To save the change, one must execute firewall-cmd
>> --runtime-to-permanent.
>>
>> This is very frustrating, and not obvious. If --permanent doesn't work
>> for a command, then it should give an error - not silently fail
>> without doing anything!
>>
> 
> This behaviour is congruent with SELinux. One utility adjusts the
> permanent configuration, the one that will be applied at startup.
> Another changes the current running environment without altering the
> startup config.  From a sysadmin point of view this is desirable since
> changes to a running system are often performed for empirical testing.
> Leaving ephemeral state changes permanently fixed in the startup
> config could, and almost certainly would eventually, lead to serious
> problem during a reboot.
> 
> Likewise, immediately introducing a state change to a running system
> when reconfiguring system startup options is just begging for an
> operations incident report.
> 
> It may not be intuitive to some but it is certainly the logical way of
> handling this.
> 

The better way is to explicitly allow the user to dump the runtime
configuration as the persistent configuration though as that makes it
much more difficult to have subtly diverging configurations due to user
errors. On network switches you often find something like "copy
running-congig startup-config".

Regards,
  Dennis

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

Re: [CentOS] CentOS-SCL python version

[Karanbir Singh]

On 16/11/15 18:26, Noam Bernstein wrote:
> Hi - I’d like to use the CentOS-SCL python27 packages, but those appear to be 
> rather out of date, still on 2.7.5.  Is there any chance that there will be 
> an update in the 2.7 track, to 2.7.10?
> 
>   thanks,

There are a few SCL's ready for release - you should see them come
through in the coming week. This includes : py27 / py33 and py34; for
py27 this would be to 2.7.8


-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS-SCL python version

[Noam Bernstein]

> On Nov 17, 2015, at 10:19 AM, Karanbir Singh  wrote:
> 
> On 16/11/15 18:26, Noam Bernstein wrote:
>> Hi - I’d like to use the CentOS-SCL python27 packages, but those appear to 
>> be rather out of date, still on 2.7.5.  Is there any chance that there will 
>> be an update in the 2.7 track, to 2.7.10?
>> 
>>  thanks,
> 
> There are a few SCL's ready for release - you should see them come
> through in the coming week. This includes : py27 / py33 and py34; for
> py27 this would be to 2.7.8

Thanks.  Any particular reason it’s 2.7.8 and not 2.7.10?

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

Re: [CentOS] firewalld being stupid

[James B. Byrne]

On Mon, November 16, 2015 16:39, Nick Bright wrote:
> On 11/6/2015 3:58 PM, James Hogarth wrote:
>> I have a couple of relevant articles you may be interested in ...
>>
>> On assigning the zone via NM:
>> https://www.hogarthuk.com/?q=node/8
>>
>> Look down to the "Specifying a particular firewall zone" bit ...
>> remember that if you edit the files rather than using nmcli you must
>> reload NM (or do nmcli reload) for that to take effect.
>>
>> If you specify a zone in NM then this will override the firewalld
>> configuration if the zone is specified there.
>>
>> Here's some firewalld stuff:
>> https://www.hogarthuk.com/?q=node/9
>>
>> Don't forget that if you use --permanent on a command you need to do
>> a
>> reload for it to read the config from disk and apply it.
> Thanks for the articles, they're informative.
>
> Here's what's really irritating me though.
>
> firewall-cmd --zone=internal --change-interface=ens224 --permanent
>
> ^^ This command results in NO ACTION TAKEN. The zone IS NOT CHANGED.
>
> firewall-cmd --zone=internal --change-interface=ens224
>
> This command results in the zone of ens224 being changed to internal,
> as
> desired. Of course, this is not permanent.
>
> As such, firewall-cmd --reload (or a reboot, ect) will revert to the
> public zone. To save the change, one must execute firewall-cmd
> --runtime-to-permanent.
>
> This is very frustrating, and not obvious. If --permanent doesn't work
> for a command, then it should give an error - not silently fail
> without doing anything!
>

This behaviour is congruent with SELinux. One utility adjusts the
permanent configuration, the one that will be applied at startup.
Another changes the current running environment without altering the
startup config.  From a sysadmin point of view this is desirable since
changes to a running system are often performed for empirical testing.
Leaving ephemeral state changes permanently fixed in the startup
config could, and almost certainly would eventually, lead to serious
problem during a reboot.

Likewise, immediately introducing a state change to a running system
when reconfiguring system startup options is just begging for an
operations incident report.

It may not be intuitive to some but it is certainly the logical way of
handling this.

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

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

Re: [CentOS] firewalld being stupid

[Jonathan Billings]

On Tue, Nov 17, 2015 at 09:18:22AM -0500, James B. Byrne wrote:
> This behaviour is congruent with SELinux. One utility adjusts the
> permanent configuration, the one that will be applied at startup.
> Another changes the current running environment without altering the
> startup config.  From a sysadmin point of view this is desirable since
> changes to a running system are often performed for empirical testing.
> Leaving ephemeral state changes permanently fixed in the startup
> config could, and almost certainly would eventually, lead to serious
> problem during a reboot.
> 
> Likewise, immediately introducing a state change to a running system
> when reconfiguring system startup options is just begging for an
> operations incident report.

Another possible reason is because when you're setting up firewalld,
you might want to batch a bunch of changes with --permanent, then,
once you've added them all, *then* you restart firewalld to pick up
the changes.  Having the firewall restart after *every* permanent
change you want to make would leave the system's firewall bouncing up
and down.

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

Re: [CentOS] firewalld being stupid

[Mike]

On Nov 17, 2015 12:11 PM,  wrote:

> tell me progress, and final result. You'd think they were an old New
> Englander.
>
>  mark, ayu'
_

Totally hilarious. Thanks for making my day.

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

Re: [CentOS] firewalld being stupid

[Nick Bright]

On 11/16/2015 3:58 PM, Gordon Messmer wrote:

On 11/16/2015 01:39 PM, Nick Bright wrote:
This is very frustrating, and not obvious. If --permanent doesn't 
work for a command, then it should give an error - not silently fail 
without doing anything! 


But --permanent *did* work.

No, it didn't. Not for changing the zone.

After using --permanent, and restarting the firewall, _the zone was not 
changed_. I've duplicated this behavior on a half dozen installs now.


--
---
-  Nick Bright-
-  Vice President of Technology   -
-  Valnet -=- We Connect You -=-  -
-  Tel 888-332-1616 x 315 / Fax 620-331-0789  -
-  Web http://www.valnet.net/ -
---
- Are your files safe?-
- Valnet Vault - Secure Cloud Backup  -
- More information & 30 day free trial at -
- http://www.valnet.net/services/valnet-vault -
---

This email message and any attachments are intended solely for the use of the 
addressees hereof. This message and any attachments may contain information 
that is confidential, privileged and exempt from disclosure under applicable 
law. If you are not the intended recipient of this message, you are prohibited 
from reading, disclosing, reproducing, distributing, disseminating or otherwise 
using this transmission. If you have received this message in error, please 
promptly notify the sender by reply E-mail and immediately delete this message 
from your system.

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

[CentOS] firewalld rule syntax

[Nick Bright]

I'm still learning firewalld obviously, and I am having trouble groking 
the documentation to understand how to do this.


I know I could do an iptables direct, but that doesn't seem like the 
"right" way to do it.


What I'm trying to do is allow a specific service, only for a specific ip.

Effectively, SNMP should be allowed form a specific IP address (the 
systems monitor). What would be the most correct way of doing this?


Create a zone for the snmp, then add the associated interface to that zone?

firewall-cmd --zone=monitoring --add-source=1.2.3.4/32
firewall-cmd --zone=monitoring --add-service=snmp
firewall-cmd --zone=monitoring --add-interface=ens192
firewall-cmd --runtime-to-permanent

Would this be an appropriate approach? Is it the 'most correct' way?

--
---
-  Nick Bright-
-  Vice President of Technology   -
-  Valnet -=- We Connect You -=-  -
-  Tel 888-332-1616 x 315 / Fax 620-331-0789  -
-  Web http://www.valnet.net/ -
---
- Are your files safe?-
- Valnet Vault - Secure Cloud Backup  -
- More information & 30 day free trial at -
- http://www.valnet.net/services/valnet-vault -
---

This email message and any attachments are intended solely for the use of the 
addressees hereof. This message and any attachments may contain information 
that is confidential, privileged and exempt from disclosure under applicable 
law. If you are not the intended recipient of this message, you are prohibited 
from reading, disclosing, reproducing, distributing, disseminating or otherwise 
using this transmission. If you have received this message in error, please 
promptly notify the sender by reply E-mail and immediately delete this message 
from your system.

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

Re: [CentOS] firewalld being stupid

[Dennis Jacobfeuerborn]

On 17.11.2015 17:51, m.r...@5-cent.us wrote:
> Nick Bright wrote:
>> On 11/17/2015 8:18 AM, James B. Byrne wrote:
>>> This behaviour is congruent with SELinux. One utility adjusts the
>>> permanent configuration, the one that will be applied at startup.
>>> Another changes the current running environment without altering the
>>> startup config. From a sysadmin point of view this is desirable since
>>> changes to a running system are often performed for empirical testing.
>>> Leaving ephemeral state changes permanently fixed in the startup
>>> config could, and almost certainly would eventually, lead to serious
>>> problem during a reboot. Likewise, immediately introducing a state
>>> change to a running system when reconfiguring system startup options
>>> is just begging for an operations incident report. It may not be
>>> intuitive to some but it is certainly the logical way of handling this.
>>
>> I certainly don't disagree with this behavior.
>>
>> What I disagree with is documented commands _*not working and failing
>> silently*_.
>>
> I agree, and it seems to be the way systemd works, as a theme, as it were.
> I restart a service... and it tells me *nothing* at all. I have to run a
> second command, to ask the status. I've no idea why it's "bad form" to
> tell me progress, and final result. You'd think they were an old New
> Englander.

Systemd has better mechanisms to report feedback compared to SysV
scripts but if the creators of the service files and the daemons don't
make use of these that's hardly systemd's fault. The best way is to use
"Type=notify" which allows a daemon to actually report to systemd when
it is done initializing. If the daemon doesn't support this then you can
still use ExecStartPost to specify a command that verifies that the
daemon indeed did start up correctly (and no the binary returning a code
of 0 does not mean the service is actually up-and-running properly).

Regards,
  Dennis

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

Re: [CentOS] firewalld being stupid

[Nick Bright]

On 11/17/2015 8:18 AM, James B. Byrne wrote:
This behaviour is congruent with SELinux. One utility adjusts the 
permanent configuration, the one that will be applied at startup. 
Another changes the current running environment without altering the 
startup config. From a sysadmin point of view this is desirable since 
changes to a running system are often performed for empirical testing. 
Leaving ephemeral state changes permanently fixed in the startup 
config could, and almost certainly would eventually, lead to serious 
problem during a reboot. Likewise, immediately introducing a state 
change to a running system when reconfiguring system startup options 
is just begging for an operations incident report. It may not be 
intuitive to some but it is certainly the logical way of handling this. 


I certainly don't disagree with this behavior.

What I disagree with is documented commands _*not working and failing 
silently*_.


--
---
-  Nick Bright-
-  Vice President of Technology   -
-  Valnet -=- We Connect You -=-  -
-  Tel 888-332-1616 x 315 / Fax 620-331-0789  -
-  Web http://www.valnet.net/ -
---
- Are your files safe?-
- Valnet Vault - Secure Cloud Backup  -
- More information & 30 day free trial at -
- http://www.valnet.net/services/valnet-vault -
---

This email message and any attachments are intended solely for the use of the 
addressees hereof. This message and any attachments may contain information 
that is confidential, privileged and exempt from disclosure under applicable 
law. If you are not the intended recipient of this message, you are prohibited 
from reading, disclosing, reproducing, distributing, disseminating or otherwise 
using this transmission. If you have received this message in error, please 
promptly notify the sender by reply E-mail and immediately delete this message 
from your system.

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

Re: [CentOS] firewalld being stupid

[m . roth]

Nick Bright wrote:
> On 11/17/2015 8:18 AM, James B. Byrne wrote:
>> This behaviour is congruent with SELinux. One utility adjusts the
>> permanent configuration, the one that will be applied at startup.
>> Another changes the current running environment without altering the
>> startup config. From a sysadmin point of view this is desirable since
>> changes to a running system are often performed for empirical testing.
>> Leaving ephemeral state changes permanently fixed in the startup
>> config could, and almost certainly would eventually, lead to serious
>> problem during a reboot. Likewise, immediately introducing a state
>> change to a running system when reconfiguring system startup options
>> is just begging for an operations incident report. It may not be
>> intuitive to some but it is certainly the logical way of handling this.
>
> I certainly don't disagree with this behavior.
>
> What I disagree with is documented commands _*not working and failing
> silently*_.
>
I agree, and it seems to be the way systemd works, as a theme, as it were.
I restart a service... and it tells me *nothing* at all. I have to run a
second command, to ask the status. I've no idea why it's "bad form" to
tell me progress, and final result. You'd think they were an old New
Englander.

 mark, ayu'

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

Re: [CentOS] firewalld rule syntax

[Nick Bright]

On 11/17/2015 11:12 AM, Nick Bright wrote:

firewall-cmd --zone=monitoring --add-source=1.2.3.4/32
firewall-cmd --zone=monitoring --add-service=snmp
firewall-cmd --zone=monitoring --add-interface=ens192
firewall-cmd --runtime-to-permanent
I went ahead and tried this and found that the zone and service must 
first be created, which requires use of:


firewall-cmd --new-zone=monitoring --permanent (--permanent is required)
firewall-cmd --new-service=snmp

edit /etc/firewalld/services/snmp.xml:


snmp
Simple Network Management Protocol



firewall-cmd --reload

However, at the end
firewall-cmd --zone=monitoring --add-interface=ens192

This results in a zone conflict. I'm not sure if it's even possible to 
have two zones on the interface.


--
---
-  Nick Bright-
-  Vice President of Technology   -
-  Valnet -=- We Connect You -=-  -
-  Tel 888-332-1616 x 315 / Fax 620-331-0789  -
-  Web http://www.valnet.net/ -
---
- Are your files safe?-
- Valnet Vault - Secure Cloud Backup  -
- More information & 30 day free trial at -
- http://www.valnet.net/services/valnet-vault -
---

This email message and any attachments are intended solely for the use of the 
addressees hereof. This message and any attachments may contain information 
that is confidential, privileged and exempt from disclosure under applicable 
law. If you are not the intended recipient of this message, you are prohibited 
from reading, disclosing, reproducing, distributing, disseminating or otherwise 
using this transmission. If you have received this message in error, please 
promptly notify the sender by reply E-mail and immediately delete this message 
from your system.

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

[CentOS] centos 7 and keychain

[Pete Stieber]

Is there a centos recommended repository for centos 7 where I can obtain 
the keychain package?


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

[CentOS] Running Fedora under CentOS via systemd-nspawn?

[Matt Garman]

tl;dr - Is anybody "running" a Fedora system via systemd-nspawn under CentOS?

Long version:

Before CentOS 7, I used chroot to create "lightweight containers"
where I could cleanly add extra repos and/or software without the risk
of "polluting" my main system (and potentially ending up in dependency
hell).  The primary driver for this was MythTV, which has dozens of
deps that span multiple repos.  Without "containing" the MythTV
installation within a chroot environment, I would inevitably lead to
conflicts when doing a yum update.

When I upgraded to CentOS 7, I found out that systemd-nspawn is
"chroot on steroids".  After figuring it all out, I replicated my
MythTV "container", and things were great.

Now I have a need for a particular piece of software: HandBrake.  I
found this site[1] that packages it for both Fedora and CentOS.  But
the CentOS version is a little older, as the latest HandBrake requires
gtk3.  The latest version is available for Fedora however.

So I thought, what if I could "run" Fedora under systemd-nspawn.
Well, I definitely *can* do it.  I copied the base Fedora filesystem
layout off the Live CD, then booted into it via systemd-nspawn.  I was
able to add repos (including the one for HandBrake), and actually
install then run the HandBrake GUI.

So while this does work, I'm wondering if it's safe?  I'm thinking
that at least some of the Fedora tools assume that they are running
under a proper Fedora kernel, whereas in my scheme, they are running
under a CentOS kernel.  I'm sure there have been changes to the kernel
API between the CentOS kernel and the Fedora kernel.  Am I risking
system stability by doing this?

Anyone have any thoughts or experience doing something like this, i.e.
running "foreign" Linux distros under CentOS via systemd-nspawn?  What
if I tried to do this with Debian or Arch or Gentoo?


[1] http://negativo17.org/handbrake/
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] firewalld rule syntax

[Clint Dilks]

However, at the end
> firewall-cmd --zone=monitoring --add-interface=ens192
>
> This results in a zone conflict. I'm not sure if it's even possible to
> have two zones on the interface.
>
> Hi Nick,

I don't believe an interface can belong to multiple zones.

Instead I think you what a rich rule, the example below would add this to
the default zone

firewall-cmd –add-rich-rule 'rule family=“ipv4” source address=“x.x.x.x/16”
service name=“http” accept'
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] firewalld rule syntax

[Nick Bright]

On 11/17/2015 1:20 PM, James Hogarth wrote:

A zone applies to a source network or interface.

Have a flick through:
https://www.hogarthuk.com/?q=node/9

Surprised SNMP isn't already defined as a service in
/usr/lib/firewalld/services  Perhaps snmpd ? Don't have a system to
hand to check.


I didn't think to try "snmpd", because "http" isn't "httpd" and so on.

I was also surprised to not find SNMP defined, though it was easy enough 
to do so. I would have assumed that anything in /etc/services would be 
defined.


--
---
-  Nick Bright-
-  Vice President of Technology   -
-  Valnet -=- We Connect You -=-  -
-  Tel 888-332-1616 x 315 / Fax 620-331-0789  -
-  Web http://www.valnet.net/ -
---
- Are your files safe?-
- Valnet Vault - Secure Cloud Backup  -
- More information & 30 day free trial at -
- http://www.valnet.net/services/valnet-vault -
---

This email message and any attachments are intended solely for the use of the 
addressees hereof. This message and any attachments may contain information 
that is confidential, privileged and exempt from disclosure under applicable 
law. If you are not the intended recipient of this message, you are prohibited 
from reading, disclosing, reproducing, distributing, disseminating or otherwise 
using this transmission. If you have received this message in error, please 
promptly notify the sender by reply E-mail and immediately delete this message 
from your system.

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

Re: [CentOS] centos 7 and keychain

[Wes James]

> On Nov 17, 2015, at 11:27 AM, Pete Stieber  wrote:
> 
> Is there a centos recommended repository for centos 7 where I can obtain the 
> keychain package?
> 
> TIA,
> Pete

I can only see a version for centos 6:

http://pkgs.repoforge.org/keychain/ 

You’ll need to download the src and see if you can build it. ??

-wes

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

Re: [CentOS] firewalld rule syntax

[James Hogarth]

On 17 Nov 2015 17:30, "Nick Bright"  wrote:
>
> On 11/17/2015 11:12 AM, Nick Bright wrote:
>>
>> firewall-cmd --zone=monitoring --add-source=1.2.3.4/32
>> firewall-cmd --zone=monitoring --add-service=snmp
>> firewall-cmd --zone=monitoring --add-interface=ens192
>> firewall-cmd --runtime-to-permanent
>
> I went ahead and tried this and found that the zone and service must
first be created, which requires use of:
>
> firewall-cmd --new-zone=monitoring --permanent (--permanent is required)
> firewall-cmd --new-service=snmp
>
> edit /etc/firewalld/services/snmp.xml:
> 
> 
> snmp
> Simple Network Management Protocol
> 
> 
>
> firewall-cmd --reload
>
> However, at the end
> firewall-cmd --zone=monitoring --add-interface=ens192
>
> This results in a zone conflict. I'm not sure if it's even possible to
have two zones on the interface.
>
>

A zone applies to a source network or interface.

Have a flick through:
https://www.hogarthuk.com/?q=node/9

Surprised SNMP isn't already defined as a service in
/usr/lib/firewalld/services  Perhaps snmpd ? Don't have a system to
hand to check.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] firewalld being stupid

[J Martin Rushton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 17/11/15 17:29, Dennis Jacobfeuerborn wrote:
> On 17.11.2015 17:51, m.r...@5-cent.us wrote:
>> Nick Bright wrote:
>>> On 11/17/2015 8:18 AM, James B. Byrne wrote:
 This behaviour is congruent with SELinux. One utility adjusts
 the permanent configuration, the one that will be applied at
 startup. Another changes the current running environment
 without altering the startup config. From a sysadmin point of
 view this is desirable since changes to a running system are
 often performed for empirical testing. Leaving ephemeral
 state changes permanently fixed in the startup config could,
 and almost certainly would eventually, lead to serious 
 problem during a reboot. Likewise, immediately introducing a
 state change to a running system when reconfiguring system
 startup options is just begging for an operations incident
 report. It may not be intuitive to some but it is certainly
 the logical way of handling this.
>>> 
>>> I certainly don't disagree with this behavior.
>>> 
>>> What I disagree with is documented commands _*not working and
>>> failing silently*_.
>>> 
>> I agree, and it seems to be the way systemd works, as a theme, as
>> it were. I restart a service... and it tells me *nothing* at all.
>> I have to run a second command, to ask the status. I've no idea
>> why it's "bad form" to tell me progress, and final result. You'd
>> think they were an old New Englander.
> 
> Systemd has better mechanisms to report feedback compared to SysV 
> scripts but if the creators of the service files and the daemons
> don't make use of these that's hardly systemd's fault. The best way
> is to use "Type=notify" which allows a daemon to actually report to
> systemd when it is done initializing. If the daemon doesn't support
> this then you can still use ExecStartPost to specify a command that
> verifies that the daemon indeed did start up correctly (and no the
> binary returning a code of 0 does not mean the service is actually
> up-and-running properly).
> 
> Regards, Dennis
> 
You may well be right.  However for those of us who just want to get
the system running it has lousy reporting.  Under SysV setting -vx on
the script gave meaningful output - there's no easy equivalent under
systemctl.  Systemctl returning success status on daemon failure is
plain stupid.  I'm sure systemd does wonderful things and is the
future and we're stuck with it now until at least CentOS/RHEL 8.  One
of the great joys of *NIX is small, stable text files that can be
handled without vast study unlike the obscure behemoth that would look
good coming out of Redmond.  Even getting ntp to supply time to
another system takes hours instead of 5 minutes.

If I ever meet Poettering I'll be sure to sup with a long spoon. ;-(
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJWS5ksAAoJEAF3yXsqtyBlA1oQANrvHWI3JbGUfREfZWYUiRxi
ZTP3rATIyXwbmgK7ApcanAXqrnF1M1PmSarmnLQFhaNdNI1an5YdT/qM5tpnBUwg
MemJSUNZHPAxdg8KDqRr2alb0jLK/GHALO+43XaEQN3CMZfZbz2rU6xKToNtF4GP
YK2o+UdPGnpvs8fj8kXkIiLiBn6rc9pBl0MABLnfdqvS13LggrUPFVhcc6oyH2FS
IgQk8rmOgFaiiqKb5r3hRpWvVbDpBo+J4CiHa0qI3d3R4OgDgZHFLfwX0CJCjbty
Kkoe/qJgNwHXnHwlJ7ZyEgx+ARKTI8Wii8S7sM0ZSAaAnkdf1SltC8DXn0jKCUKo
7Q5eYzNuf86XOfGCjrLG57Hy7v8aQG3NVa4pLFrhKUvEIjNvE14DePX18bp3Y7Yv
aKhBdnu/UVkSvoriCLCAtbVnZvKv6Jj6v9ayW6Ke/Uyfphs24m0KCM4rlMQjH9hj
IsD6qJVc2yfLQMZ9OL8emusXLRAmRf002oWVtFrBaskdL9GFkG00eMewADyFyM2r
HUlkcGdP4EsFaPF74spRjhY4sl+PRQ3Hl3QyQ5xz51N8+bnuua3Dv5gniDDeqMc/
3pa4IZAReYN6drO7dKBmh2AGqVX7C8JZJDsJ5kb8PN0O4L2SAq/V4rB3lb1w/WoY
TH9EcBGRtdmNxsF801Ah
=QOQq
-END PGP SIGNATURE-
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] firewalld being stupid

[m . roth]

J Martin Rushton wrote:
> On 17/11/15 17:29, Dennis Jacobfeuerborn wrote:
>> On 17.11.2015 17:51, m.r...@5-cent.us wrote:
>>> Nick Bright wrote:
 On 11/17/2015 8:18 AM, James B. Byrne wrote:
> This behaviour is congruent with SELinux. One utility adjusts
> the permanent configuration, the one that will be applied at
> startup. Another changes the current running environment
> without altering the startup config. From a sysadmin point of
> view this is desirable since changes to a running system are
> often performed for empirical testing. Leaving ephemeral
> state changes permanently fixed in the startup config could,
> and almost certainly would eventually, lead to serious
> problem during a reboot. Likewise, immediately introducing a
> state change to a running system when reconfiguring system
> startup options is just begging for an operations incident
> report. It may not be intuitive to some but it is certainly
> the logical way of handling this.

 I certainly don't disagree with this behavior.

 What I disagree with is documented commands _*not working and
 failing silently*_.

>>> I agree, and it seems to be the way systemd works, as a theme, as
>>> it were. I restart a service... and it tells me *nothing* at all.
>>> I have to run a second command, to ask the status. I've no idea
>>> why it's "bad form" to tell me progress, and final result. You'd
>>> think they were an old New Englander.
>>

>> binary returning a code of 0 does not mean the service is actually
>> up-and-running properly).
>>
> You may well be right.  However for those of us who just want to get
> the system running it has lousy reporting.  Under SysV setting -vx on
> the script gave meaningful output - there's no easy equivalent under
> systemctl.  Systemctl returning success status on daemon failure is
> plain stupid.  I'm sure systemd does wonderful things and is the
> future and we're stuck with it now until at least CentOS/RHEL 8.  One
> of the great joys of *NIX is small, stable text files that can be
> handled without vast study unlike the obscure behemoth that would look
> good coming out of Redmond.  Even getting ntp to supply time to
> another system takes hours instead of 5 minutes.
>
> If I ever meet Poettering I'll be sure to sup with a long spoon. ;-(

Actually, I think I've figured out why systemd... let's see, the CEO of
upstream was CEO of Delta Airlines before he came to RH (?!), and now
this



mark

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