Re: [CentOS] almalinux?

[Peter Eckel via CentOS]

> Looking.  Rocky was supposed to release something at the beginning of the
> month, but I haven't seen anything.

The release was postponed by one month.

"Unfortunately we’ve had to revise our previous update for a release candidate 
from March 31 to April 30, due to complications in the build efforts. We 
continue to make steady progress, and are optimistic about our revised 
timeline."





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

Re: [CentOS] almalinux?

[Peter Eckel via CentOS]

Hi Simon,

+1

I expect that to happen sooner or later. Currently Alma has a head start with 
Rocky postponed until the end of April, but to me the race is still open.

As is the case with many other colleagues, I'm currently stuck with RHEL clones 
because RHEL/CentOS is what my customers are using and they are not going to 
switch to Debian/FreeBSD/Ubuntu/whatever any time soon for a plethora of 
reasons. So it would be nice to have a one-stop-solution instead of having to 
decide which of the clones will be the more future-proof option.

Regards,

  Peter.

> On 5. Apr 2021, at 20:31, Simon Matter  wrote:
> 
> 
>> 
>> Anyone looked into almalinux? I was sort of waiting for rocky, but I see
>> from over the weekend on slashdot that almalinux stable is released.
>> 
>>mark
> 
> I hoped they would join forces and produce only one RHEL clone but put
> some effort into bringing EPEL to a usable state for EL8 instead. IMHO
> that would help *MUCH* more than to have two almost identical rebuilds of
> RHEL.
> 
> Simon
> 
> ___
> 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

Re: [CentOS] almalinux?

[Peter Eckel via CentOS]

Hi Mark, 

> Anyone looked into almalinux? I was sort of waiting for rocky, but I see from 
> over the weekend on slashdot that almalinux stable is released.

yup. 

So far I upgraded a couple of test machines using the conversion tool they 
provided on GitHub (works fine, although it seems each and every package will 
be re-downloaded during the migration process which makes it a bit tedious), 
and I used my own KVM/virt-install/Kickstart/Ansible-Workflow to bring up one 
new server from scractch with no further change than swapping the ISO image for 
CentOS against the one for Alma 8.3.

Both procedures worked absolutely flawless, and so far I still have to find the 
first issue with any of the machines converted to or initially set up with 
AlmaLinux.

Caveat:

1. All of the machines I tried are VMs, no bare metal servers or VM hosts.
2. All of the machines are headless with no GUI installed at all.
3. No UEFI or Secure Boot (the latter is an open issue with Alma AFAIK).

On the other hand I did not need to change a single bit of Ansible code or 
Kickstart template in order to make it work, so the compatibility to CentOS 
seems to be very good.

Regards, 

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

Re: [CentOS] KVM vs. incremental remote backups

[Peter Eckel via CentOS]

> All relevant logging is centralised to a server cluster running Graylog.

... and, because I forgot to mention it: Yes, that server cluster has a 
"persistent data" device.

Regards, 

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

Re: [CentOS] KVM vs. incremental remote backups

[Peter Eckel via CentOS]

Hi Simon, 

> Whenever I read such things I'm wondering, what about things like log
> files? Do you call them OS files or persistent data? How do you back'em up
> then?

I don't. 

All relevant logging is centralised to a server cluster running Graylog.

Regards, 

  Peter.

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

Re: [CentOS] KVM vs. incremental remote backups

[Peter Eckel via CentOS]

Hi Niki,

I'm using a similar approach like Stephen's, but with a kink.

* Kickstart all machines from a couple of ISOs, depending on the requirements 
(the Kickstart process is controlled by Ansible)
* Machines that have persistent data (which make up about 50% in average) have 
at least two virtual disk devices: The one for the OS (which gets overwritten 
by Kickstart when a machine is re-created), and another one for persistent data 
(which Kickstart doesn't touch)
* Ansible sets up everything on the base server Kickstart provides, starting 
from basic OS hardening, authentication and ending with monitoring and backup 
of the data volume
* Backup is done via Bareos to a redundant storage server

That way I can reinitialise a VM at any time without having to care for the 
persistent data in most cases. If persistent data need to be restored as well, 
Bareos can handle that as soon as the machine has been set up via Ansible. OS 
files are never backed up at all.

An improvement I'm planning to look into is moving from Kickstart to Terraform 
for the provisioning of the base machines. Currently it takes me about 10 
minutes to recreate a broken VM provided the persistent data is left intact. 

Cheers, 

  Peter.

> On 31. Mar 2021, at 14:41, Nicolas Kovacs  wrote:
> 
> Hi,
> 
> Up until recently I've hosted all my stuff (web & mail) on a handful of bare
> metal servers. Web applications (WordPress, OwnCloud, Dolibarr, GEPI,
> Roundcube) as well as mail and a few other things were hosted mostly on one 
> big
> machine.
> 
> Backups for this setup were done using Rsnapshot, a nifty utility that 
> combines
> Rsync over SSH and hard links to make incremental backups.
> 
> This approach has become problematic, for several reasons. First, web
> applications have increasingly specific and sometimes mutually exclusive
> requirements. And second, last month I had a server crash, and even though I
> had backups for everything, this meant quite some offline time.
> 
> So I've opted to go for KVM-based solutions, with everything split up over a
> series of KVM guests. I wrapped my head around KVM, played around with it (a
> lot) and now I'm more or less ready to go.
> 
> One detail is nagging me though: backups.
> 
> Let's say I have one VM that handles only DNS (base installation + BIND) and
> one other VM that handles mail (base installation + Postfix + Dovecot).
> 
> Under the hood that's two QCOW2 images stored in /var/lib/libvirt/images.
> 
> With the old "bare metal" approach I could perform remote backups using Rsync,
> so only the difference between two backups would get transferred over the
> network. Now with KVM images it looks like every day I have to transfer the
> whole image again. As soon as some images have lots of data on them (say, 100
> GB for a small OwnCloud server), this quickly becomes unmanageable.
> 
> I googled around quite some time for "KVM backup best practices" and was a bit
> puzzled to find many folks asking the same question and no real answer, at
> least not without having to jump through burning loops.
> 
> Any suggestions ?
> 
> Niki
> 
> -- 
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Blog : https://blog.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> Mob. : 06 51 80 12 12
> ___
> 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

Re: [CentOS] CentOS 8 future

[Peter Eckel]

Hi Johnny, 

> $250K is not even close.  That is one employee, when you also take into
> account unemployment insurance, HR, medical insurance etc.  now multiply
> that by 8.  Now, outfit those 8 employees to work from home .. all over
> the world, different countries, different laws.
> 
> .. THEN buy 30 machines minimum (servers, not workstations) for
> building and testing, buy a service contract for those 30 machines, host
> the bandwidth required to sync out to 600 worldwide servers.
> 
> We need all the CI machines .. that is a bunch of blade servers for
> that.  They need service contacts too.

I don't doubt your numbers, they sound perfectly reasonable to me. 

On the other hand: How many of the employees will be laid off or reallocated 
now that CentOS point releases are no longer published? How many of the servers 
will be shut down, how many service contracts will be cancelled? What's your 
estimate of the reduction in bandwidth that will be saved by replacing point 
releases by a stream of releases with more frequent updates?

> In any event it doesn't matter.  The decision is made. If people don't
> want to use CentOS Stream, then don't.  The decision is not changing.

Too bad.

I've just completed a migration of about 30 servers from CentOS 6 to CentOS 8, 
expecting to get another 9 years of lifetime out of that (substantial) work. 
Now I have one year left of that, in which I need to plan what to do. One 
option is to go with the flow and switch to Stream, but I must admit that it's 
not my favourite one. Rocky, Lenix or maybe Springsdale would be the next best 
guesses. But given the fact that I migrated the whole setup process to Ansible 
it might be a good idea to jump off the cliff and switch to Debian or FreeBSD. 
As I said, I have one year left  which I plan to use for evaluation of options.

Two of my big customers will definitely not have that range of options. One of 
them is a RHEL shop with a tendency to try Debian, and last week they strongly 
thought about leaving the RHEL space entirely. The FOSS team there had made 
substantial effort over the last year to get CentOS on the list of 
company-approved operating systems (currently that's only RHEL and Debian), and 
now that work has gone down the drain completely. You can imagine how they feel 
now.

The other one is stuck with RHEL-based distributions (Oracle, you know) - but 
they consider switching to OEL with support as well. At least they'll get rid 
of the hassle with the RHN that way, which can be a pain in the backside.

I doubt those two are the only ones. My guess is this decision will backfire 
big time. I would love to stand corrected in one year's time, because I really 
like the RHEL way of doing things. Or rather, I liked it. Until last week. 
Still a great set of products, but the trustworthiness of Red Hat has taken a 
big hit for me, and for my customers as well.

Anyway, thank you and the rest of the CentOS team for all the great work you've 
done and are doing. It is appreciated, and it will not be forgotten.

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

Re: [CentOS] Postfix vs. Thunderbird on Mac OS

[Peter Eckel]

Hi,

the main problem is that the MacBook obviously presents an illegal host name to 
the mail server, which in turn rejects accepting mail to be submitted from it 
because of 'reject_unknown_helo_hostname'.

With your 'smtpd_helo_restrictions', Postfix handles submissions from clients 
as it would handle mail from external mail servers, and so the wrong host name 
gets mail to be rejected. The mail submission doesn't even get to the point 
where 'smtpd_recipient_restrictions' are checked (which would allow senders 
from 'mynetworks') because 'smtpd_helo_restrictions' hits first. One way to fix 
that would be to put 'permit_mynetworks' into 'smtpd_helo_restrictions' (and of 
course provide proper settings for 'mynetworks') so the invalid host name is 
ignored for local networks.

If you want to fix the client instead (which I would recommend in any case), 
'scholae.lan' could be a domain the mail server cannot resolve (as seen from 
your log, your domain is 'scholae.fr'), and so the host name is rejected. Even 
if the domain were resolvable, there is in all likelihood no DNS entry for 
'Air-de-bea', so the name is technically invalid as far as Postfix is concerned.

The main question is where it got that host name from - most mis-configuration 
on the device itself, or on the DHCP server it uses to get its network 
configuration from.

If it's not the DHCP server, have a look at the 'Sharing' system configuration 
on the Mac. On top of that panel there is a field to configure the simple host 
name (in this case it'S probably "Air-de-bea"), and below that there's an 
'Edit' button that you can use to specify an alternate name and sn FQDN. If 
'Use dynamic global hostname' is checked, the Mac will use the hostname 
configured there - this might well be set to 'Air-de-bea.scholae.lan'.

If it's DHCP where the host name gets its name from, you'll need to have that 
fixed - either provide dynamic DNS updates, or assign a properly registered 
host name to the Mac.

Cheers,

  Pete.

> On 19. Sep 2019, at 10:43, Nicolas Kovacs  wrote:
> 
> Hi,
> 
> I'm running our local school's mail server on CentOS 7, Postfix and
> Dovecot. We get quite a lot of spam, so I have the following sender
> restrictions in my /etc/postfix/main.cf:
> 
> --8<--
> # Restrictions SMTP
> smtpd_helo_restrictions = reject_unknown_helo_hostname
> smtpd_sender_restrictions = reject_unknown_sender_domain,
>  check_sender_access hash:/etc/postfix/sender_access
> smtpd_recipient_restrictions = permit_mynetworks,
>  permit_sasl_authenticated,
>  reject_rbl_client zen.spamhaus.org,
>  reject_rhsbl_reverse_client dbl.spamhaus.org,
>  reject_rhsbl_helo dbl.spamhaus.org,
>  reject_rhsbl_sender dbl.spamhaus.org
> smtpd_relay_restrictions = permit_mynetworks,
>  permit_sasl_authenticated,
>  reject_unauth_destination
> smtpd_data_restrictions = reject_unauth_pipelining
> --8<--
> 
> Most folks are using Thunderbird on Linux, and everything works
> perfectly. One single user has a MacBook Air with Thunderbird on Mac OS
> Mojave, and her outgoing mails are rejected with the following error
> message in /var/log/maillog on the server:
> 
> --8<--
> Sep 16 14:22:32 sd-48011 postfix/smtps/smtpd[14434]: NOQUEUE: reject:
> RCPT from villa.figaret.pck.nerim.net[62.212.106.47]: 450 4.7.1
> : Helo command rejected: Host not found;
> from= to= proto=ESMTP
> helo=
> --8<--
> 
> As far as I understand, it has to do with this MacBook's host
> configuration.
> 
> Any suggestions?
> 
> Cheers from the sunny South of France,
> 
> Niki Kovacs
> --
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> Mob. : 06 51 80 12 12
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos



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

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

Hi Gordon, 

> There's probably going to be a lot of misinformation where bareos is 
> concerned.  The developers forked that product claiming that when they signed 
> license assignments they didn't know that this could or would allow Bacula to 
> begin a dual-license release in which some features were added to a separate 
> proprietary release. Bacula's developers claim that the fork included code 
> that was not licensed to them.  Their lawsuit was settled with undisclosed 
> terms.  Given what information is available publicly, I am inclined to 
> believe that the fork was in the wrong, but users are often more concerned 
> with protecting people that they like than they are in license compliance.


thanks for this interesting background information!

On the other hand, I'm not trying to defend one company against the other - 
their lawsuit has been settled as you wrote, and so that's stuff that is in the 
past and doesn't have much relevance from a technical viewpoint. 

When I switched from Bacula to Bareos it was a purely technical decision, 
driven by the ease of maintaining an installation of Bareos vs. Bacula. In the 
meantime, the forks have diverged a bit, and there are some very interesting 
features (such as a flavour of opportunistic TLS encryption based on PSK) that 
make me stay with Bareos.

Leon's suggestion of creating a Backup SIG that could - among other things - 
maintain an RPM release of recent Bacula versions would IMHO really help Bacula 
a lot. At least it would eliminate my first reason for switching, and probably 
it would never have happened had current releases been available more easily.

Cheers, 

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

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

Hi Leon,

> IMHO - as Kern (Bacula lead developer) is pushing Bacula forward I dont 
> understand this too. It must be
> a misinformation about the current status of the project itself and 
> competitors interests (Bareos).

the fork of Bacula happened in 2013, IIRC. Things may have changed since then, 
but I did not bother to switch back. It's a good thing, however, that there was 
a change.

The fact that I can't find any recent RPMs anymore is definitely nothing that 
makes switching back an attractive option :-)

> IIRC Bacula is also open source software. Remember RHEL binaries are not free
> available ... if you are referring to precompiled MS Windows binaries of 
> Bacula).

In fact Bacula is open core, i.e. there is an enterprise version that has 
additional functionality not contained in the community edition. It's only 
fair, however, to note that there is also a downside to Bareos' concept - 
binary distributions are released less frequently to the community while 
enterprise service subscribers receive more frequent binary updates.

> BTW Bacula is included in CentOS/RHEL albeit in an older version. This 
> applies also
> for example to PHP and has the cause in the enterprise strategy of the 
> distribution.
> So don't blame the wrong one.

I'm not blaming anyone at all - as a user of CentOS/RHEL I know about the 
drawbacks of a stable enterprise vs. bleeding edge release strategy.

> Maybe a good reason to start a Backup SIG which provides a repository with 
> current bacula packages?

Hm ... there used to be a repository maintained by some company associated with 
Bacula, but I can't find it anymore - so it seems that starting a SIG taking 
care of that would be a good idea.

Cheers,

  Peter.


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

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

Hi Alessandro, 

> Why many users skip bacula? It is powerfull and very stable. It is very 
> difficult to setup but if you know how it works it is simple.

I used Bacula before I switched to Bareos. 

There was a point, however, when the open source release of Bacula became, to 
put it mildly, a bit too inactive for my taste. Obviously I wasn't alone with 
this, because roughly at that time Bareos was forked from Bacula. 



Essentially, Bareos is an improved (at least IMHO) fork of Bacula, and unlike 
Bacuka it's fully open source.

Cheers, 

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

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

Hi Valeri,

> you mean, director and STORAGE daemon, right? File daemon _IS_ a client...

yep. I noticed when klicking on 'send', as usual :-)

Cheers,

  Peter.


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

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

I must correct myself:

> I always do it the other way around, i.e. upgrade the director/file daemon 
> and then the clients as time suits. No problems with that so far.

I meant storage daemon, not file daemon!

Cheers,

  Peter.


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

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

Hi Alessandro,

> What if I will use bareos I will never get problem between version like 
> happening today with bacula?

difficult to say - I never ran into any upgrade issues with Bareos, but neither 
with Bacula while I was still using it.

> I could use newer bareos client on older bareos director?

I always do it the other way around, i.e. upgrade the director/file daemon and 
then the clients as time suits. No problems with that so far.

Do you happen to be at FOSDEM? The Bareos team is going to be there, as usual: 


Cheers,

  Peter.


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

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

> Amanda (from base CentOS) -> USB removable disk -> firesafe.
> 
> Backups on or by the computer might protect you from disk failures, but
> are useless in case of fire or theft.

Good point. The backup strategy is at least as important as the tool used.

Using Bacula, I'm doing daily backups of critical data (which is not 
everything, but i.e. my business data) to an encrypted disk on an offsite 
server 400km from here over the internet.

I'm also still doing backups to external physical media, but on a much looser 
schedule since it's always some effort to bring them to my offsite safe. The 
best backup of your work is pretty useless when it's two months old.


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

Re: [CentOS] Centos 7 and backup solution

[Peter Eckel]

Hi Alessandro,

> what type of backup solution do you use on C7?

the same as on most other operating systems: Bareos.



Bareos has some learning curve, but it's free, it's extremely reliable and 
flexible. I've been using it for years, after switching from its parent Bacula, 
which I've been using for years before that, and it has not failed me once when 
I needed it.

Cheers,

  Peter.


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

Re: [CentOS] email Server for CentOS 7

[Peter Eckel]

> On 29. Sep 2018, at 23:58, John R. Dennison  wrote:
> 
> Save yourself the effort, time, headaches and eventual bloody tears of 
> impotent
> rage and just go with Google or some other provider. Running a mail
> server properly is one of the more difficult tasks and quite often not
> worth the time and trouble, especially if one is asking about it on a
> list such as this.

I fully agree with most of the former, except for the Google part. Google is to 
privacy what a shark pool is to a carp. If possible, avoid Google at all cost, 
and particularly for E-Mail. There are services around that cost a very small 
amount of money (e.g. mailbox.org or posteo.de), provide a very reasonable 
service and do *not* peek into your mail for advertisement targets and sell 
your data to their customers.

If you want to run your own mail server (there are good reasons to do so, I've 
been running my own services for many years now) be prepared for a learning 
curve, as mail is not as simple and straightforward as it looks. You should 
also run your own DNS in that case, as many modern features of secure mail 
services are tightly linked to DNS (e.g. SPF, DKIM, DMARC etc.). DNSsec is 
preferred. 

There are some good books around (e.g. the Postfix/Dovecot books by Peer 
Heinlein, who incidentally is the owner of the mailbox.org service, but the 
Postfix book only seems to be available in German). Without a good foundation 
on running mail servers and/or some help from experienced mail server operators 
you're almost certain to screw up big time, which in most cases means ending up 
on some blacklists or having mail delivered very unreliably. 

As for the software question, I recommend the Postfix/Dovecot setup, enriched 
with some additional components to support graylisting, virus checking, spam 
filtering, DKIM, DMARC and SPF.

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

Re: [CentOS] Admins supporting both RHEL and CentOS

[Peter Eckel]

Hi Joseph, 

> On 28. Nov 2017, at 14:06, 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.

I concur with the latter: I also often see RHEL installations where the admins 
assume they are running "RHEL 7.3" rather than "RHEL 7". In some cases there 
isn't even an upgrade mechanism in place: Systems are installed from ISO images 
(usually by the solution vendor) and there are no upgrades whatsoever until the 
system gets decommissioned.

While that may seem a bit strange insofar as the upgrade mechanism with RHEL 
works quite the same as with CentOS by default (running updates regularly will 
make RHEL cross .x boundaries when they are reached), the different behaviour 
might come from three facts: 1. some vendors restrict their support to specific 
.x releases, 2. RHEL systems tend to run in production environments more often 
than CentOS systems, so they are subject to stricter rules regarding testing 
and clearance of updates, and 3. maintaining a RHN satellite or allowing 
internet access for RHN-registered systems is not part of the enterprise's IT 
strategy (don't laugh).

> What is the case with users on this list who support both?

I for my part treat RHEL and CentOS basically the same with respect to upgrades 
wherever possible: The test stages are quite near to the current bleeding-edge 
release (if that expression is not too far-fetched for an enterprise 
distribution), and after successful testing (usually a couple of weeks to a 
month, with the exception of security updates which are higher prioritised) 
they go into production.

Cheers, 

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

Re: [CentOS] Failed attempts

[Peter Eckel]

Hi Valeri, 

> Good luck! Use strong passwords (passphrase I call it when I talk to my
> users), especially for root account.

if possible: Do not use passwords at all. Disable password login, and replace 
by SSH private/public key authentication, and, again if possible, with OTP (two 
factor authentication) on top. 

All the other hints (disallow root access via SSH, use strong passwords, port 
knocking, different ports etc.) just put the hurdle a bit higher but do not 
solve the underlying problem: Password authentication is weak by design, as it 
relies on the well-behaviour of users. Don't restrict their passwords and 
they'll use simple ore easily-guessible ones. Restrict them and they will write 
them down. 

Cheers, 

  Pete.


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

Re: [CentOS] File access in Apache 2.4

[Peter Eckel]

Hi Gordon, 

> Or you could just run "systemctl edit httpd.service" like I suggested two 
> days ago.  :)

... which is a nice way of doing it quickly, indeed. Thanks for the hint, I 
didn't know that command. 

However there is one disadvantage: All changes go into a file named 
'override.conf', and if one wants to separate them it's still necessary to know 
where the configuration change is actually stored. 

I do a lot of stuff with tools like Ansible these days and have made it a 
custom to keep separate configuration changes in separate files (and 'systemctl 
edit ...' wouldn't work well for that purpose anyway). 

Cheers, 

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

Re: [CentOS] File access in Apache 2.4

[Peter Eckel]

> official way is to copy the unit file to  /etc/systemd/system and edit
> this copy.

that's one way to do it. It has the disadvantage of overriding *all* settings 
in the vendor-supplied unit files, which may be changed or extended in later 
releases. 

I prefer the other supported way (see 
):

1. Create a directory named after the unit in /etc/systemd/system, 
/etc/systemd/system/httpd.service.d/

2. Create an override file within that directory, for instance 
private-tmp.conf, with the following contents: 

  [Service]
  PrivateTmp=false

3. Run "systemd daemon-reload" and "systemd restart httpd"

You can verify that the override file has been loaded with 

> [root@master1 ~]# systemctl status httpd
> ● httpd.service - The Apache HTTP Server
>Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor 
> preset: disabled)
>   Drop-In: /etc/systemd/system/httpd.service.d
>└─private-tmp.conf

This will override only the setting you want to override and still survive 
updates.

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

Re: [CentOS] CentOS 7 selinux

[Peter Eckel]

Hi Larry, 

> If I make a change to /etc/sysconfig/selinux do I have to restart anything
> for the change to take effect?

It depends. 

If you are changing the SELinux mode from 'enforcing' to 'permissive' and vice 
versa, you can make that change active in the running system by issuing the 
'setenforce 1' or 'setenforce 0' command, respectively. 

If you want to go to or from 'disabled' or change the SELinux policy you'll 
need to reboot to activate the change. 

Regards, 

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

Re: [CentOS] Google Ads in rsyslog documentation files

[Peter Eckel]

Hi Mark,

>> CASE 01544649 opened upstream.
> 
> Thanks, Pete. I was just discussing it with my manager

if he agreed to you opening (or backing) the case that would be great. I just 
became aware that my developer account is not entitled to raising issues :-(

I can send you the reply of RH offline if you want to handle this further.

  Pete.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Google Ads in rsyslog documentation files

[Peter Eckel]

Hi Mark, 

I'm not sure whether upstream is the right place to address this, but I'll try. 
I just downloaded all versions of the rsyslog sources from rsyslog.com, and 
found 'googlesyndication' links in the following versions: 

rsyslog-4.8.0
rsyslog-5.10.0
rsyslog-5.10.1
rsyslog-5.8.13
rsyslog-6.6.0
rsyslog-7.3.0
rsyslog-7.3.1
rsyslog-7.3.2
rsyslog-7.3.3
rsyslog-7.3.4
rsyslog-7.3.5
rsyslog-7.3.6
rsyslog-7.3.7
rsyslog-7.3.8
rsyslog-7.3.9
rsyslog-7.3.10
rsyslog-7.3.11
rsyslog-7.3.12
rsyslog-7.4.0
rsyslog-7.4.1
rsyslog-7.4.2
rsyslog-7.4.3
rsyslog-7.4.4
rsyslog-7.4.5
rsyslog-7.4.6
rsyslog-7.4.7
rsyslog-7.4.8
rsyslog-7.4.9
rsyslog-7.4.10
rsyslog-7.5.0
rsyslog-7.5.1
rsyslog-7.5.2
rsyslog-7.5.3
rsyslog-7.5.4
rsyslog-7.5.5
rsyslog-7.5.6

Which means it's gone in 8.x.x and in 7.x.x starting from 7.5.6. 4.x.x, 5.x.x 
and 6.x.x haven't been cleaned ever.

CASE 01544649 opened upstream.

Cheers, 

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

[CentOS] Google Ads in rsyslog documentation files

[Peter Eckel]

Hi all, 

I know this comes from upstream (and most likely from the rsyslog project 
itself), but what's your opinion about Google Ads in system documentation 
files? 

> [peckel@mucnvjmppmtr01 ~]$ cat /etc/redhat-release 
> Red Hat Enterprise Linux Server release 6.7 (Santiago)
> [peckel@mucnvjmppmtr01 ~]$ grep google /usr/share/doc/rsyslog-5.8.10/*
> /usr/share/doc/rsyslog-5.8.10/rsyslog_secure_tls.html:google_ad_client = 
> "pub-3204610807458280";
> /usr/share/doc/rsyslog-5.8.10/rsyslog_secure_tls.html:google_ad_slot = 
> "5958614527";
> /usr/share/doc/rsyslog-5.8.10/rsyslog_secure_tls.html:google_ad_width = 125;
> /usr/share/doc/rsyslog-5.8.10/rsyslog_secure_tls.html:google_ad_height = 125;
> /usr/share/doc/rsyslog-5.8.10/rsyslog_secure_tls.html:src="http://pagead2.googlesyndication.com/pagead/show_ads.js";>
> /usr/share/doc/rsyslog-5.8.10/tls_cert_ca.html:google_ad_client = 
> "pub-3204610807458280";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_ca.html:google_ad_slot = "5958614527";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_ca.html:google_ad_width = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_ca.html:google_ad_height = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_ca.html:src="http://pagead2.googlesyndication.com/pagead/show_ads.js";>
> /usr/share/doc/rsyslog-5.8.10/tls_cert_client.html:google_ad_client = 
> "pub-3204610807458280";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_client.html:google_ad_slot = 
> "5958614527";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_client.html:google_ad_width = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_client.html:google_ad_height = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_client.html:src="http://pagead2.googlesyndication.com/pagead/show_ads.js";>
> /usr/share/doc/rsyslog-5.8.10/tls_cert_errmsgs.html:google_ad_client = 
> "pub-3204610807458280";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_errmsgs.html:google_ad_slot = 
> "5958614527";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_errmsgs.html:google_ad_width = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_errmsgs.html:google_ad_height = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_errmsgs.html:src="http://pagead2.googlesyndication.com/pagead/show_ads.js";>
> /usr/share/doc/rsyslog-5.8.10/tls_cert_machine.html:google_ad_client = 
> "pub-3204610807458280";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_machine.html:google_ad_slot = 
> "5958614527";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_machine.html:google_ad_width = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_machine.html:google_ad_height = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_machine.html:src="http://pagead2.googlesyndication.com/pagead/show_ads.js";>
> /usr/share/doc/rsyslog-5.8.10/tls_cert_scenario.html:google_ad_client = 
> "pub-3204610807458280";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_scenario.html:google_ad_slot = 
> "5958614527";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_scenario.html:google_ad_width = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_scenario.html:google_ad_height = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_scenario.html:src="http://pagead2.googlesyndication.com/pagead/show_ads.js";>
> /usr/share/doc/rsyslog-5.8.10/tls_cert_server.html:google_ad_client = 
> "pub-3204610807458280";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_server.html:google_ad_slot = 
> "5958614527";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_server.html:google_ad_width = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_server.html:google_ad_height = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_server.html:src="http://pagead2.googlesyndication.com/pagead/show_ads.js";>
> /usr/share/doc/rsyslog-5.8.10/tls_cert_summary.html:google_ad_client = 
> "pub-3204610807458280";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_summary.html:google_ad_slot = 
> "5958614527";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_summary.html:google_ad_width = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_summary.html:google_ad_height = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_summary.html:src="http://pagead2.googlesyndication.com/pagead/show_ads.js";>
> /usr/share/doc/rsyslog-5.8.10/tls_cert_udp_relay.html:google_ad_client = 
> "pub-3204610807458280";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_udp_relay.html:google_ad_slot = 
> "5958614527";
> /usr/share/doc/rsyslog-5.8.10/tls_cert_udp_relay.html:google_ad_width = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_udp_relay.html:google_ad_height = 125;
> /usr/share/doc/rsyslog-5.8.10/tls_cert_udp_relay.html:src="http://pagead2.googlesyndication.com/pagead/show_ads.js";>

I find it rather disconcerting if there are commercial ads embedded in help 
texts I find on my open source servers. 

Best regards, 

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

Re: [CentOS] Another Fedora decision

[Peter Eckel]

Hi Johan,

> His point in short: passwords are not all that important any more.
> All virus spreading and hacking these days is done by sending malicous mails 
> and by visiting malicious sites.

If your brother in law doesn't see that the virus argument 
doesn't apply to the question of whether or not to choose strong passwords 
maybe he shouldn't be a software developer in the first place.

Strong passwords don't protect against viruses, phishing etc. pp., that is 
true. But having weak passwords opens a plethora of other attack vectors beside 
that, and as for instance the iTunes hack shows there *are* real-world 
scenarios where passwords are attacked successfully. Just put an ssh server on 
a public IP and wait for a day, and you'll see how many.

Regarding the original issue, I don't see where requiring users to enter 
strong(ish) passwords in the GUI installer at installation time could do any 
harm except a minor inconvenience for some people. Kickstart is not affected, 
so automated installs won't break, and on the other hand the use of weak 
passwords may be reduced a bit by the change. I'm all for it.

Cheers,

  Peter.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Text file encoding

[Peter Eckel]

Hi Patrick, 

>   iconv -f MACINTOSH -t ISO8859-15 file.bib.mac >file.bib
>   iconv -f ISO8859-15 -t MACINTOSH file.bib >file.bib.mac
> 
> But it is a little tedious to work like this...
> 
> Runing pdflatex (in CentOS) on these files written on apple laptops works 
> fine with
> 
>   \usepackage[applemac]{inputenc}
> 
> So the main problem is an editor problem. I've tried several ones (nedit, 
> gedit, kate, vim...) none of them seams to support this encoding. But may be 
> it is a configuration problem ?
> 
> Any idea ?

Use UTF-8 on all platforms. 

Most ediors on the Mac, among them the predominant LaTeX editor for Mac OS X, 
TeXshop, can (and should) be set to use UTF-8 as the default encoding, and if 
exchanging textual data between platforms is an issue, UTF-8 (or -16) is the 
only sensible solution. 

Opening files with language specific characters such as German Umlauts in Linux 
is no problem if the files have been encoded as UTC-8 and UTF-8 is set as the 
locale on Linux.

Cheers, 

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

Re: [CentOS] ssh-askpass in bash script

[Peter Eckel]

Hi Les, 

> Errr, 'unattended jobs' are the main reason for having computers.

I differentiate here between desktop machines and servers ... regarding servers 
you're definitely right, but though I don't have reliable data I'd say from 
experience that the vast majority of ssh keys are stored on desktop systems 
used to administer servers. And those are exactly the ones I'd rather never see 
being used without a strong passphrase.

> Well, that and watching kitten videos.

You're definitely correct here :-)

Cheers, 

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

Re: [CentOS] ssh-askpass in bash script

[Peter Eckel]

Hi Joseph, 

> Why not just use authorized_keys with an empty pass phrase?

because every responsible system admin will immediately kill you when you do 
that? :-)

Except in very specific situations, e.g. unattended jobs that copy data or 
execute commands over ssh connections, it is very unwise to *ever* create an 
ssh key without a passphrase, as the only thing between that key and access to 
the systems it 'protects' is then file permissions on the server it is located 
on. 

Even in the few situations where it is unavoidable (in most cases it just seems 
so) to use an unprotected key, actions should be taken to limit its usability 
as much as possible (no-pty, forced commands etc.). 

The sensible way to achieve what the OP wants is to use an SSH agent.

Cheers, 

  Peter.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] bind (named) compromised?

[Peter Eckel]

Hi James, 

you seem to be running an open DNS resolver, is that correct? And if so, do you 
do it intentionally?

I just received an US-CERT alert today that warns about ongoing amplification 
attacks, among others against DNS, but also against some other UDP based 
services.



From the symptoms you describe I'd say that your DNS server is being used in 
such an attack. 

> I also see a chroot directory, but if I grep for named it doesn't appear 
> to be using the chroot(?):
> # ps aux | grep named
> named 3497  0.4  0.7 170088 15836 ?Ssl  23:02   0:02 
> /usr/sbin/named -u named
> root  3763  0.0  0.0  61192   764 pts/1S+   23:13   0:00 grep named

Do you have the bind-chroot package installed?

Best regards, 

  Peter.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How can I disable PostFix maillog ( /var/log/maillog )

[Peter Eckel]

> But, When my server handle a big file ..
> Maybe, It's use more Ram memory.

No. Don't worry.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What is eating up Swap

[Peter Eckel]

Hi Götz, 

On Dec 10, 2013, at 15:01 , Götz Reinicke - IT Koordinator 
 wrote:

> Hi,
> 
> recently I noticed, that one of our webservers is using swap space,
> while there is plenty of physical ram available.
> 
> free -m
> total   used   free sharedbuffers cached
> Mem:  8118   2014   6103  0 85261
> -/+ buffers/cache:   1667   6450
> Swap: 8197 77   8119
> 
> 
> It's not that much, but why?

my first idea would be that RAM usage was higher temporarily, which led to some 
pages being swapped out, and those pages haven't been used since so they were 
never swapped in again. 

> Any ideas how to debug that? Thanks for any hint and suggestion.

/proc/*/smaps is a starting point. It's fairly easy to write a little script 
that adds the values in the Swap: lines for each process and calculates swap 
usage per process. 

Bests, 

  Peter.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: Script Help

[Peter Eckel]

Oops, I read that too late ... 

> Let's say my original lines are:
> CN=DATA.OU=XYZ.O=CO
> CN=DATA.OU=XYY.OU=MEM.O=CO
> CN=DATA.OU=XZZ.OU=OOP.O=CO
> 
> I want them to look like:
> CN=XYZ_DATA.OU=XYZ.O=CO
> CN=XYY_DATA.OU=XYY.OU=MEM.O=CO
> CN=XZZ_DATA.OU=XZZ.OU=OOP.O=CO

then the perl script would be 

  perl -pne 's/(CN=)(DATA\.OU=)((.*?)\.O.*)$/$1$4_$2$3/' /file/name

Best regards, 

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

Re: [CentOS] OT: Script Help

[Peter Eckel]

Hi James, 

  perl -pne 's/^(CN=)(DATA\.OU=)((.*?)\.O=CO)$/$1$4_$2$3/' /file/name

or, if you prefer in-place editing, 

  perl -i.bak -pne 's/(CN=)(DATA\.OU=)((.*?)\.O=CO)/$1$4_$2$3/' /file/name

which replaces the file with the modified version and keeps a .bak file around 
for security. 

Example: 

lagavulin:~ pete$ cat /tmp/test
some text
some text2
CN=DATA.OU=XYZ.O=CO
some text3
some text4
some text
some text2
CN=DATA.OU=RST.O=CO
some text3
some text4
some text
some text2
CN=DATA.OU=ABC.O=CO
some text3
some text4
some text
some text2
CN=DATA.OU=UVWXYZ.O=CO
some text3
some text4

lagavulin:~ pete$  perl -pne 's/(CN=)(DATA\.OU=)((.*?)\.O=CO)/$1$4_$2$3/' 
/tmp/test
some text
some text2
CN=XYZ_DATA.OU=XYZ.O=CO
some text3
some text4
some text
some text2
CN=RST_DATA.OU=RST.O=CO
some text3
some text4
some text
some text2
CN=ABC_DATA.OU=ABC.O=CO
some text3
some text4
some text
some text2
CN=UVWXYZ_DATA.OU=UVWXYZ.O=CO
some text3
some text4

I guess that's what you need. 

Best regards, 

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

Re: [CentOS] Centos 6.4 - yum update gives: Error: kernel conflicts with bfa-firmware

[Peter Eckel]

Hi Johnny, 

> Can you post the kernel versions and bfa-firmware versions that are
> trying to up upgraded ... and whether you have the i386 or x86_64
> version installed?

I'm getting exactly the same error when I try to update using the 'updates' 
repo only: 

> [root@orcus7 ~]# yum update --disablerepo=* --enablerepo=updates 
> Loaded plugins: downloadonly
> updates   
>| 3.5 kB   
>   00:00 
> Setting up Update Process
> Resolving Dependencies
> --> Running transaction check
> ---> Package bind-libs.x86_64 32:9.8.2-0.10.rc1.el6_3.6 will be updated
> ---> Package bind-libs.x86_64 32:9.8.2-0.17.rc1.el6.3 will be an update
> ---> Package bind-utils.x86_64 32:9.8.2-0.10.rc1.el6_3.6 will be updated
> ---> Package bind-utils.x86_64 32:9.8.2-0.17.rc1.el6.3 will be an update
> ---> Package cups.x86_64 1:1.4.2-48.el6_3.3 will be updated
> ---> Package cups.x86_64 1:1.4.2-50.el6_4.4 will be an update
> ---> Package cups-libs.x86_64 1:1.4.2-48.el6_3.3 will be updated
> ---> Package cups-libs.x86_64 1:1.4.2-50.el6_4.4 will be an update
> --> Processing Dependency: libjpeg.so.62(LIBJPEG_6.2)(64bit) for package: 
> 1:cups-libs-1.4.2-50.el6_4.4.x86_64
> ---> Package dbus-glib.x86_64 0:0.86-5.el6 will be updated
> ---> Package dbus-glib.x86_64 0:0.86-6.el6 will be an update
> ---> Package gnutls.x86_64 0:2.8.5-4.el6_2.2 will be updated
> ---> Package gnutls.x86_64 0:2.8.5-10.el6_4.1 will be an update
> ---> Package kernel.x86_64 0:2.6.32-358.0.1.el6 will be installed
> ---> Package kernel-firmware.noarch 0:2.6.32-279.22.1.el6 will be updated
> ---> Package kernel-firmware.noarch 0:2.6.32-358.0.1.el6 will be an update
> ---> Package libcgroup.x86_64 0:0.37-4.el6 will be updated
> ---> Package libcgroup.x86_64 0:0.37-7.1.el6 will be an update
> ---> Package libxml2.x86_64 0:2.7.6-8.el6_3.4 will be updated
> ---> Package libxml2.x86_64 0:2.7.6-12.el6_4.1 will be an update
> ---> Package openldap.x86_64 0:2.4.23-26.el6_3.2 will be updated
> ---> Package openldap.x86_64 0:2.4.23-32.el6_4 will be an update
> ---> Package openssl.x86_64 0:1.0.0-25.el6_3.1 will be updated
> ---> Package openssl.x86_64 0:1.0.0-27.el6_4.2 will be an update
> ---> Package selinux-policy.noarch 0:3.7.19-155.el6_3.14 will be updated
> ---> Package selinux-policy.noarch 0:3.7.19-195.el6_4.1 will be an update
> ---> Package selinux-policy-targeted.noarch 0:3.7.19-155.el6_3.14 will be 
> updated
> ---> Package selinux-policy-targeted.noarch 0:3.7.19-195.el6_4.1 will be an 
> update
> ---> Package tzdata.noarch 0:2012j-1.el6 will be updated
> ---> Package tzdata.noarch 0:2012j-2.el6 will be an update
> --> Processing Conflict: kernel-2.6.32-358.0.1.el6.x86_64 conflicts 
> bfa-firmware < 3.0.3.1
> --> Finished Dependency Resolution
> --> Running transaction check
> ---> Package cups-libs.x86_64 1:1.4.2-50.el6_4.4 will be an update
> --> Processing Dependency: libjpeg.so.62(LIBJPEG_6.2)(64bit) for package: 
> 1:cups-libs-1.4.2-50.el6_4.4.x86_64
> ---> Package kernel.x86_64 0:2.6.32-279.14.1.el6 will be erased
> --> Processing Conflict: kernel-2.6.32-358.0.1.el6.x86_64 conflicts 
> bfa-firmware < 3.0.3.1
> --> Finished Dependency Resolution
> Error: kernel conflicts with bfa-firmware
> Error: Package: 1:cups-libs-1.4.2-50.el6_4.4.x86_64 (updates)
>Requires: libjpeg.so.62(LIBJPEG_6.2)(64bit)
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest

I have the standard repos cr enabled. 

> [root@orcus7 ~]# yum list installed | grep bfa-firmware
> bfa-firmware.noarch3.0.0.0-1.el6  @base   
>   


It works, however, when I do an update with the 'base' repo enabled as well. 

> Also, what are you upgrading from?

In my case, CentOS 6.3 with daily updates installed. 

> We have not seen this specific issue in our QA testing.

I found it by accident because I run yum-cron and pull daily updates. 

Best regards, 

  Peter.

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] exim localhost vs 127.0.0.1

[Peter Eckel]

Hi Mihamina, 

> [mihamina@recette53 ~]$ rpm -aq | grep exim
> exim-4.72-4.el6.x86_64
> 
> [mihamina@recette53 ~]$ telnet localhost 25
> Trying ::1...
> Connected to localhost.
> Escape character is '^]'.
> 220 recette53.ideoneov.com ESMTP Exim 4.72 Mon, 11 Mar 2013 10:09:27 +0100
> HELO mihamina
> 250 recette53.ideoneov.com Hello localhost [::1]
> MAIL from: 
> 250 OK
> RCPT to: 
> 550 relay not permitted
> 
> 
> mihamina@recette53 ~]$ telnet 127.0.0.1 25
> Trying 127.0.0.1...
> Connected to 127.0.0.1.
> Escape character is '^]'.
> 220 recette53.ideoneov.com ESMTP Exim 4.72 Mon, 11 Mar 2013 10:10:26 +0100
> HELO mihamina
> 250 recette53.ideoneov.com Hello localhost [127.0.0.1]
> MAIL from: 
> 250 OK
> RCPT to: 
> 250 Accepted
> DATA
> 354 Enter message, ending with "." on a line by itself
> From: 
> To: 
> Subject: Haftra Andrana

I'm not a specialist on EXIM, but obviously your system resolves 'localhost' to 
the IPv6 address ::1. 

Probably you have allowed EXIM to relay for 127.0.0.1/8, but not for ::1, so it 
will allow relay access on IPv4 localhost, but not on IPv6 localhost. 

Cheers, 

  Peter.


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

Re: [CentOS] BIND Setup Issue

[Peter Eckel]

On 10.03.2013, at 16:14, Arek Czereszewski  wrote:

> Put this in a zone file:
> netcloudjob.com. IN A 173.201.189.43
> 
> Just after a MX line

Austin already did that, and it doesn't help. 

The name can already be resolved, and the address cannot be pinged either. I 
checked before I replied.

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

Re: [CentOS] BIND Setup Issue

[Peter Eckel]

Hi Austin, 

since your A record is fine and can be resolved, the issue is obviously not 
BIND related but lies somewhere in your network/firewall configuration.

The last address that is visible in the tracereoute output from here is 

> 15  ip-208-109-113-174.ip.secureserver.net (208.109.113.174)  163.811 ms  
> 163.984 ms  164.166 ms

so the issue must be somewhere between 208.109.113.174 and 173.201.189.43. 
Another IP (probably another customer of GoDaddy) in your /24 range is directly 
connected to 208.109.113.174 which makes it likely to be your next hop as well:

> 15  ip-208-109-113-174.ip.secureserver.net (208.109.113.174)  178.314 ms  
> 165.344 ms  165.293 ms
> 16  ip-173-201-189-1.ip.secureserver.net (173.201.189.1)  164.007 ms  163.767 
> ms  163.820 ms


So probably the issue is in your router setup (packet filters and/or NAT, if 
applicable) or in the configuration of your own machine (iptables?).

Regards, 

  Peter.

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

Re: [CentOS] /tmp directory

[Peter Eckel]

Hi Mogens, 

> What is "important"?

valid question. 

I would define 'important' or rather 'valuable' (in a material or non-material 
sense) in terms of reproducability. If it costs you (personal) time, effort or 
money to reproduce them, or if the data are irreprocible to reproduce and might 
be needed later on, /tmp and friends are the wrong place. 

In addition to that, normally /tmp is not a file system that would be backed 
up. No place for production data of any kind. 

> I keep a "yum list >/tmp/yum.lst" in /tmp.
> 
> That's important to me, as I often search for packages.

But it's easily reproducable with one command, even in cron. So it's not what I 
would call 'valuable data'. It's redundant, kind of a cache. 

By the way, what's wrong with 'yum search'? Too slow?

Best regards, 

  Peter.

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

Re: [CentOS] /tmp directory

[Peter Eckel]

On 10.12.2012, at 18:01, Rudi Ahlers  wrote:

> On Mon, Dec 10, 2012 at 6:58 PM,   wrote:
>> Rudi Ahlers wrote:
>> Am 10.12.2012 um 11:22 schrieb John Doe:
>>> From: Jerry Geis 
>>> 
>>> You also have '/var/tmp' that is expected to survive reboots and
>>> should be less often (never?) cleared.
>> 
>> cat /etc/cron.daily/tmpwatch
>> flags=-umc
>> /usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
>> -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
>> -X '/tmp/hsperfdata_*' 240 /tmp
>> /usr/sbin/tmpwatch "$flags" 720 /var/tmp
>> for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do
>>if [ -d "$d" ]; then
>> /usr/sbin/tmpwatch "$flags" -f 720 "$d"
>>fi
>> done
>> 
>> 720 = 30 days
> 
> what? you mean this dir called /var/tmp is actually for temporary
> stuff?? man, this system is seriously screwed up...
>>> 
>>> What else do you use it for?
>> 
>> I think John intended the cmt with 
>> 
>>mark "temporary files are temporary? who'd'a thunk it?"
>> 
>> ___
> 
> 
> Probably. But I've seen people using /tmp to store rather important
> stuff, which is why I asked the question - to get clarity.

Sure. I've  also seen people using the Windows trash can for the very same 
purpose. 

In the IT business, there is a word for that kind of people. We call them 
'stupid'.

Cheers, 

  Peter.

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

Re: [CentOS] Slow login to system without internet connection

[Peter Eckel]

Hi Hakan, 

>  "UseDns no" doesn't  solve the problem because  GSS Api needs reverse 
> lookup.

good point. I disable the GSS API along with some other things in routine 
initial server hardening anyway so this did not occur to me. 

> If (do not need GSS Authentication) then
>   put "GSSAPIAuthentication no" in the host /etc/ssh/sshd_config
> else
>  put your server ip and server name in the client  /etc/hosts
>  "xxx.xxx..xxx yourserver.name"
>  :)

I'd rather put the client IP address in the server's /etc/hosts ...

Best regards, 

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

Re: [CentOS] Slow login to system without internet connection

[Peter Eckel]

Hi Ljubomir, 

> But when I tried to login to my server, it was not instantenous, and I 
> think it was 15+, maybe even 30+ seconds (I forgot to time it) from 
> start of ssh command to password prompt. It is in-house connection, so 
> there is nothing to traceroute.


are you using an external DNS server that is reachable via the internet only?

If so, edit /etc/ssh/sshd_config and change this

  #UseDNS yes

to

  UseDNS no

Then restart sshd and see whether it still happens. sshd tries to look up its 
counterpart's host name using DNS in the default setting, and if DNS is not 
reachable it waits for the request to time out. 

Best regards, 

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

Re: [CentOS] CentOS 6 docs?

[Peter Eckel]

Hi Mark, 

probably you know it, but maybe someone else finds this useful: 

On 07.11.2012, at 19:56, m.r...@5-cent.us wrote:

> Is there somewhere else than  for
> documentation for CentOS 6?



Since the documents available on the CentOS documentation pages are mostly the 
ones for RHEL anyway that shouldn't make too much of a difference. 

Best regards, 

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

Re: [CentOS] OT: Tool for monitoring traffic IP reception

[Peter Eckel]

Hi, 

> Uhmm .. I am reading the docs about SEC, but it only speaks about
> event correlation ... How do you do to check if syslog is receiving
> data??

essentially you set up SEC to watch for the syslog log file where the data are 
supposed to go, set up a 'Single' rule that creates a context with a lifetime 
of your choice that has a shellcmd attached to it that sends a mail if it 
expires. 

The context will be refreshed everytime a message comes in. If no message 
arrives for your given expiry period, it will send a mail. 

You can use this as a sample to start with:

type = Single
ptype= RegExp
pattern  = .*
desc = Heartbeat received
action   = create HEARTBEAT_ACTIVE 720 \
  shellcmd /bin/echo 'Alert!' | /bin/mail -s test 
u...@example.com

Not very sophisticated (and I have not tested it, so it might contain errors), 
but something very similar to it should do the trick. 

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

Re: [CentOS] OT: Tool for monitoring traffic IP reception

[Peter Eckel]

On 30.08.2012, at 11:52, C. L. Martinez wrote:

> I am searching some lightweight tool to control when rsyslog didn't
> receive events from a
> specific host or group of hosts for x minutes/seconds.
> 
> Only a simple tool to send an email when an alert is triggered, I
> don't need flat tools like zabbix or similars.

try SEC: 

SEC can do a lot more, but your requirement can be implemented in a fairly 
simple rule. The tool is rock-solid and I've been using it in a number of 
projects for years.


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

Re: [CentOS] default gateway outside of the LAN

[Peter Eckel]

Hi Boris,

> We have a somewhat unique setup whereby our default router is outside of
> the local network.

'unique' is a very mild expression. The word you're actually looking for was 
probably 'wrong'. 

Your gateway *must* be in the network your interfaces are in. You also would 
not want your living room be built without any doors and a sign on the wall 
'the exit is in the kitchen'. 

Best regards, 

  Peter.

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

Re: [CentOS] leap second

[Peter Eckel]

Hi Les, 

> Interesting, but I thought that ntp clients always advanced the clock
> by small fractions of a second anyway even when the master source
> differs by more.

they do. But the leap second is quite a different thing: Actually the time 
doesn't really diverge from the server's, but the stratum 1 server deliveres a 
totally unexpected 01:59:60, and the stratum 2 server follows. 

The Google approach is not to use that time at all, but slow the clock down a 
bit on the stratum 2 server so that the stratum 1 (that has the 'genuine' time 
and jumps to the :60 time stamp after :59) is, after the time window is over, 
about one second ahead of the stratum 2. So approximately the instant when the 
stratum 1 server jumps from :59 to :60, the stratum 2 server jumps from :58 to 
:59, and at the next second tick, they will both jump to 02:00:00 and be in 
synch again. The same approach works with a negative leap second, which was 
never needed yet, however.

The disadvantage of this method is that you have to know in advance when the 
leap second will happen, which requires tables that regularly have to be 
updated since it is fairly unpredictable in the long run when a leap second 
will be necessary. I don't know why they didn't simply use the 'LI' bit in the 
NTP protocol to determine when to start 'smearing' - at least the article 
doesn't say they did: 



Maybe 24 hours notification in advance did not seem long enough for the smear 
interval. I doubt it, because I would not really like the time to differ from 
the real time for more than a day. 

Best regards, 

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

Re: [CentOS] leap second

[Peter Eckel]

Hi Les, 

> I'm sort of curious about how a bug of this magnitude slips through
> the QA process (into java and RHEL, not CentOS).  With all the furor
> about y2k, did no one even bother to simulate a leap second ahead of
> the real occurrence?

... and leap seconds are not even scarce. According to 
, this was the third one since 2000, 
and it is actually the first time I heard of any problems. 

On the other hand I'm a bit surprised that the problems were comparably few - 
actually there is a time '01:59:60' for one second, and any plausibility check 
I've ever seen assumes that minutes and seconds are in the range from 0..59. 
Wrongly, it seems.

Apparently Google uses an approach that looks much less risky to me - they use 
a time window over which they 'smear' the leap second by making their time 
servers lie about the time for a while, making it pass a little bit slower. 
That way they avoid the unlucky 61st second and still advance the clocks within 
a reasonable time. 



Kind Regards, 

  Peter.


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

Re: [CentOS] leap second

[Peter Eckel]

Hi Keith, 

> My Centos 5.8 box is running ntpd, and I did not notice any 
> problems with it. 

I did not have any problems on CentOS 5.8, but on one CentOS 6.2 box running a 
Java application. 

Kind Regards, 

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

Re: [CentOS] leap second

[Peter Eckel]

Hi Morgens, 

> Some java processes were >100% CPU after the leap second was added.

same problem here ... OpenNMS hat 100% CPU and didn't do anything anymore. 

Rebooting is not necessary, though. For me it worked to just set the time 
manually once, and everything was back to normal. 

It doesn't strike me as a particularly good idea to insert a ':60' second - 
software that does proper sanity checks on date/time values is supposed to barf 
on that. 

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

Re: [CentOS] Resizing est4 filesystem while mounted

[Peter Eckel]

Hi Dennis, 

> The partitioning of the new disk in the guest is important because if you
> use the disk directly as a PV then this PV will also be shown on the host.
> An alternative is to modify the LVM filters in /etc/lvm/lvm.conf on the
> host to specifically not scan the LV for the new disk.
> I find it easier to create a partition though (i.e. use /dev/vda1 instead
> of /dev/vda as the PV).

Thanks for your explanation. Until now I just filteres the guests' PVs on the 
host on the "human interface level" by simply ignoring them, but yours is 
definitely the cleaner and more secure way. 

Maybe I missed something, but in what way is it easier to partition each and 
every LV one wants to use as a PV in a guest than to specify a proper filter in 
/etc/lvm/lvm.conf once? 

I use a consistent naming scheme for the lv's like

  /dev/vg_/lv_virt_

and use the filter 

  filter = [ "r|/dev/vg_\d+/lv_virt_\.*|" ]

to ignore all the guest's PVs. Is there any downside in doing that, or are 
there any advantages in using partitions instead of raw 'devices' for the PVs?

Best regards, 

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

Re: [CentOS] Reject Action For SPF

[Peter Eckel]

Hi Prabh, 

> Thanks for your advice, i actually know this. what would you say about
> those who put there efforts to implement SPF. why they do it?

*if* someone sets up SPF for their domain, SPF works. Among other things, it 
can greatly reduce the amount of backscatter you receive due to spammers using 
your address to send mail. So it's not futile at all, it's just not planned to 
be used the way you intend to do it. 

Which SPF implementation are you using? And on which CentOS release?

Best regards, 

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

Re: [CentOS] Reject Action For SPF

[Peter Eckel]

Hi Prabh, 

> i have setup SPF alright, postfix is performing check as well (results
> below), but even if there is no SPF record exist for a domain, message is
> still accepted.
> 
> how can i set the reject action, if no SPF available.

are you sure you want to do this? It will definitely result in lots of 
legitimate mail being blocked, because SPF is by no means ubiquitous. 

You can set up your mail server to block mail if the SPF record suggests it, 
but I would never filter mail originating from domains having no SPF record at 
all. 

Best regards, 

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

Re: [CentOS] transition to ip6

[Peter Eckel]

Hi Les (sorry for calling you 'Lee' before), 

> What is typical or reasonable for source address restrictions? That
> is, if there are 2 global organizations, and one wants to increase
> the security on access to a service by limiting to the source
> addresses that might come from the other, is there a sane way to
> specify it, and to make the application use those addresses at the
> right times if the interface has others?

In general, all IPv6 addresses on a given interface will have the same network 
prefix, and that will (except in some ... exotic ... cases) be a /64. So 
setting up the address filter on the server side to the whole /64 will make 
most sense. 

When the client has only one interface, that should be all there is to do. When 
it has more than one interface, as Adam previously noted, you'll use routing 
tables to make sure external traffic uses the /64 that is allowed on the 
external server, while internal traffic uses whatever is needed. 

If you are required to use one single address to connect to the external server 
and have only one interface, configuring the software to bind to the permitted 
v6 address will do the trick. It will also use that one for internal traffic, 
but that won't matter as it's on the same /64 as the other addresses on that 
LAN.

I'm not sure how to handle the case where you have one interface with several 
v6 addresses for external traffic and one or more interfaces for internal 
traffic and have to use one specific address on the external interface because 
of single-address restrictions on the external server. I'd say, either don't do 
it (filter on /64 instead), or remove all addreesses but the one required from 
the external interface and let routing tables handle the rest. 

Bests, 

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

Re: [CentOS] transition to ip6

[Peter Eckel]

Hi Stephen, 

> *gigglefit*
> 
> One of my providers gave me a single(!) IPv6 address.

Actually that's at least something the IETF has thought of ... if it is certain 
that one and only one device will be connected. I'm not actually sure what use 
case there is for such a connection, but at least it is a possibility mentioned 
in RFC 3177:

   This document provides recommendations to the addressing registries
   (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address
   blocks to end sites.  In particular, it recommends the assignment of
   /48 in the general case, /64 when it is known that one and only one
   subnet is needed and /128 when it is absolutely known that one and
   only one device is connecting.

> Another one has subdivided a /64 into multiple /96's (one for each customer).

Yuck. That doesn't make sense at all. 

SLAAC won't work, Privacy Extensions won't work ... you're stuck with static 
addresses that way, which kills a big part of the ease of management IPv6 could 
provide, if used properly.

What are they trying to do? Save IPv6 address space? :-)

OK, 3177 is just a recommendation, but when you look at the schemes after which 
SLAAC und PE addresses are generated, anything less than /64 (except, in rare 
circumstances, /128) is just bull.

> You might want to rethink the /64 concept!

I think you might want to rethink the choice of your provider. 

Bests, 

  Peter.

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

Re: [CentOS] transition to ip6

[Peter Eckel]

Hi Lee, 

> So what does that mean for a client application (http/ftp,etc.) where
> you might have local firewalls permitting things for internal-subnet
> source ranges but you also have external targets that only accept
> pre-configured static sources?

Are you referring to the situation where you have several clients on the 
internal network that use NAT to appear as one single IPv4 host to an external 
server, which allows access based on that global outside NAT address?  

The situation is a bit different without NAT. Instead of filtering on a single 
IPv4 address the external server would filter on a /64 IPv6 network. 
Security-wise there is no difference as you'll never get smaller allocations 
than /64 per site anyway, so what with respect to filtering was was a single 
IPv4 address with IPv4/NAT is a /64 subnet with IPv6: A unique identifier of 
the network connecting to the external server. Both with IPv4/NAT and IPv6 the 
server only knows which network you are coming from, not which specific host is 
trying to connect. 

When there really is a requirement that the external server allows only a 
single address to access it and that can't be changed, you could resort to 
using a proxy. 

If you're interested, RFC4864 expands on some of the aspects of IPv4/NAT vs. 
IPv6: 

Best regards, 

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

Re: [CentOS] transition to ip6

[Peter Eckel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Adam, 

> Typically the routing table does a lot of work.   Much like 127.0.0.0/8
> the mask of a link-local will make it unprefered by 'public' traffic.
> There is also a syntax for specifying the outbound interface for
> traffic.

Routing tables won't do much for you when you have several different IP 
addresses (stateless autocnfigured, privacy extension and static) within the 
same network on the same physical interface - they'll all use the same route. 
The longest match algorithm would more or less lead to a random choice of 
source addresses. 

If you want a specific source address to be used, you have to specify it ... no 
big deal, though. bind() hasn't changed that much. 

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk95f18ACgkQ+8TW1Xhd1gdMEgCeLlhgwWa5v29cCJGuVS0IN1C+
5UAAoPQv4sw9HHeXe4JISW8jhsS0vtJy
=6E3z
-END PGP SIGNATURE-
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] transition to ip6

[Peter Eckel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Adam, 

> You can explicitly turn in off on every type of client.  Then wait till
> you want to do it.

agreed. The problem is that you can, and you actually *must* do it. Doing 
nothing leaves v6 on by default on most modern operating systems. 

> False.  The same firewall rules will apply as before

Unfortunately, this is only theoretically true. 

> [and NAT isn't psuedo-security - NAT IS *NOT* *NOT* *NOT* A SECURITY
> FEATURE; please, let's not have to go over that again].

That's the meaning of 'pseudo', isn't it? :-)

> Your DOCSIS IPv6 capable black-box will apply the same filters to IPv6
> traffic that it does to IPv4 traffic.  As will you Vista and Windows 7
> workstations.

I'm not talking about host-based packet filtering. Turn on IPv6 on a Cisco box, 
for example, and none of your packet filters will affect IPv6 traffic. Lots of 
home/small business routers show the same behaviour, except that you don't even 
have to turn on IPv6 routing, it's on by default. 

> There is no such thing as "NAT security" for them to rely on.  If that
> is their security model the administrator is incompetent and should be
> fired immediately.

Agreed. 

>> be completely exposed to the Internet without any protection,
> 
> False.

No. See above.

>> and the bad thing is that you just don't have to do anything to make
>> it 'work'. From one day to the other, IPv6 connectivity will be there
>> and most people won't even notice until it's too late. 
> 
> Or they won't notice and have nothing more to worry about than they did
> before.

Not if they either rely on NAT (which *many* home users do - and they are the 
security problem with respect to Botnets, not properly managed networks like 
yours and mine.

> Well, don't worry.  Because that is exactly what happens.  An IPv6
> stateful firewall is just as effective as an IPv4 stateful firewall.

Yes, as long as it's there. 

> Most just consumer routers simply mirror the IPv4 and IPv6 filters.  If
> you have a managed network with 'real' routers your administrators have
> probably already done that; if you are unsure - ask them.

I don't have to, as my introduction of IPv6 was some years ago. Telling people 
to just sit and wait is the worst you can do - at least I woudldn't trust a 
'black box' router as far as I can throw it to actually implement v6 filter 
rules, especially since many of them are fairly old and not on the latest 
firmware level. 

Best regards, 

  Peter.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk95e5YACgkQ+8TW1Xhd1geRyACeKimmjPrrrYtSee/wNJmLP1NZ
k9gAoI8yGvEeVmfjXtqeEqMHx6PfrTUv
=kus4
-END PGP SIGNATURE-
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] transition to ip6

[Peter Eckel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Adam, 

> Or you assign the rule to the interface, rather than the address.
> Nothing new, that is how firewalls work on DHCP clients today.

that will be pretty difficult on the perimeter router ... 

Best regards, 

  Peter.

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk95eW0ACgkQ+8TW1Xhd1gcSXACg0Sculr5FUZ1yQxIHp581r0Gi
musAnRUVVMVav2HBKmQuK6IDmVY98jrt
=Fazc
-END PGP SIGNATURE-
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] transition to ip6

[Peter Eckel]

Hi Lee, 

> How do applications choose the correct outbound address in that
> scenario?  That has always been a problem when using multiple ipv4
> addresses on the same interface in combination with firewalling, etc.
> where the source address matters.

that problem hasn't changed too much from IPv4 to IPv6. Basically, it's up to 
the application which IP address it binds to, while the OS should provide 
sensible defaults. In most cases with Privacy Extension enabled (mostly on 
client systems), the system should use a PE address, ideally a different one 
for each connection. Outgoing addresses for servers must be configured, e.g. in 
Postfix it's in the 'smtp_bind_address6' configuration variable, in BIND 
'query-source-v6'. 

The functionality is there (as it was with v4), applications just have to use 
it. It is, however, a more pressing issue as with v6 any interface is likely to 
have several addresses. The generic case for an interface's addresses is:

- link-local address, starting with 'fe80::' and ending with a node part that 
has been derived from the MAC of the interface for communication with the local 
network

- autoconfigured address, starting with your prefix and ending with the same 
node part as the link-local address (i.e., derived from the MAC)

- Privacy Extension address, starting with your prefix and ending with a random 
node part (it's likely that there are several of them, as a rollover mechanism 
exists for address rotation)

- Static addresses, starting with your prefix and ending with a user-chosen 
node part for specific services (there might me several of them as well)

All of them may co-exist. The normal logic for outgoing address selection is to 
use a PE address if there is one and the autoconfigured address (if present) 
otherwise (OK, that's as is *should* be, and most of the time it is). 
Everything else is up to you and how the software you use binds to outgoing 
addresses and lets you specify it.

Best regards, 

  Peter. 

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

Re: [CentOS] transition to ip6

[Peter Eckel]

Hi Lee, 

> If the addresses are auto-discovered, how are you supposed to be able to 
> configure filtering rules for what you want to let through?

very simply. 

1. Each interface on an IPv6 enabled machine has several addresses. One of them 
is the autoconfigured address, one is the (a) Privacy Extension address, and 
then you can still configure addresses manually. Obviously the latter method is 
the right choice for servers.

2. Except for the Privacy Extension address(es), auto-configured addresses are 
static (although virtually unmemorisable) as long as the prefix and the host's 
MAC address are. So there is a static address that you can put into your DNS 
and configure on your firewall. 

Best regards, 

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

Re: [CentOS] transition to ip6

[Peter Eckel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Adam, 

> And recent computer or distributions is sitting their quietly waiting
> for it's IPv6 address to arrive - probably automatically, via auto
> discovery.  Clients are trivial.

... and that is EXACTLY the biggest problem with IPv6. 

'Introducing' IPv6 happens automatically in most cases, and inadvertently as 
well. The moment ISPs will start supporting IPv6 for their customers will be a 
security nightmare, because IPv6 firewalls will not be configured on most 
networks, and the pseudo-security of NAT will no longer be in effect. 

In fact, a very large number of networks (especially those currently relying on 
NAT 'security') will be completely exposed to the Internet without any 
protection, and the bad thing is that you just don't have to do anything to 
make it 'work'. From one day to the other, IPv6 connectivity will be there and 
most people won't even notice until it's too late. 

One may only hope that home router manufacturers will deliver standard 
configurations with all incoming IPv6 traffic (except answers to outgoing 
packets, obviously) blocked by default, but I'm not very optimistic :-(

So, before you do anything else, set up proper incoming and outgoing IPv6 port 
filtering rules on your perimeter routers. It will save you a hell of a 
headache. 

  Peter.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk93AW4ACgkQ+8TW1Xhd1gcs+ACdGuX1d+0tB9BCh29oH/qJYli7
1rMAoLgnYPcgz3H73kot9sONNjmXOc8C
=TjFi
-END PGP SIGNATURE-
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] your advice on backup procedure

[Peter Eckel]

Hi Bob, 

I just want to to throw in another alternative to make choice harder ... :-)

> The scenario...
> centos server acting as a virtual host. Virtual machines are webservers 
> and dns servers. All on one machine, all running centos 6.
> Virtual machines are kvm, sitting in lvm storage.

My basic setup is quite similar to yours. CentOS 5 machine working as host, 
several virtual CentOS 5/6 boxes on that host, but additionally there are some 
Mac OS X and Ubuntu boxes around that also need to be backed up, some of them 
in remote locations. 

I have a NAS drive set up in my small datacenter that works as an iSCSI host 
and serves a LUN for backups. The virtual host machine runs Bacula dir and sd, 
with the backup volumes on the LUN. All Clients run bacula fd and connect to 
the server, the ones connecting from the internet use SSL encryption and 
certificate authentication. I run full backups once a week, and daily 
incrementals. 

For the last half year or so, the solution has proven rock-solid, not a single 
failure. I had to restore several files during that period, and there wasn't 
any problem at all with that as well. 

Database backup is done using pre-scripts that perform a database dump and then 
back up that dump, which is a bit of a downside as other solutions often have 
database backup plugins, but nothing that could not be solved. After initial 
setup, configuration is done on the Bacular directory server alone, which saves 
some amount of maintenance. Backup strategies can be defined in a very flexible 
way, too. 

There also is a feature that allows you to define a base system (e.g. a freshly 
installed CentOS box) and tell the server just to back up differences from that 
base system, saving large amounts of storage if you have many similar machines 
to be backed up. 

Best regards, 

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

Re: [CentOS] getting yum-cron to send a mail

[Peter Eckel]

Hi Bob, 

it is set up in /etc/sysconfig/yum-cron (/etc/sysconfig generally is a good 
place to look for this kind of thing).

MAILTO is set to your desired mail address. I also set ERROR_LEVEL to 1 to get 
a mail when something was installed by yum-cron - the default setting will only 
send mail on error. 

Works like a charm, and there also is some amount of documentation about all 
the options in the file. 

Best regards, 

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

Re: [CentOS] Local privilege escalation bug in kernel

[Peter Eckel]

Hi Frank, 

> Do we know if this bug affects Centos?
> 
> http://www.techworld.com.au/article/413300/linux_vendors_rush_patch_privilege_escalation_flaw_after_root_exploits_emerge
> 
> The article states that it affects kernel 2.6.39 and above, but since RH
> backports so much stuff I'm not sure if this would actually include the Centos
> kernels.

I did a quick check using the 'mempodipper' demo exploit on CentOS 5.7 and 
CentOS 6.2. Currently it doesn't seem to affect either. 

On CentOS 5.7 it just hangs, on 6.2 it finishes without dropping me in a root 
shell. So at first sight it seems CentOS is not affected. 

Best regards, 

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

Re: [CentOS] sshd: listen on ip1:port1 and ip2:port2

[Peter Eckel]

Hi Eero, 

> How about using iptables to forward 443 to 22? I think it is the
> simplest way to do this hack.

no, the simplest way is to tell sshd on which port to listen on each interface. 
Which is extremely straightforward.

Redirecting ports to other ports IMHO is neither particularly simple nor 
maintenance-friendly ... don't do it unless there really is no other way, or 
the next guy who has to figure out in a hurry what the system does will really, 
really hate you ... :-)

Best regards, 

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

Re: [CentOS] sshd: listen on ip1:port1 and ip2:port2

[Peter Eckel]

Hi Fabien, 

> In order to do so, you just need to add in /etc/ssh/sshd_config:
> Port 22
> Port 443
> 
> Then reload the ssh service.

that will lead to sshd listening on both ports for both interfaces, so it's not 
what Alex needs. 

Best regards, 

  Peter.


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

Re: [CentOS] sshd: listen on ip1:port1 and ip2:port2

[Peter Eckel]

On 24.01.2012, at 13:23, Alexander Farber wrote:

> I'd like SSHd to keep listening at the_old_ip:22 but also at the_new_ip:443.

# man sshd_config:

 ListenAddress
 Specifies the local addresses sshd should listen on.  The 
following forms may be used:

   ListenAddress host|IPv4_addr|IPv6_addr
   ListenAddress host|IPv4_addr:port
   ListenAddress [host|IPv6_addr]:port

 If port is not specified, sshd will listen on the address and all 
prior Port options specified.  The
 default is to listen on all local addresses.  Multiple 
ListenAddress options are permitted.  Addition-
 ally, any Port options must precede this option for non port 
qualified addresses.

# grep ListenAddress /etc/sshd/sshd_config:

ListenAddress 127.0.0.1:443
ListenAddress 192.168.42.182:22

# netstat -antup | grep sshd

tcp0  0 192.168.42.182:22   0.0.0.0:*   LISTEN  31585/sshd  
tcp0  0 127.0.0.1:443   0.0.0.0:*   LISTEN  31585/sshd  

Best regards, 

  Peter.

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

Re: [CentOS] DNS and Reverse Adresses

[Peter Eckel]

Hi Götz, 

> My question: dose maybe someone forgot the 192.168.200.x reverse zone
> files and config

probably. 

> and can I just create a file like that for the 172.17
> hosts and adding the config for the reverse zone to my named.conf?

Yes, *if* you either have the only DNS in your network (not a hierarchically 
lower level that gets its domains delegated from the next higher level) or the 
200.168.192.in-addr.arpa domain has been delegated to you. Having the authority 
over the 'domainname.de' domain and hostnames that resolve to 192.168.200.x 
addresses does not automatically mean that you have authority over the said 
reverse lookup domain as well. 

You can check whether some other name server resolves 192.168.200.x addresses 
by entering 

  dig -x 192.168.200.x

If you get NXDOMAIN, there is probably either more mis-configuration around 
(happens frequently in my experience), or there actually is no other server 
that could provide reverse lookup. You can also try to check the delegation of 
the 200.168.192.in-addr.arpa address by issuing the command 

  dig 200.168.192.in-addr.arpa NS

The pointers you get in return (if any) should give you an indication whether 
you have authority to resolve reverse lookups for 192.168.200.x addresses.

Again, if yours is/are the only or main authoritative DNS server(s) in the 
(internal) network, these considerations do not apply.  

Viele Grüße, 

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

Re: [CentOS] vmware fusion display auto-size problem

[Peter Eckel]

Hi Monty, 

> Which repository did you get the above drivers from?  I have base and cr 
> enabled on my box.

they are from @base. 

I doubt that the VMware Tools installer installs them at all. Possibly without 
a current version of the VMware tools the CentOS installation process doesn't 
recognise it runs on a VMware instance, and so the drivers don't get installed. 
Just a wild guess, though.

Cheers, 

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

Re: [CentOS] vmware fusion display auto-size problem

[Peter Eckel]

Hi Monty, 

> I am running vmware fusion 4.1.1 on a OSX host.

Same here.

> Centos6.2 is a guest. 

Same here.

> The box is a macbook laptop running leopard.

OK, there's a difference - I have a Mac Pro running Snow Leopard. But that 
shouldn't make a difference.

> Before upgrading to 6.2, the display auto-resize (or auto-fill) was 
> working fine. After 6.2, it has stopped working.

Works here. 

> Centos is fully updated to 6.2.

Same here. 

> I have tried to install the vmware  drivers from the repository (via yum),
> and yum reports I have the latest. Vmware reports I have the latest
> version of app and linux tools.

My current versions are: 

  xorg-x11-drv-vmware.x86_64 11.0.3-1.el6 
  xorg-x11-drv-vmmouse.x86_6412.7.0-1.el6
  xorg-x11-drv-vmware.x86_64 11.0.3-1.el6

VMware Tools version is: 

  VMware-Tools-8.8.1-528969

This is the version that was downloaded by Fusion after the upgrade to 4.1.1. 

> I have uninstalled and re-installed vmware tools to no avail.  During 
> the vmware tools install it returns a statement that it does not have 
> drivers for x:

I get the statement that it does not install X drivers since there are drivers 
installed by the distribution, but resizing works fine, so the drivers should 
be up-to-date.
  
  Detected X server version 1.10.4
  Distribution provided drivers for Xorg X server are used.
  Skipping X configuration because X drivers are not included.

> Anybody else come across this?  Google and vmware sites either do not 
> have any info, or I am asking the wrong question.
> 
> This being my first foray into vmware, is it advisable not to run 
> updates until needed?  What is best practice in this config?

I usually install all updates provided by CentOS (the VMs I run on Fusion are 
mostly test systems). From time to time, there are kernel updates that are not 
compatible with VMware Tools, but usually a reconfiguration (with installed 
gcc/required libs/kernel headers) fixes that. It's also possible to enable 
'VMware automatic kernel modules', an experimental feature of VMware Tools, 
that should automate that process. You can enable it by re-running 
vwmware-install.pl or running /usr/bin/vmware-config-tools.pl
 
HTH, 

  Peter.


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

Re: [CentOS] what percent of time are there unpatched exploits against default config?

[Peter Eckel]

Hi Marko, 

> Using the ssh key can be problematic because it is too long and too random to 
> be memorized --- you have to carry it on a usb stick (or whereever). This 
> provides an additional point of failure should your stick get lost or stolen.

this is only correct when you use SSH keys without a sufficiently secure 
passphrase. Which you obviously should never do. If you have a passphrase with 
your key, finding or stealing the USB stick is completely useless, and even if 
someone gets at your key, your no worse off than with password authentication. 

> Human brain is still by far the most secure information-storage device. :-)

I strongly disgree. Social engineering is a very efficient way to get at other 
people's data.

> It is very inconvenient for people who need to login to their servers from 
> random remote locations (ie. people who travel a lot or work in hardware-
> controlled environment).

Agreed.

> Besides, it is essentially a question of overkill. If password is not good 
> enough, you could argue that the key is also not good enough --- two keys (or 
> a larger one) would be more secure. Where do you draw the line?

One key is indefinitely better than a password. The additional security you 
gain when you add another key is, however, disputable. 

Best regards, 

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

Re: [CentOS] Latest yum update cr (6.1?)

[Peter Eckel]

Hi, 

> Is anyone else seeing this ?
> [...]
> --> Running transaction check
> ---> Package perl-CGI.x86_64 0:3.51-119.el6_1.1 will be installed
> http://mirror.centos.org/centos/6/cr/x86_64/repodata/21176588c0c317c0b6933f0c0d113263fbb2ff3f6f7bff60cbdff730a38c1db4-filelists.sqlite.bz2:
>  [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404"
> Trying other mirror.
> Error: failure:
> repodata/21176588c0c317c0b6933f0c0d113263fbb2ff3f6f7bff60cbdff730a38c1db4-filelists.sqlite.bz2
>  from cr: [Errno 256] No more mirrors to try.


I don't know whether it relates to the same problem, but I couldn't properly 
upgrade a system running 6.0 + CR that wasn't at the latest patch level when 
6.1 came out. Lots of messages like the one you showed. 

The solution was to temporarily disable the centos-release-cr repo, then 
upgrade, then re-enable CR again:

  yum remove centos-release-cr
  yum update
  yum install centos-release-cr

I assume the reason is that the CR repo for 6.0 has been pulled with release of 
6.1 whith the catalog still in place. 

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

Re: [CentOS] When will 6.2 be released.

[Peter Eckel]

Hi Louis,

> come on Johnny, there are still plenty of people that appreciate the
> work you guys do and are happy to see 6.1 released. Please give us first
> a chance to say "thank you so much!"

Indeed, and since I omitted that in my last post (I probably was too busy 
chuckling), I'd like to chime in here. From what little seeped through to the 
outside, this time it was a Herculic task to keep up with upstream, and they 
did it - again. 

Thank you very much, all of the team. 

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

Re: [CentOS] When will 6.2 be released.

[Peter Eckel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Johnny, 

> Let's go ahead and get this flame thread started now to save time.
> 
> The CentOS team sucks ... it took  days to do 6.1 ... it is going to
> take twice as long to get 6.2
> 
> My mom said CentOS blows.
> 
> kbsingh is ugly.
> 
> hughesjr is old and fat.
> 
> OK ... that should do.

OK, thanks. A simple '6.1 has been released' would have done, though :-)

Cheers, 

  Peter.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk7jRMgACgkQ+8TW1Xhd1gdQpgCgr/V8vNb9TJIgI6ScwZsrScUn
AA8An0YGvp0csjKj8NDxiMDy0ogb4/dZ
=tApB
-END PGP SIGNATURE-
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] 6.1 .iso size?

[Peter Eckel]

Hi John, 

On 03.12.2011, at 23:25, John R Pierce wrote:

> On 12/03/11 2:11 PM, Beartooth wrote:
>> I don't have that kind of access to any http server.
> 
> in a pinch, enable IIS on a windows system.  its a bit funky, but it 
> works just fine for this sort of thing.  or any linux box, you could 
> install httpd on.

... or any Mac OS X box, which come with httpd installed. That's what I do with 
my Xen installations. 

Cheers, 

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

Re: [CentOS] Centos v3.3 CD 2

[Peter Eckel]

Hi Jonathan, 

> wouldst thou be willing to divulge thy mail client and/or plugin which
> spake in such a manner?

thou shalt read the headers:

> Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/2005 Thunderbird/8.0


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

Re: [CentOS] Centos 6 - named with internal zone file and forwarding

[Peter Eckel]

Hi Giles,

Am 23.10.2011 um 13:18 schrieb Giles Coochey :

> ugg
> ... turns out I had a rather embarassing typo in named.conf... it all works 
> now.

that tends to happen pretty easily, I know. When I do changes to the BIND 
configs, I made a habit of using named-checkconf/named-checkzone every time and 
also checking the log after restarting the daemon.

It's still no sure-fire remedy, but it helps a lot.

Cheers,

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