Re: [CentOS] Ad integration with centos 6

[dnk]

On Wednesday, December 28, 2011, James A. Peltier  wrote:
> - Original Message -
> | Hi Alain,
> |
> | I had tried that tutorial, and had issues with that one as well. I
> | obviously was missing something when I tried it.
> |
> | I actually got my machine in AD using likewise open. It works quite
> | well,
> | with minimal config.
> |
> | I appreciate the pointers though!
> |
> | D
>
> Now try diagnosing the problem when you have no idea what LWO did or
continues to do to make things work.  We had a great deal of problems with
LWO.  It was a cinch to set up but debugging it quickly became tedious
because troubleshooting a system we didn't understand how all the pieces
fit together was met with, well, pain.  Quite often it was easier to just
re-install the node then try to troubleshoot why something wasn't working.
 At least, that's my experience.
>
> --
> James A. Peltier
> Manager, IT Services - Research Computing Group
> Simon Fraser University - Burnaby Campus
> Phone   : 778-782-6573
> Fax : 778-782-3045
> E-Mail  : jpelt...@sfu.ca
> Website : http://www.sfu.ca/itservices
>  http://blogs.sfu.ca/people/jpeltier
> I will do the best I can with the talent I have
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>

Those are very valid points. I just was able to get this setup, where as I
couldn't get the others.

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

Re: [CentOS] Is Biarch with 6.x now dead?

[Michael Lampe]

John R Pierce wrote:

> who says he's building system packages?I got the impression he's
> building his own applications, stuff that typically runs in $HOME rather
> than /usr or whatever.

Exactly. Wasn't that clear from the very beginning?

-Michael


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

[CentOS] asus-wmi.ko for Asus G73Sw running CentOS 6.2

[Rob Kampen]

Hi List,
Just loaded our favorite OS onto my new ASUS laptop.
Practically everything worked out of the box - I used the live DVD to 
check things out and installed from there.
I have followed
http://forum.notebookreview.com/asus-gaming-notebook-forum/553474-g73-asus-wmi-linux-driver-i-need-your-help-6.html
to get suspend working and also to get function keys working for LCD 
screen backlight controls working (Fn F5 and Fn F6).
Upon further searches I find that there is a kernel module asus-wmi.ko 
available in some distros that also allows some of the other Asus 
functions to operate - of particular interest is the keyboard backlight 
(Fn F3 and Fn F4) as well as the master backlight on/off key to function.

Question, does anyone know where and how to locate this (asus-wmi.ko) 
and get it functioning under CentOS 6.2?

I am prepared to set up the required build environment - but need some 
assistance as this is really at the limits of my experience. I have 
rebuilt the kernel to remove patches with some success previously and 
will have to dust off this knowledge if required.

TIA

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

Re: [CentOS] Ad integration with centos 6

[James A. Peltier]

- Original Message -
| Hi Alain,
| 
| I had tried that tutorial, and had issues with that one as well. I
| obviously was missing something when I tried it.
| 
| I actually got my machine in AD using likewise open. It works quite
| well,
| with minimal config.
| 
| I appreciate the pointers though!
| 
| D

Now try diagnosing the problem when you have no idea what LWO did or continues 
to do to make things work.  We had a great deal of problems with LWO.  It was a 
cinch to set up but debugging it quickly became tedious because troubleshooting 
a system we didn't understand how all the pieces fit together was met with, 
well, pain.  Quite often it was easier to just re-install the node then try to 
troubleshoot why something wasn't working.  At least, that's my experience.

-- 
James A. Peltier
Manager, IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone   : 778-782-6573
Fax : 778-782-3045
E-Mail  : jpelt...@sfu.ca
Website : http://www.sfu.ca/itservices
  http://blogs.sfu.ca/people/jpeltier
I will do the best I can with the talent I have

___
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?

[Craig White]

On Wed, 2011-12-28 at 00:40 -0700, Bennett Haselton wrote:
> On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Foster  wrote:

> > What was the nature of the break-in, if I may ask?
> >
> 
> I don't know how they did it, only that the hosting company had to take the
> server offline because they said it was sending a DOS attack to a remote
> host and using huge amounts of bandwidth in the process.  The top priority
> was to get the machine back online so they reformatted it and re-connected
> it, so there are no longer any logs showing what might have happened.
> (Although of course once the server is compromised, presumably the logs can
> be rewritten to say anything anyway.)

the top priority was to get the machine back online?

Seems to me that you threw away the only opportunity to find out what
you did wrong and to correct that so it doesn't happen again. You are
left to endlessly suffer the endless possibilities and the extreme
likelihood that it will happen again.

It shouldn't have taken more than 2 hours to figure out how they got in.

Next time - have them buy or ship them an external drive and have them
do a dd copy of your hard drive to the external drive so you have an
exact copy of the drive before you reformat/re-deploy.

> > Security is more than just updates and a strong password.

> Well that's what I'm trying to determine.  Is there any set of default
> settings that will make a server secure without requiring the admin to
> spend more than, say, 30 minutes per week on maintenance tasks like reading
> security newsletters, and applying patches?  And if there isn't, are there
> design changes that could make it so that it was?
> 
> Because if an OS/webserver/web app combination requires more than, say,
> half an hour per week of "maintenance", then for the vast majority of
> servers and VPSs on the Internet, the "maintenance" is not going to get
> done.  It doesn't matter what our opinion is about whose fault it is or
> whether admins "should" be more diligent.  The maintenance won't get done
> and the machines will continue to get hacked.  (And half an hour per week
> is probably a generous estimate of how much work most VPS admins would be
> willing to do.)
> 
> On the other hand, if the most common causes of breakins can be identified,
> maybe there's a way to stop those with good default settings and automated
> processes.  For example, if exploitable web apps are a common source of
> breakins, maybe the standard should be to have them auto-update themselves
> like the operating system.  (Last I checked, WordPress and similar programs
> could *check* if updates were available, and alert you next time you signed
> in, but they didn't actually patch themselves.  So if you never signed in
> to a web app on a site that you'd forgotten about, you might never realize
> it needed patching.)

please excuse my impertinence but it seems as though you want everyone
on the list to indulge in your speculation of the myriad of
possibilities for your servers lack of security when you deliberately
chose not to conclusively determine the problem.

As for the time needed to maintain a VPS, It sounds like you are
reselling shares of co-located servers to others... good luck with that.

Craig


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Re: [CentOS] Is Biarch with 6.x now dead?

[Michael Lampe]

Les Mikesell wrote:

> You _can_ cross-compile code for a whole bunch of different
> environments.  That doesn't make it a particularly good idea, even if
> it does happen to be fairly easy in this one particular case.  How
> many cases do you want to support?

Exactly this one. The only relevant case. Fully supported by TUV for a 
good reason. And by the CentOS credo, it'll be here, too! It must be! It 
is! Whew!

(And nobody has compiled the apps on my Android on his! Even if it's now 
possible to install Debian on Android!)
___
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?

[Craig White]

On Wed, 2011-12-28 at 07:43 -0600, Johnny Hughes wrote:

> There have been NO critical kernel updates.  A critical update is one
> where someone can remotely execute items at the root users.
> 
> Almost all critical updates are Firefox, Thunderbird, telnetd (does
> anyone still allow telnet?), or samba (never expose that directly to the
> internet either :D).  There was one critical issue on CentOS-5.x for exim:
> 
> http://rhn.redhat.com/errata/RHSA-2010-0970.html
> 
> All the other issues (non-critical) will require the user to get a "user
> shell" and then elevate their privileges some way

perhaps he is referring to RHSA 2011:1245
http://lists.centos.org/pipermail/centos/2011-September/118075.html

which CentOS was very slow in getting the update out the door but as you
said, it was labeled 'important' and not 'critical'  and of course
concerned apache and not kernel.

Craig


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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?

[Les Mikesell]

On Wed, Dec 28, 2011 at 5:01 PM, Timothy Murphy  wrote:
>>
>> Running your own server is not like using a toaster.  It requires
>> someone with a detailed level of knowledge to install and maintain it.
>
> What about home servers?

Are they exposed to inbound internet traffic?  If so, expect people
who are smarter and more experienced than yourself to attempt to hack
in, even if only with fully automated schemes.

> It seems to me that these are bound to become more popular
> as more devices with IP addresses (Smart TV's and phones, etc)
> get linked into home systems.

They don't need to be directly accessible from the internet.   Most
would be behind a NAT router that only allows outbound access.

> I guess the person in the home running one of these
> is a System Administrator.
> Or maybe there should be a new title, Home System Administrator.
>
> I run CentOS on a couple of small home servers (one remotely),
> and wouldn't claim to have any deep knowledge of the subject.
> I usually find the gurus on this newsgroup solve any problems I have!

There are distributions targeted to the SOHO or even home environment.
 Look at SME server or ClearOS - that basically have the same
components as CentOS but come up working with most needed services
running and configurable with a simple web interface.

-- 
Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Is Biarch with 6.x now dead?

[Les Mikesell]

On Wed, Dec 28, 2011 at 5:13 PM, Michael Lampe
 wrote:
>
> Stuttgarts former top class machine is running CentOS 5. I never tried
> the 32-bit feature there myself, because my code _is_ 64-bit clean. But
> I would have been pissed if ...

You _can_ cross-compile code for a whole bunch of different
environments.  That doesn't make it a particularly good idea, even if
it does happen to be fairly easy in this one particular case.  How
many cases do you want to support?

-- 
  Les Mikesell
lesmikes...@gmail.com
___
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?

[Craig White]

On Wed, 2011-12-28 at 13:47 +0900, 夜神　岩男 wrote:

> With the vast majority of web applications being developed on frameworks 
> like Drupal, Django and Plone, the overwhelming majority of "server 
> hacks" with regard to the web have to do with attacking these structures 
> (at least initially), not the actual OS layer directly at the outset.

just a mention that ruby on rails just changed the methodology with
version 3.x in that all displayed code is automatically escaped and you
have to designate beforehand anything that you want to be evaluated as
html/script which is a significant bump in security.

Craig


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Re: [CentOS] unable to initialize epel6 chroot in centos 5.7

[Jason Wee]

On Thu, Dec 29, 2011 at 9:03 AM, Karanbir Singh wrote:

> On 12/29/2011 01:00 AM, Jason Wee wrote:
> > Greetings,
> >
> > I have a centos 5.7 (2.6.18-274.12.1.el5) server with mock
> > (mock-1.0.25-1.el5) installed. When initialize epel-6 chroot in centos
> 5.7
> > it failed, below are the snippet of error in the terminal output,
> 
> > srpm in C5 mock for C6 or is there a fix for this?
>
> yes, ideally that involves porting the rpm from c6 back to c5 ( and then
> you have some strange issue potential for c5 builds on the machine ).
>
> hmm.. yes, example rebuilding the srpm of C6 in C5 chroot where it depend
on another library which have different version which will give strange
issue
or surprise result later. The safety and functional option for now is to
install
a C6 server and initialize the epel-6 chroot for it?


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

Re: [CentOS] unable to initialize epel6 chroot in centos 5.7

[Karanbir Singh]

On 12/29/2011 01:00 AM, Jason Wee wrote:
> Greetings,
> 
> I have a centos 5.7 (2.6.18-274.12.1.el5) server with mock
> (mock-1.0.25-1.el5) installed. When initialize epel-6 chroot in centos 5.7
> it failed, below are the snippet of error in the terminal output,

> srpm in C5 mock for C6 or is there a fix for this?

yes, ideally that involves porting the rpm from c6 back to c5 ( and then
you have some strange issue potential for c5 builds on the machine ).

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

[CentOS] unable to initialize epel6 chroot in centos 5.7

[Jason Wee]

Greetings,

I have a centos 5.7 (2.6.18-274.12.1.el5) server with mock
(mock-1.0.25-1.el5) installed. When initialize epel-6 chroot in centos 5.7
it failed, below are the snippet of error in the terminal output,

...
...
rpmlib(PayloadIsXz) is needed by mingetty-1.08-5.el6.x86_64
rpmlib(FileDigests) is needed by popt-1.13-7.el6.i686
rpmlib(PayloadIsXz) is needed by popt-1.13-7.el6.i686
rpmlib(FileDigests) is needed by findutils-4.4.2-6.el6.x86_64
rpmlib(PayloadIsXz) is needed by findutils-4.4.2-6.el6.x86_64
(1, [u'Please report this error in
https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%205&component=yum'
])

DEBUG: kill orphans
[jason@example ~] $

I've tried clean and reinitialize the chroot but it failed. Google for this
issue and mailing list only result in failed to build rpm in C5 from C6
(which is opposite of this). Has anyone successfully initialize or build
srpm in C5 mock for C6 or is there a fix for this?

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

Re: [CentOS] Is Biarch with 6.x now dead?

[Michael Lampe]

Reindl Harald wrote:

> on  a clean environment $HOME does not contain software
> this is the apple-way having binaries running where your user
> have write-access and from the viewpoints of security and
> modern system-managment worst practice

The three Federal Computing Centers in Germany (Juelich, Stuttgart, 
Munich -- with Stuttgart now hosting Germany's largest Supercomputer to 
date) all work in this way. How else should they? Most of the codes are 
developped by the users themselves, they are updated regularly -- and 
they do contain bugs (64-bit bugs, e.g.) ...

Stuttgarts former top class machine is running CentOS 5. I never tried 
the 32-bit feature there myself, because my code _is_ 64-bit clean. But 
I would have been pissed if ...
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Is Biarch with 6.x now dead?

[Reindl Harald]

Am 29.12.2011 00:01, schrieb John R Pierce:
> On 12/28/11 2:54 PM, Reindl Harald wrote:
>> do what you believe and let us look where you end in 5-6 years
>> after doing a couple of updates with "./configure&&  make&&  make install)
>>
>> it IS DIRTY because it does NOT remove obsoleted files
>> and yes i have seen environemnets where as example mysql did not
>> compile any longer as long all pieces of the old version were not
>> deleted manually
> 
> who says he's building system packages?I got the impression he's 
> building his own applications, stuff that typically runs in $HOME rather 
> than /usr or whatever.

on  a clean environment $HOME does not contain software
this is the apple-way having binaries running where your user
have write-access and from the viewpoints of security and
modern system-managment worst practice



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

Re: [CentOS] Is Biarch with 6.x now dead?

[Reindl Harald]

Am 28.12.2011 23:54, schrieb Michael Lampe:
> They update with everything else, there's no bandwidth limitation for 
> these machines and the discs are big enough. (The 'everything' I 
> described shortly elsewhere + a lot of extras totals to ~16 GB of disc 
> space. That's nothing.)

and becaus ewe have the ressources we are wasting them?

"They update with everything else"
mhh you must have a lot of money to have  only SSD-RAID
or why do you not notice the difference updating 100 or
180 packages?



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

Re: [CentOS] Is Biarch with 6.x now dead?

[Michael Lampe]

Reindl Harald wrote:

> it IS DIRTY because it does NOT remove obsoleted files
> and yes i have seen environemnets where as example mysql did not
> compile any longer as long all pieces of the old version were not
> deleted manually

Hardly ever do I type 'make install'. I stick to 
Base/Updates/Epel/Elrepo. Only if it's really necessary do I install 
other stuff. And I normally put quite some effort into it: I produce 
proper RPMs.

> working on a modern OS beside the apckage-managment is just silly
> you have no clear dependencies, you have no migration-path, you
> have no clean rollback - you are doing a dirty job working so

Well ...

I'll tell the users of our cluster (which I happen to manage as an 
extra) that they cannot submit any jobs any longer because their stuff 
is not and cannot be installed as an RPM ...

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

Re: [CentOS] Is Biarch with 6.x now dead?

[John R Pierce]

On 12/28/11 2:54 PM, Reindl Harald wrote:
> do what you believe and let us look where you end in 5-6 years
> after doing a couple of updates with "./configure&&  make&&  make install)
>
> it IS DIRTY because it does NOT remove obsoleted files
> and yes i have seen environemnets where as example mysql did not
> compile any longer as long all pieces of the old version were not
> deleted manually

who says he's building system packages?I got the impression he's 
building his own applications, stuff that typically runs in $HOME rather 
than /usr or whatever.

-- 
john r pierceN 37, W 122
santa cruz ca mid-left coast

___
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?

[Timothy Murphy]

Johnny Hughes wrote:

> System Administration is a time consuming and complicated thing.  That
> is why there are System Administrators.  That is why there are
> certifications like RHCT, RHCE, CISSP.  There are a whole slew of things
> that people who want to run secure server need to know, and dozens of
> security related certifications:
> 
> http://issa.org/page/?p=Certifications_13
> 
> 
> Running your own server is not like using a toaster.  It requires
> someone with a detailed level of knowledge to install and maintain it.

What about home servers?

It seems to me that these are bound to become more popular
as more devices with IP addresses (Smart TV's and phones, etc)
get linked into home systems.

I guess the person in the home running one of these
is a System Administrator.
Or maybe there should be a new title, Home System Administrator.

I run CentOS on a couple of small home servers (one remotely),
and wouldn't claim to have any deep knowledge of the subject.
I usually find the gurus on this newsgroup solve any problems I have!


-- 
Timothy Murphy  
e-mail: gayleard /at/ eircom.net
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College Dublin


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

Re: [CentOS] Is Biarch with 6.x now dead?

[Reindl Harald]

Am 28.12.2011 23:54, schrieb Michael Lampe:
> Three examples I have already given. To repeat one: a user has a code 
> base that is not 64-bit clean? What am I to do? Tell him to f***, 
> fix it myself for him, or what?

YES damend

force him to cleanup hsi crap or chain him in a virtual machine
or even replace him by one with more knowledge what he is doing
because 2012 "not 64-bit clean" is a bad joke



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

Re: [CentOS] Is Biarch with 6.x now dead?

[Michael Lampe]

(Sorry to be a little talkative today, but I will easily refute everything.)

Les Mikesell wrote:

> If you are moving binaries to any other machine, you are likely to
> have odd failures if you don't carefully control the libraries in the
> build environment.

The linker doesn't and cannot link 64-bit objects to 32-bit libs.

There's nothing else. Include files/etc. that are duplicated in 32-bit 
RPMs must be identical otherwise rpm doesn't install them together.

> If you aren't moving them to some other machine,
> then you rarely if ever need anything but the native libraries and
> development header set.

That's the basic use case anyway: A user compiles his stuff on the 
frontend of the cluster and then submits his job.

> The libraries are useful for 3rd party binary apps, but why build a
> 32bit app yourself if you are going to run it in a 64bit environment?

Three examples I have already given. To repeat one: a user has a code 
base that is not 64-bit clean? What am I to do? Tell him to f***, 
fix it myself for him, or what?

> I recall at least a couple of update conflicts/failure in the 5.x line
> caused by having 32bit versions of things installed on a 64bit host.
> Didn't those affect you?

Also already answerded: They forgot to copy the 32-bit updates to the 
64-bit updates repo. In one case there was a real bug. This happend only 
a couple of times so far in the 5.x time frame. So what? There where 
other bugs as well.

>  And there is always the extra time wasted
> doing updates to libraries and programs you don't ever use.

They update with everything else, there's no bandwidth limitation for 
these machines and the discs are big enough. (The 'everything' I 
described shortly elsewhere + a lot of extras totals to ~16 GB of disc 
space. That's nothing.)

-Michael

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

Re: [CentOS] Is Biarch with 6.x now dead?

[Reindl Harald]

Am 28.12.2011 23:32, schrieb Michael Lampe:
> Reindl Harald wrote:
> 
>> you need not to build a distribution to build clean packages
>> in a clean build-envirnonment - this is simply in your own
>> interest over the long and any quick&  dirty solution
>> will eat your time later
> 
> Please tell me in detail what ends up quick and dirty, when doing what 
> is well established Unix practise since decades. This is nothing else 
> than a simplified (but very convenient!) form of crosscompiling.

do what you believe and let us look where you end in 5-6 years
after doing a couple of updates with "./configure && make && make install)

it IS DIRTY because it does NOT remove obsoleted files
and yes i have seen environemnets where as example mysql did not
compile any longer as long all pieces of the old version were not
deleted manually

working on a modern OS beside the apckage-managment is just silly
you have no clear dependencies, you have no migration-path, you
have no clean rollback - you are doing a dirty job working so

but yes, you can, do if you think it is good enough for you
for the majority of advanced users it is not and in a prodessional
environment it is simply unacceptable




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

Re: [CentOS] Is Biarch with 6.x now dead?

[Les Mikesell]

On Wed, Dec 28, 2011 at 4:19 PM, Michael Lampe
 wrote:
> Maybe we're talking about different things here. I'm definitely not
> talking about how to build a distribution. That's why I'm using your's
> on not running my own.

If you are moving binaries to any other machine, you are likely to
have odd failures if you don't carefully control the libraries in the
build environment.   If you aren't moving them to some other machine,
then you rarely if ever need anything but the native libraries and
development header set.

> I'm talking about the usefulness of biarch. Not in the sense of building
> packages for redistribution, especially not as RPMs. It's just for
> building code for one's own purposes.

The libraries are useful for 3rd party binary apps, but why build a
32bit app yourself if you are going to run it in a 64bit environment?

I recall at least a couple of update conflicts/failure in the 5.x line
caused by having 32bit versions of things installed on a 64bit host.
Didn't those affect you?  And there is always the extra time wasted
doing updates to libraries and programs you don't ever use.

-- 
   Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Is Biarch with 6.x now dead?

[Michael Lampe]

Reindl Harald wrote:

> you need not to build a distribution to build clean packages
> in a clean build-envirnonment - this is simply in your own
> interest over the long and any quick&  dirty solution
> will eat your time later

Please tell me in detail what ends up quick and dirty, when doing what 
is well established Unix practise since decades. This is nothing else 
than a simplified (but very convenient!) form of crosscompiling.

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

Re: [CentOS] Is Biarch with 6.x now dead?

[Reindl Harald]

Am 28.12.2011 23:19, schrieb Michael Lampe:
> Maybe we're talking about different things here. I'm definitely not 
> talking about how to build a distribution. That's why I'm using your's 
> on not running my own.

you need not to build a distribution to build clean packages
in a clean build-envirnonment - this is simply in your own
interest over the long and any quick & dirty solution
will eat your time later

end of 2011 we should even consider to let 23bit die at all

and no, ia am no meber of centos
i am speaking for me as a user who loves clean and modern systems



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

Re: [CentOS] Is Biarch with 6.x now dead?

[Michael Lampe]

Maybe we're talking about different things here. I'm definitely not 
talking about how to build a distribution. That's why I'm using your's 
on not running my own.

I'm talking about the usefulness of biarch. Not in the sense of building 
packages for redistribution, especially not as RPMs. It's just for 
building code for one's own purposes.

Take an arbitrary source package and run configure. It may fail even on 
CentOS 6.2. So what?

Now, some run of configure fails on x86_64 in 32-bit mode. So what again?

To build a distribution (large, but something of a well defined size!), 
you need a build environment, which works for everything in a well 
defined way.

I only need an environment, in which I can make concrete things work 
easily, and that gives me the basics. For any piece of source code 
outside the core distribution, I'm not getting anything else anyway, not 
even in 64-bit mode.

People, who write their own code, expect never anything else.

And Biarch gives this to you equally well if you want to compile and run 
32-bit programs on 64-bit.

-Michael

PS: This is (of course) not for building RPMs, but the configure scripts 
I was interested in so far, work with this in my ~/.tcshrc:

---
...
alias linux32 "linux32 $SHELL"
...
if ( `uname -m` == i686 ) then
 setenv CC "gcc -m32"
 setenv CXX "g++ -m32"
 setenv PKG_CONFIG_PATH /usr/lib/pkgconfig
endif
...
---

 > linux32
 > configure
 > ... etc. ...

And if you have your own Makefiles, just put in two or three '-m32' and 
your set.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Is Biarch with 6.x now dead?

[Johnny Hughes]

On 12/28/2011 12:53 PM, Michael Lampe wrote:
> Johnny Hughes wrote:
> 
>> There is a variable in yum.conf called multilib_policy ...
>>
>> The default in CentOS 5 is all ... the default in CentOS 6 is best.
> 
> Ah, ok. Part of my playing around with 6.2 ist finding all the 
> differences with respect to 5.x. ;)
> 
>> I can tell you that I would personally use something like mock to build
>> or 32-bit items in at least a clean chroot when building/compiling 32
>> bit things on a 64-bit machine.  But to each their own.
> 
> I'm somehow confused with all of you loathing biarch so much. I can 
> partly understand this from a packagers point of view, but as an end user?
> 
> What you get at the end if you install both 32-bit and 64-bit packages 
> is the 32-bit stuff in (basically) /usr/lib. Otherwise nothing changes. 
> So the added stuff _is_ cleanly separated from the rest of the system.
> 
> The kernel runs 32-bit and 64-bit programs anyway, gcc has '-m32' (you 
> cannot even get rid of this), and all you you need to compile an run 
> 32-bit programs is the extra stuff in /usr/lib. (The include/doc/etc. 
> files which are in both packages _must_ be identical, that's checked.)

When you build things, *-devel files are used.  If you have extra stuff
(any extra stuff) in the build root, then the configure scripts can find
it and link against it since there are many optional things that are
searched for in the configure scripts.

This is true if you have curses installed (as an example) ... some
program's configure script will find that and link against it.  Now,
every time you want to run that program, you need to have curses installed.

It is therefore very important to have a very clean build root, with
only the absolute minimum amount of packages (or if you like, the
minimum libraries and headers) installed that are required to build the
package.  That way you control what is linked against.

If you have the 32bit headers in /lib/ (instead of in /lib64/) ... and
if the some crazy configure script finds it and there and includes it,
what does that do to the build?

This is why Red Hat uses mock to build packages.  It builds a clean root
to build packages.

It also is why OBS (open build system from opensuse) builds a VM or a
buildroot for each individual package, installing only the things needed
to build against.

> 
> All the Unix systems from the old days (Irix, Solaris, AIX, ...) had 
> this long before Linux saw 64 bits.
> 
> I like this feature very much, I and several others are using it on 5.x 
> for years now, and nobody ever complained.
> 
> The only problems I ever had were with you, Dear Packagers/Rebuilders. 
> Sometimes you forgot the updated 32-bit package from the x64 updates 
> repo, an in one case they were even really clashing in an unallowed way. 
> Your fault again. :)
> 
> So: what's the beef?

If you are on a machine that is not building things, then having the
32-bit software also on there is fine ... if you need it.

Now, personally, I don't want anything on my machines that are not
required to make them work.  If some script kiddie needs /lib/ld-2.12.so
for his hacker script to work and I only have /lib64/* stuff then that
is good as far as I am concerned.

I don't want things on any of my machines unless it is required ... So,
unless I need X and Gnome, it is not installed.





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

Re: [CentOS] Is Biarch with 6.x now dead?

[Michael Lampe]

Johnny Hughes wrote:

> There is a variable in yum.conf called multilib_policy ...
>
> The default in CentOS 5 is all ... the default in CentOS 6 is best.

Ah, ok. Part of my playing around with 6.2 ist finding all the 
differences with respect to 5.x. ;)

> I can tell you that I would personally use something like mock to build
> or 32-bit items in at least a clean chroot when building/compiling 32
> bit things on a 64-bit machine.  But to each their own.

I'm somehow confused with all of you loathing biarch so much. I can 
partly understand this from a packagers point of view, but as an end user?

What you get at the end if you install both 32-bit and 64-bit packages 
is the 32-bit stuff in (basically) /usr/lib. Otherwise nothing changes. 
So the added stuff _is_ cleanly separated from the rest of the system.

The kernel runs 32-bit and 64-bit programs anyway, gcc has '-m32' (you 
cannot even get rid of this), and all you you need to compile an run 
32-bit programs is the extra stuff in /usr/lib. (The include/doc/etc. 
files which are in both packages _must_ be identical, that's checked.)

All the Unix systems from the old days (Irix, Solaris, AIX, ...) had 
this long before Linux saw 64 bits.

I like this feature very much, I and several others are using it on 5.x 
for years now, and nobody ever complained.

The only problems I ever had were with you, Dear Packagers/Rebuilders. 
Sometimes you forgot the updated 32-bit package from the x64 updates 
repo, an in one case they were even really clashing in an unallowed way. 
Your fault again. :)

So: what's the beef?

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

Re: [CentOS] why not have yum-updatesd running by default?

[Jim Wildman]

The 'E' in CentOS stands for Enterprise.  Enterprises use change
control.  Servers do not update themselves whenever they see an update.
Updates are tested (not so much), approved and scheduled, hopefully in
line with a maintenance window.  In most enterprises that I've been in,
a server can't even contact the default repo servers.  And remember that
for a RHEL server, it has to be registered with RHN before it can
officially receive updates.  Defaulting yum-updatesd to on will be a no-op 
in almost every 'enterprise' case.

Enterprises also don't hang servers directly off the Internet.  There
are many layers betwixt the wild web and the OS.

In the decade plus that I've been running RHEL, I've seen 1 update that
was worthy of an emergency change to push it out RIGHT NOW to the
servers.  And even that one didn't really need to be done.

--
Jim Wildman, CISSP, RHCE   j...@rossberry.com http://www.rossberry.net
"Society in every state is a blessing, but Government, even in its best
state, is a necessary evil; in its worst state, an intolerable one."
Thomas Paine
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] why not have yum-updatesd running by default?

[dnk]

On Wednesday, December 28, 2011, Johnny Hughes  wrote:
> On 12/28/2011 02:04 AM, Bennett Haselton wrote:
>> Ever since someone told me that one of my servers might have been hacked
>> (not the most recent instance) because I wasn't applying updates as soon
as
>> they became available, I've been logging in and running "yum update"
>> religiously once a week until I found out how to set the yum-updatesd
>> service to do the equivalent automatically (once per hour, I think).
>>
>> Since then, I've leased dedicated servers from several different
companies,
>> and on all of them, I had to set up yum-updatesd to run and check for
>> updates -- by default it was off.  Why isn't it on by default?  Or is it
>> being considered to make it the default in the future?
>>
>> Power users can always change it if they want; the question is what would
>> be better for the vast majority of users who don't change defaults.  In
>> that case it would seem better to have updates on, so that they'll get
>> patched if an exploit is released but a patch is available.
>>
>> If the risk is that a buggy update might crash the machine, then that has
>> to be weighed against the possibility of *not* getting updates, and
getting
>> hacked as a result -- usually the latter being worse.
>>
>> After all, if users are exhorted to log in to their machines and check
for
>> updates and apply them, that implies that the risk of getting hosed by a
>> buggy update is outweighed by the risk of getting hacked by not applying
>> updates.  If that's true for updates that are applied manually, it ought
to
>> be true for updates that are downloaded and applied automatically,
>> shouldn't it?
>
> The first part of your question is answered simply as ... it defaults to
> do what the upstream distro does.  If they (the upstream provider) set
> their distro to automatically run updates by default, then so will
> CentOS.  I do not think they will do that though.
>
> The last question (does the security risk of not applying auto updates
> quickly outweigh the risk of the system breaking because of a bad
> update) depends on the situation.
>
> If you are doing some things, auto updates are probably fine.  I build
> and release these packages for CentOS and I fully trust them ...
> however, even I do not auto update my production servers at work.
>
> Each of my servers is a unique and complex system of several 3rd party
> applications/repos as well as the CentOS operating system.  So while the
> CentOS updates almost always "just work", the 3rd party apps (or 3rd
> party repos) might need looking at after the update to verify everything
> is still functioning properly.
>
> Now, we do have some servers that are just create and teardown for extra
> work load and these do auto update ... but I would never do that (auto
> update) for things that I consider critical.
>
> Over the years there have been updates where permissions issues
> prevented DNS servers from restarting, etc.   ...  it is just too
> important to me that my machines run to trust pushing auto updates to
> critical servers.  At least that is my take.  But, then again, I have
> test servers for my most critical stuff and I push the updates there for
> a couple of days to verify that they work before I move the updates into
> production.
>
> All that being said, if your server is a LAMP machine with MYSQL and
> Apache from CentOS and other standard CentOS packages like dhcp, bind,
> etc., then auto updates will likely never cause you problems.
>
>

This would not be a good idea in general. (just my opinion). I think back
to one update (can't remember which update - 5.x something) where it
swapped the eth0 and eth1 on all our dells. So every server was taken down
after update and then required the nics to be reconfigured (or cables
swapped) to get proper connectivity.

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

Re: [CentOS] Ad integration with centos 6

[dnk]

Hi Alain,

I had tried that tutorial, and had issues with that one as well. I
obviously was missing something when I tried it.

I actually got my machine in AD using likewise open. It works quite well,
with minimal config.

I appreciate the pointers though!

D



On Wednesday, December 28, 2011, Alain Péan 
wrote:
> Hi dnk,
>
> Le 23/12/2011 07:23, dnk a écrit :
>> Can anyone point me to a tutorial on using Active Directory to
authenticate
>> a centos 6 server? I just want to use it to authenticate, ssh and
restrict
>> access to a particular ad group. I prefer to use the lightest method
>> possible. I know you can use ldap, or winbind, etc. I have been trying to
>> follow the ones I have been googling, but none of them seem "quit
complete.
>> My issue is that I have no ldap experience.
>>
>> Dnk
>>
>
> I am personnally using SSSD (System Security Service Deamon) to
> authenticate C6 (SL6) against AD. See this blog link that looks good :
>
http://www.ohjeah.net/2011/06/09/linux-ssh-pam-ldap-sssd-2008-r2-ad-deployment/
>
> There is something more that I do before configuring Authentication, is
> to add the machine to AD with Samba (net join ads...).
>
> In /etc/krb5.conf, I added the encryption types required by AD 2008 :
> ...
> [libdefaults]
> ticket_lifetime = 24000
> default_realm = EXAMPLE.COM
> default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
> des3-hmac-sha1
> default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
> des3-hmac-sha1
> clockskew = 300
> 
>
> Hopes that helps...
>
> Alain
>
> --
> ==
> Alain Péan - LPP/CNRS
> Administrateur Système/Réseau
> Laboratoire de Physique des Plasmas - UMR 7648
> Observatoire de Saint-Maur
> 4, av de Neptune, Bat. A
> 94100 Saint-Maur des Fossés
> Tel : 01-45-11-42-39 - Fax : 01-48-89-44-33
> ==
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Is Biarch with 6.x now dead?

[Johnny Hughes]

On 12/28/2011 10:25 AM, Michael Lampe wrote:
> Ljubomir Ljubojevic wrote:
> 
>> Biarch is actually only needed for libraries and support packages.
>> Running native i386 application on x86_64 does not make much sense
>> (third-party apps are another thing).
> 
> I also like the option to compile, run, test, debug, etc. my own 
> programs as 32 bit. That's why starting with 5.x there's not only the 
> libs, but also the devel-packages.
> 
> Biarch is at least to me a valuable feature. Anyway it's all there, just 
> not in the ISOs it seems.

There is a variable in yum.conf called multilib_policy ...

The default in CentOS 5 is all ... the default in CentOS 6 is best.  I
personally like best better.  I only have the bare minimum i386
libraries on my machines (usually none but sometimes a few libraries on
workstations)

If you like, you can set multilib_policy to all after you install the
i386 items you want on your x86_64 install.

I can tell you that I would personally use something like mock to build
or 32-bit items in at least a clean chroot when building/compiling 32
bit things on a 64-bit machine.  But to each their own.




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

Re: [CentOS] NIS passwd and paswd.byname map encryption

[James Pearson]

Boris Epstein wrote:
> Hello listmates.
> 
> It appears that in order to authenticate a Mac OS X Lion client via NIS the
> passwords in passwd and passwd.byname maps need to be MD5 encrypted. How do
> I see what encryption has been used in my maps? How do I change it?

I think it is the case that Lion only supports DES password hashes in 
NIS passwd maps - see the thread at:



i.e. they only support the standard crypt() password hashes - which is a 
regression from previous versions of MacOS X - MacOS 10.6 supports MD5 
NIS password hashes ...

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

Re: [CentOS] Is Biarch with 6.x now dead?

[Michael Lampe]

Reindl Harald wrote:

> compiling is not the problem

Indeed. And thanks to biarch, this works ootb.

> there is ONE virtual machine neough for all users

Biarch reduces this even to one less: none. It's obvioulsy the simpler 
solution.

> however i can not imagine a usecase for 32bit software these days

I've given three real life examples.

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

Re: [CentOS] Is Biarch with 6.x now dead?

[Reindl Harald]

Am 28.12.2011 18:13, schrieb Michael Lampe:
> Reindl Harald wrote:
> 
>> compilers and devel-packages should usually be seperated from
>> working-computers and the compiled software packed as RPM
>> in a dedicated vritual machine
> 
> I'm using CentOS not only as a mail/web/etc. server, but also on my 
> development workstation, on a compute server and on an in-house compute 
> cluster. Compiling from source code in both 32- an 64-bit is a 
> requirement of all users of these machines.

what excatly is the need to use 32bit-software?
compiling is not the problem
there is ONE virtual machine neough for all users

however i can not imagine a usecase for 32bit software these days

2.6.41.6-1.fc15.x86_64 #1 SMP Wed Dec 21 22:36:55 UTC 2011
[harry@srv-rhsoft:~]$ rpm -qa | grep i686





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

Re: [CentOS] Is Biarch with 6.x now dead?

[Les Mikesell]

On Wed, Dec 28, 2011 at 11:06 AM, Michael Lampe
 wrote:
> Les Mikesell wrote:
>
>> Why not use a virtual machine for that and have a cleaner separation
>> of the architectures?
>
> Biarch runs natively and therfore faster, it can use
> hardware-accelerated OpenGL, it is easier to setup and use, and it is
> fully supported by TUV. To me the separation of arcitectures is clean
> enough and you simply switch from 64-bit-mode to 32-bit-mode by typing
> 'linux32'. How can it be better with a virtual machine?

Why does a compiler need OpenGL?  And with separate machines (physical
or virtual) you would just open windows on both at the same time.

> Also consider for example a compute cluster. It will of course have the
> 64-bit version of CentOS installed, but some users may also want to run
> 32-Bit-Code on it (because it's faster in their case, because their code
> isn't 64-bit-clean yet, or because it's a 32-bit-only commercial code,
> whatever).

Having run-time libs for both isn't a problem.  But if you want to
test that something will run on a real 32 bit machine, a VM would be a
more realistic test.

-- 
   Les Mikesell
lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Is Biarch with 6.x now dead?

[Michael Lampe]

Reindl Harald wrote:

> compilers and devel-packages should usually be seperated from
> working-computers and the compiled software packed as RPM
> in a dedicated vritual machine

I'm using CentOS not only as a mail/web/etc. server, but also on my 
development workstation, on a compute server and on an in-house compute 
cluster. Compiling from source code in both 32- an 64-bit is a 
requirement of all users of these machines.

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

Re: [CentOS] Is Biarch with 6.x now dead?

[Michael Lampe]

Les Mikesell wrote:

> Why not use a virtual machine for that and have a cleaner separation
> of the architectures?

Biarch runs natively and therfore faster, it can use 
hardware-accelerated OpenGL, it is easier to setup and use, and it is 
fully supported by TUV. To me the separation of arcitectures is clean 
enough and you simply switch from 64-bit-mode to 32-bit-mode by typing 
'linux32'. How can it be better with a virtual machine?

Also consider for example a compute cluster. It will of course have the 
64-bit version of CentOS installed, but some users may also want to run 
32-Bit-Code on it (because it's faster in their case, because their code 
isn't 64-bit-clean yet, or because it's a 32-bit-only commercial code, 
whatever).

-Michael



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

[CentOS] NIS passwd and paswd.byname map encryption

[Boris Epstein]

Hello listmates.

It appears that in order to authenticate a Mac OS X Lion client via NIS the
passwords in passwd and passwd.byname maps need to be MD5 encrypted. How do
I see what encryption has been used in my maps? How do I change it?

Thanks.

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

[CentOS] CentOS-announce Digest, Vol 82, Issue 15

[centos-announce-request]

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

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

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

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


Today's Topics:

   1. CESA-2011:1851 Critical CentOS 5 krb5 Update (Johnny Hughes)
   2. CESA-2011:1851 Critical CentOS 4 krb5 Update (Johnny Hughes)
   3. CESA-2011:1852 Critical CentOS 6 krb5-appl Update (Johnny Hughes)
   4. CentOS 4, CentOS 5,   and CentOS 6 Announce List messages
  (Johnny Hughes)


--

Message: 1
Date: Tue, 27 Dec 2011 20:44:52 +
From: Johnny Hughes 
Subject: [CentOS-announce] CESA-2011:1851 Critical CentOS 5 krb5
Update
To: centos-annou...@centos.org
Message-ID: <20111227204452.ga20...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2011:1851 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2011-1851.html

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

i386:
13b66e24262104d1a535e5d40d683de4da3847eb1b66b4430231f933af68d8a5  
krb5-devel-1.6.1-63.el5_7.i386.rpm
2217c3794890bce4ed9ffe6955bed543a7c973dfebbb3bc46948e054802d4108  
krb5-libs-1.6.1-63.el5_7.i386.rpm
869e0eabefe615cd7167af8cc5bb1eb107e77f26b6d45eed40ab836214e1e87f  
krb5-server-1.6.1-63.el5_7.i386.rpm
4bce7ce2cc6103d26833a788ac12fa5783c2458124fadd48283ee516ae3b3b0f  
krb5-server-ldap-1.6.1-63.el5_7.i386.rpm
74ff72965b4795c3aa25b3bb55eb0cf172517f05b71cd4b01c42fce7e1a92504  
krb5-workstation-1.6.1-63.el5_7.i386.rpm

x86_64:
13b66e24262104d1a535e5d40d683de4da3847eb1b66b4430231f933af68d8a5  
krb5-devel-1.6.1-63.el5_7.i386.rpm
8a1a675ad00fa74748330392835b1113b1f5568f67241af1e5662f8ef85635bb  
krb5-devel-1.6.1-63.el5_7.x86_64.rpm
2217c3794890bce4ed9ffe6955bed543a7c973dfebbb3bc46948e054802d4108  
krb5-libs-1.6.1-63.el5_7.i386.rpm
e2b0de48044aed6f9f60c7ce728e83697e3c1bcc7c5d445f4b3915bc76e5fc1f  
krb5-libs-1.6.1-63.el5_7.x86_64.rpm
4a709c9b9b9c9c405f24a5282949619573de32e7cda13cf661b3b58c659f5bce  
krb5-server-1.6.1-63.el5_7.x86_64.rpm
0c67699c07c9a71f6aa33cf293ec91d737b2d81d9ff8c0c34ded40e940d6ff85  
krb5-server-ldap-1.6.1-63.el5_7.x86_64.rpm
46e1ea8f197c7e94fd006ac72c6020d8b05baeeac26ff9f762dcf586af8ce3e3  
krb5-workstation-1.6.1-63.el5_7.x86_64.rpm

Source:
17982c402403263dc16764e2f8d9ea546bc94f7a5e2eda3bc0f1acc964ae3ba2  
krb5-1.6.1-63.el5_7.src.rpm



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



--

Message: 2
Date: Tue, 27 Dec 2011 20:56:16 +
From: Johnny Hughes 
Subject: [CentOS-announce] CESA-2011:1851 Critical CentOS 4 krb5
Update
To: centos-annou...@centos.org
Message-ID: <20111227205616.ga20...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2011:1851 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2011-1851.html

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

i386:
ae7eff91d77062264e811abe4f12b3b158564d8e3e538c66de30b33e5e57f854  
krb5-devel-1.3.4-65.el4.i386.rpm
c1e001823d14741ad9fb53b7e987b70a7189e3e93e4efc36c706b67966077494  
krb5-libs-1.3.4-65.el4.i386.rpm
90b52f16650bef67a0d6cd1a3c074ed499d10518857085f52b7af8d253ebbaad  
krb5-server-1.3.4-65.el4.i386.rpm
daef8cc7d6544effbdee59eadac25c3647b559386592089b645dae81c5a34d21  
krb5-workstation-1.3.4-65.el4.i386.rpm

x86_64:
70b16a0d10dce2498ef5849b9c0ee56f28c49d2a7ee8ca8bd3396a0c70912bfb  
krb5-devel-1.3.4-65.el4.x86_64.rpm
c1e001823d14741ad9fb53b7e987b70a7189e3e93e4efc36c706b67966077494  
krb5-libs-1.3.4-65.el4.i386.rpm
7b9a183dbc97a0586c5d215fc362f812d37c61be3c5c62b5846d41983344a896  
krb5-libs-1.3.4-65.el4.x86_64.rpm
e4a5601d4971bc9d293960d9c0ce88c1a569e2631c6951710ec73b3b56438ab2  
krb5-server-1.3.4-65.el4.x86_64.rpm
2abcb05e02d67f2fa465eb9816f2fcc678a3e54c6fdb9f835e50609d18381532  
krb5-workstation-1.3.4-65.el4.x86_64.rpm

Source:
6fee71efd6e6b9452cb7ee9190102e950f4d4001b5e086d8e728877244fc18e3  
krb5-1.3.4-65.el4.src.rpm



-- 
Tru Huynh
CentOS Project { http://www.centos.org/ }
irc: tru_tru, #cen...@irc.freenode.net



--

Message: 3
Date: Tue, 27 Dec 2011 21:11:42 +
From: Johnny Hughes 
Subject: [CentOS-announce] CESA-2011:1852 Critical CentOS 6 krb5-appl
Update
To: centos-annou...@centos.org
Message-ID: <20111227211142.ga21...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2011:1852 Critical

Upstream details at 

Re: [CentOS] Is Biarch with 6.x now dead?

[Reindl Harald]

Am 28.12.2011 17:48, schrieb Les Mikesell:
> On Wed, Dec 28, 2011 at 10:25 AM, Michael Lampe
>  wrote:
>>
>>> Biarch is actually only needed for libraries and support packages.
>>> Running native i386 application on x86_64 does not make much sense
>>> (third-party apps are another thing).
>>
>> I also like the option to compile, run, test, debug, etc. my own
>> programs as 32 bit. That's why starting with 5.x there's not only the
>> libs, but also the devel-packages.
>>
>> Biarch is at least to me a valuable feature. Anyway it's all there, just
>> not in the ISOs it seems.
> 
> Why not use a virtual machine for that and have a cleaner separation
> of the architectures?

not only architectures

compilers and devel-packages should usually be seperated from
working-computers and the compiled software packed as RPM
in a dedicated vritual machine

the only way to keep systems clean, "make install" is the best way
to make the whole setup dirty and especially for development/building
snapshots of a virtual machine are a hughe benfit



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

Re: [CentOS] Is Biarch with 6.x now dead?

[Les Mikesell]

On Wed, Dec 28, 2011 at 10:25 AM, Michael Lampe
 wrote:
>
>> Biarch is actually only needed for libraries and support packages.
>> Running native i386 application on x86_64 does not make much sense
>> (third-party apps are another thing).
>
> I also like the option to compile, run, test, debug, etc. my own
> programs as 32 bit. That's why starting with 5.x there's not only the
> libs, but also the devel-packages.
>
> Biarch is at least to me a valuable feature. Anyway it's all there, just
> not in the ISOs it seems.

Why not use a virtual machine for that and have a cleaner separation
of the architectures?

-- 
  Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ad integration with centos 6

[Alain Péan]

Hi dnk,

Le 23/12/2011 07:23, dnk a écrit :
> Can anyone point me to a tutorial on using Active Directory to authenticate
> a centos 6 server? I just want to use it to authenticate, ssh and restrict
> access to a particular ad group. I prefer to use the lightest method
> possible. I know you can use ldap, or winbind, etc. I have been trying to
> follow the ones I have been googling, but none of them seem "quit complete.
> My issue is that I have no ldap experience.
>
> Dnk
>

I am personnally using SSSD (System Security Service Deamon) to 
authenticate C6 (SL6) against AD. See this blog link that looks good :
http://www.ohjeah.net/2011/06/09/linux-ssh-pam-ldap-sssd-2008-r2-ad-deployment/

There is something more that I do before configuring Authentication, is 
to add the machine to AD with Samba (net join ads...).

In /etc/krb5.conf, I added the encryption types required by AD 2008 :
...
[libdefaults]
 ticket_lifetime = 24000
 default_realm = EXAMPLE.COM
 default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5 
des3-hmac-sha1
 default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5 
des3-hmac-sha1
 clockskew = 300


Hopes that helps...

Alain

-- 
==
Alain Péan - LPP/CNRS
Administrateur Système/Réseau
Laboratoire de Physique des Plasmas - UMR 7648
Observatoire de Saint-Maur
4, av de Neptune, Bat. A
94100 Saint-Maur des Fossés
Tel : 01-45-11-42-39 - Fax : 01-48-89-44-33
==

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

Re: [CentOS] Is Biarch with 6.x now dead?

[Michael Lampe]

Ljubomir Ljubojevic wrote:

> Biarch is actually only needed for libraries and support packages.
> Running native i386 application on x86_64 does not make much sense
> (third-party apps are another thing).

I also like the option to compile, run, test, debug, etc. my own 
programs as 32 bit. That's why starting with 5.x there's not only the 
libs, but also the devel-packages.

Biarch is at least to me a valuable feature. Anyway it's all there, just 
not in the ISOs it seems.

-Michael
___
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?

[Eero Volotinen]

http://www.awe.com/mark/blog/20110727.html

--
Eero
___
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?

[Johnny Hughes]

On 12/28/2011 07:55 AM, Johnny Hughes wrote:
> On 12/28/2011 01:40 AM, Bennett Haselton wrote:
>> On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Foster  wrote:
>>
>>>
>>>
>>>
>>>
>>> On Dec 27, 2011, at 11:29 PM, Bennett Haselton 
>>> wrote:
>>>
 On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste <
 seben...@weather.admin.niu.edu> wrote:

> On Tue, 27 Dec 2011, Bennett Haselton wrote:
>
>> Suppose I have a CentOS 5.7 machine running the default Apache with no
>> extra modules enabled, and with the "yum-updatesd" service running to
> pull
>> down and install updates as soon as they become available from the
>> repository.
>>
>> So the machine can still be broken into, if there is an unpatched
>>> exploit
>> released in the wild, in the window of time before a patch is released
> for
>> that update.
>>
>> Roughly what percent of the time is there such an unpatched exploit in
> the
>> wild, so that the machine can be hacked by someone keeping up with the
>> exploits?  5%?  50%?  95%?
>
> There's no way to give you an exact number, but let me put it this way:
>
> If you've disable as much as you can (which by default, most stuff is
> disabled, so that's good), and you restart Apache after each update,
> your chances of being broken into are better by things like SSH brute
> force attacks. There's always a chance someone will get in, but when you
> look at the security hole history of Apache, particularly over the past
> few years, there have been numerous CVE's, but workarounds and they
>>> aren't
> usually earth-shattering. Very few of them have. The latest version that
> ships with 5.7 is as secure as they come. If it wasn't, most web sites
> on the Internet would be hacked by now, as most run Apache
>

 I was asking because I had a server that did get broken into, despite
 having yum-updatesd running and a strong password.  He said that even if
 you apply all latest updates automatically, there were still windows of
 time where an exploit in the wild could be used to break into a machine;
>>> in
 particular he said:

 "For example, there was a while back ( ~march ) a kernel exploit that
 affected CentOS / RHEL. The patch came after 1-2 weeks of the security
 announcement. The initial announcement provided a simple work around
>>> until
 the new version is released."

>>>
>>> What was the nature of the break-in, if I may ask?
>>>
>>
>> I don't know how they did it, only that the hosting company had to take the
>> server offline because they said it was sending a DOS attack to a remote
>> host and using huge amounts of bandwidth in the process.  The top priority
>> was to get the machine back online so they reformatted it and re-connected
>> it, so there are no longer any logs showing what might have happened.
>> (Although of course once the server is compromised, presumably the logs can
>> be rewritten to say anything anyway.)
>>
>>> Security is more than just updates and a strong password.
>>>
>>>  - Rilindo Foster
>>>
>>
>> Well that's what I'm trying to determine.  Is there any set of default
>> settings that will make a server secure without requiring the admin to
>> spend more than, say, 30 minutes per week on maintenance tasks like reading
>> security newsletters, and applying patches?  And if there isn't, are there
>> design changes that could make it so that it was?
>>
>> Because if an OS/webserver/web app combination requires more than, say,
>> half an hour per week of "maintenance", then for the vast majority of
>> servers and VPSs on the Internet, the "maintenance" is not going to get
>> done.  It doesn't matter what our opinion is about whose fault it is or
>> whether admins "should" be more diligent.  The maintenance won't get done
>> and the machines will continue to get hacked.  (And half an hour per week
>> is probably a generous estimate of how much work most VPS admins would be
>> willing to do.)
>>
>> On the other hand, if the most common causes of breakins can be identified,
>> maybe there's a way to stop those with good default settings and automated
>> processes.  For example, if exploitable web apps are a common source of
>> breakins, maybe the standard should be to have them auto-update themselves
>> like the operating system.  (Last I checked, WordPress and similar programs
>> could *check* if updates were available, and alert you next time you signed
>> in, but they didn't actually patch themselves.  So if you never signed in
>> to a web app on a site that you'd forgotten about, you might never realize
>> it needed patching.)
> 
> System Administration is a time consuming and complicated thing.  That
> is why there are System Administrators.  That is why there are
> certifications like RHCT, RHCE, CISSP.  There are a whole slew of things
> that people who want to run secure server need to know, and dozens of
> s

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

[Johnny Hughes]

On 12/28/2011 01:44 AM, Bennett Haselton wrote:
> On Tue, Dec 27, 2011 at 10:08 PM, Ken godee  wrote:
> 
>>> password"?  That's what I'm talking about -- how often does this sort of
>>> thing happen, where you need to be subscribed to be a security mailing
>> list
>>> in order to know what workaround to make to stay safe, as opposed to
>> simply
>>> running yum-updatesd to install latest patches automatically.
>>
>> Happens all the time!
> 
> 
> Really?  An exploit is released in the wild, and there's a lag of several
> days before a patch is available through updates -- "all the time"?  How
> often?  Every week?
> 
> Since Gilbert and "supergiantpotato" seemed to be saying the opposite (that
> unpatched OS- and web-server-level exploits were pretty rare), what data
> were you relying on when you said that it "happens all the time"?
> 
> 
>> Count on it! If running any server available to
>> the public there is no "set and forget" if you're responsible for that
>> server you best stay informed/subscribed and ready to take action be it
>> a work around, update or whatever.

This website deals specifically with RHEL and security metrics:

http://www.awe.com/mark/blog/tags/metrics

CentOS will usually release security updates within 24 hours of upstream
during normal security updates and within 2 weeks on a "Point Release"
(a point release is a move from 5.6 to 5.7 or 6.1 to 6.2, etc.).

If you need faster updates than CentOS can provide, then RHEL is the
logical alternative.



signature.asc
Description: OpenPGP digital signature
___
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?

[Johnny Hughes]

On 12/28/2011 01:40 AM, Bennett Haselton wrote:
> On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Foster  wrote:
> 
>>
>>
>>
>>
>> On Dec 27, 2011, at 11:29 PM, Bennett Haselton 
>> wrote:
>>
>>> On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste <
>>> seben...@weather.admin.niu.edu> wrote:
>>>
 On Tue, 27 Dec 2011, Bennett Haselton wrote:

> Suppose I have a CentOS 5.7 machine running the default Apache with no
> extra modules enabled, and with the "yum-updatesd" service running to
 pull
> down and install updates as soon as they become available from the
> repository.
>
> So the machine can still be broken into, if there is an unpatched
>> exploit
> released in the wild, in the window of time before a patch is released
 for
> that update.
>
> Roughly what percent of the time is there such an unpatched exploit in
 the
> wild, so that the machine can be hacked by someone keeping up with the
> exploits?  5%?  50%?  95%?

 There's no way to give you an exact number, but let me put it this way:

 If you've disable as much as you can (which by default, most stuff is
 disabled, so that's good), and you restart Apache after each update,
 your chances of being broken into are better by things like SSH brute
 force attacks. There's always a chance someone will get in, but when you
 look at the security hole history of Apache, particularly over the past
 few years, there have been numerous CVE's, but workarounds and they
>> aren't
 usually earth-shattering. Very few of them have. The latest version that
 ships with 5.7 is as secure as they come. If it wasn't, most web sites
 on the Internet would be hacked by now, as most run Apache

>>>
>>> I was asking because I had a server that did get broken into, despite
>>> having yum-updatesd running and a strong password.  He said that even if
>>> you apply all latest updates automatically, there were still windows of
>>> time where an exploit in the wild could be used to break into a machine;
>> in
>>> particular he said:
>>>
>>> "For example, there was a while back ( ~march ) a kernel exploit that
>>> affected CentOS / RHEL. The patch came after 1-2 weeks of the security
>>> announcement. The initial announcement provided a simple work around
>> until
>>> the new version is released."
>>>
>>
>> What was the nature of the break-in, if I may ask?
>>
> 
> I don't know how they did it, only that the hosting company had to take the
> server offline because they said it was sending a DOS attack to a remote
> host and using huge amounts of bandwidth in the process.  The top priority
> was to get the machine back online so they reformatted it and re-connected
> it, so there are no longer any logs showing what might have happened.
> (Although of course once the server is compromised, presumably the logs can
> be rewritten to say anything anyway.)
> 
>> Security is more than just updates and a strong password.
>>
>>  - Rilindo Foster
>>
> 
> Well that's what I'm trying to determine.  Is there any set of default
> settings that will make a server secure without requiring the admin to
> spend more than, say, 30 minutes per week on maintenance tasks like reading
> security newsletters, and applying patches?  And if there isn't, are there
> design changes that could make it so that it was?
> 
> Because if an OS/webserver/web app combination requires more than, say,
> half an hour per week of "maintenance", then for the vast majority of
> servers and VPSs on the Internet, the "maintenance" is not going to get
> done.  It doesn't matter what our opinion is about whose fault it is or
> whether admins "should" be more diligent.  The maintenance won't get done
> and the machines will continue to get hacked.  (And half an hour per week
> is probably a generous estimate of how much work most VPS admins would be
> willing to do.)
> 
> On the other hand, if the most common causes of breakins can be identified,
> maybe there's a way to stop those with good default settings and automated
> processes.  For example, if exploitable web apps are a common source of
> breakins, maybe the standard should be to have them auto-update themselves
> like the operating system.  (Last I checked, WordPress and similar programs
> could *check* if updates were available, and alert you next time you signed
> in, but they didn't actually patch themselves.  So if you never signed in
> to a web app on a site that you'd forgotten about, you might never realize
> it needed patching.)

System Administration is a time consuming and complicated thing.  That
is why there are System Administrators.  That is why there are
certifications like RHCT, RHCE, CISSP.  There are a whole slew of things
that people who want to run secure server need to know, and dozens of
security related certifications:

http://issa.org/page/?p=Certifications_13


Running your own server is not like using a toaster.  It requires
someone w

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

[Johnny Hughes]

On 12/27/2011 11:01 PM, Bennett Haselton wrote:
> Yeah I know that most break-ins do happen using third-party web apps;
> fortunately the servers I'm running don't have or need any of those.
> 
> But then what about what my friend said:
> "For example, there was a while back ( ~march ) a kernel exploit that
> affected CentOS / RHEL. The patch came after 1-2 weeks of the security
> announcement. The initial
> announcement provided a simple work around until the new version is
> released."
> Is that an extremely rare freak occurrence?  Or are you just saying it's
> rare *compared* to breakins using web apps?  Or am I misunderstanding what
> my friend was referring to in the above paragraph?
> 

There have been NO critical kernel updates.  A critical update is one
where someone can remotely execute items at the root users.

Almost all critical updates are Firefox, Thunderbird, telnetd (does
anyone still allow telnet?), or samba (never expose that directly to the
internet either :D).  There was one critical issue on CentOS-5.x for exim:

http://rhn.redhat.com/errata/RHSA-2010-0970.html

All the other issues (non-critical) will require the user to get a "user
shell" and then elevate their privileges some way


If you want to know what the different classifications mean:

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


If you want objective numbers for security exploits, here is some info
for RHEL:

http://www.redhat.com/security/data/metrics/

and

http://www.awe.com/mark/blog/tags/metrics

===
If you want to search for a specific CVE:

https://www.redhat.com/security/data/cve/

===

CentOS is currently completely updated with all released updates for
CentOS-4.9, CentOS-5.7, and CentOS-6.2.

We also provide a CR repository for "Point Release" transitions (though,
we will not always use the CR repo if we can get the point release out
within 2-3 weeks).  Here is info on the CR repository:

http://wiki.centos.org/AdditionalResources/Repositories/CR

=

Long winded discussions on the list about people's opinions concerning
security might help you make decisions on the best practices for setting
up your server (do not allow ssh logins by password, limit logins by IP
addresses (or at least block problem subnets), disable root logins
directly, try to use SELinux for your web apps, etc.) ... but really,
each install is unique.

A google search will provide many suggestions for best security
practices, here is what upstream recommends:

http://www.centos.org/docs/5/html/Deployment_Guide-en-US/pt-security.html

The bottom line is, a default installation requires hardening.  The
amount of hardening needed depends on each individual install and its
requirements.



signature.asc
Description: OpenPGP digital signature
___
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?

[Johnny Hughes]

On 12/27/2011 10:42 PM, Bennett Haselton wrote:
> Everything installed on the machine had been installed with "yum".  So I
> assumed that meant that it would also be updated by "yum" if an update was
> available from the distro.
> 

1.  Are you running PHP apps on the web server?  Perl apps?  Bad code in
dynamic apps is the main way security breaches happen if via apache.
And in those cases is usually the ability to execute some script
(sometimes one that the bad guys upload first) that is the issue.  Many
times this happens because programmers of the dynamic (php, perl,
python, ruby, etc.) do not properly vet the input of some form or other
item.

2.  Why have password logins at all?  Using a secure ssh key only for
logins makes the most sense.

3.  Please do not top post.

> On Tue, Dec 27, 2011 at 9:38 PM, Karanbir Singh wrote:
> 
>> On 12/28/2011 04:29 AM, Bennett Haselton wrote:
>>> I was asking because I had a server that did get broken into, despite
>>> having yum-updatesd running and a strong password.  He said that even if
>>
>> the software component compromised was a part of the updates being
>> dished out from the distro ( and therefore likely covered via the
>> yum-updatesd? )
>>



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

Re: [CentOS] why not have yum-updatesd running by default?

[Johnny Hughes]

On 12/28/2011 02:04 AM, Bennett Haselton wrote:
> Ever since someone told me that one of my servers might have been hacked
> (not the most recent instance) because I wasn't applying updates as soon as
> they became available, I've been logging in and running "yum update"
> religiously once a week until I found out how to set the yum-updatesd
> service to do the equivalent automatically (once per hour, I think).
> 
> Since then, I've leased dedicated servers from several different companies,
> and on all of them, I had to set up yum-updatesd to run and check for
> updates -- by default it was off.  Why isn't it on by default?  Or is it
> being considered to make it the default in the future?
> 
> Power users can always change it if they want; the question is what would
> be better for the vast majority of users who don't change defaults.  In
> that case it would seem better to have updates on, so that they'll get
> patched if an exploit is released but a patch is available.
> 
> If the risk is that a buggy update might crash the machine, then that has
> to be weighed against the possibility of *not* getting updates, and getting
> hacked as a result -- usually the latter being worse.
> 
> After all, if users are exhorted to log in to their machines and check for
> updates and apply them, that implies that the risk of getting hosed by a
> buggy update is outweighed by the risk of getting hacked by not applying
> updates.  If that's true for updates that are applied manually, it ought to
> be true for updates that are downloaded and applied automatically,
> shouldn't it?

The first part of your question is answered simply as ... it defaults to
do what the upstream distro does.  If they (the upstream provider) set
their distro to automatically run updates by default, then so will
CentOS.  I do not think they will do that though.

The last question (does the security risk of not applying auto updates
quickly outweigh the risk of the system breaking because of a bad
update) depends on the situation.

If you are doing some things, auto updates are probably fine.  I build
and release these packages for CentOS and I fully trust them ...
however, even I do not auto update my production servers at work.

Each of my servers is a unique and complex system of several 3rd party
applications/repos as well as the CentOS operating system.  So while the
CentOS updates almost always "just work", the 3rd party apps (or 3rd
party repos) might need looking at after the update to verify everything
is still functioning properly.

Now, we do have some servers that are just create and teardown for extra
work load and these do auto update ... but I would never do that (auto
update) for things that I consider critical.

Over the years there have been updates where permissions issues
prevented DNS servers from restarting, etc.   ...  it is just too
important to me that my machines run to trust pushing auto updates to
critical servers.  At least that is my take.  But, then again, I have
test servers for my most critical stuff and I push the updates there for
a couple of days to verify that they work before I move the updates into
production.

All that being said, if your server is a LAMP machine with MYSQL and
Apache from CentOS and other standard CentOS packages like dhcp, bind,
etc., then auto updates will likely never cause you problems.



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

Re: [CentOS] Installation on a Macbook Pro with nVidia MCP89 SATA controller

[B.J. McClure]

On Wed, 2011-12-28 at 04:40 +, Karanbir Singh wrote:
> On 12/27/2011 01:10 PM, B.J. McClure wrote:
> > I tried CentOS 6.0 and 6.1 on Mac-Air with SSD.  Installer could not
> > find SSD and Google did not help.  FWIW, Ubuntu installed fine.  If you
> 
> I've seen a couple of MacbookAir's now running CentOS-6, do you need to
> set some mode (bootcamp like ?)
> 
> - KB

Could be.  Just downloaded 6.2 Live DVD and will have a serious go at it
after New Years.  Short handed at the moment.

Thanks for the suggestion and thanks to the entire team for a great job.
As one of the mostly silent majority, we do appreciate what you guys
contribute to us.

Happy New Year.

B.J.

CentOS release 6.2 (Final)

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

Re: [CentOS] Is Biarch with 6.x now dead?

[Ljubomir Ljubojevic]

On 12/28/2011 06:02 AM, Michael Lampe wrote:
>> nope. its actually quite a major pain to manage..
>>
>> you forgot to mention what you installed, how you did it and what you
>> expected V/s achieved
>
> I have installed all the packages from the two x86_64 DVDs with
> (eventually):
>
>   yum install --exclude=ovirt\* \*
>
> I'm not using any internet-based repos for now, because of limited
> bandwidth at home.
>
> I haven't touched 6.x before 6.2 and just thought it would be as in 5.x
> (biarch wise).
>
> With 6.2 everything on my X301 semms to be working much better or at
> least as good as in 5.7.
>
> I will slowly, carefully, and thankfully play with your Christmas
> present in the next two weeks. :)
>
> -Michael
>

Biarch is actually only needed for libraries and support packages. 
Running native i386 application on x86_64 does not make much sense 
(third-party apps are another thing).

So logic behind biarch is simple. "If your 32-bit app rpm requests 
32-bit support package/app it will be installed at the same time as that 
package".Or you can manually add/install needed package(s), like several 
packages, for Skype (32-bit) for example. But there is no need to waste 
useful space for package that will never be used (in case of 64-bit apps).


-- 

Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

Google is the Mother, Google is the Father, and traceroute is your
trusty Spiderman...
StarOS, Mikrotik and CentOS/RHEL/Linux consultant
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] why not have yum-updatesd running by default?

[Fajar Priyanto]

On Wed, Dec 28, 2011 at 4:04 PM, Bennett Haselton  wrote:
> Power users can always change it if they want; the question is what would
> be better for the vast majority of users who don't change defaults.  In
> that case it would seem better to have updates on, so that they'll get
> patched if an exploit is released but a patch is available.
>
> If the risk is that a buggy update might crash the machine, then that has
> to be weighed against the possibility of *not* getting updates, and getting
> hacked as a result -- usually the latter being worse.

IMHO, the risk of applying patches blindly outweight the benefit of
automatic update.
Yum-updatesd would not only fixes security bug, but also other things
that may not be good for our system.
Consider a database server that got automatically updated and the
sysadmin is so contemplate that it's only after a month or so he
realized the update have caused a corruption in the database. I don't
think his boss would be happy.

If a sysadmin is concern of the security of the servers, he should
subscribe to security advisory mailing list and do any required update
in time.
Laziness is not an excuse. Anyway, should he decides, he can always
easily activate the automatic updates.
___
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?

[夜神 岩男]

On 12/28/2011 04:40 PM, Bennett Haselton wrote:
> On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Foster  wrote:
>> On Dec 27, 2011, at 11:29 PM, Bennett Haselton
>>
>> What was the nature of the break-in, if I may ask?
>>
>
> I don't know how they did it, only that the hosting company had to take the
> server offline because they said it was sending a DOS attack to a remote
> host and using huge amounts of bandwidth in the process.  The top priority
> was to get the machine back online so they reformatted it and re-connected
> it, so there are no longer any logs showing what might have happened.
> (Although of course once the server is compromised, presumably the logs can
> be rewritten to say anything anyway.)

Stopping right there, it sounds like the hosting company doesn't know 
their stuff.

Logs should always be replicated remotely in a serious production 
environment, and I would say that any actual hosting company -- being a 
group whose profession it is to host things -- would define that category.

Yes, logs can get messed with. But everything up to the moment of 
exploit should be replicated remotely for later investigation, whether 
or not the specific, physical machine itself is wiped. The only way to 
get around that completely is to compromise the remote logger, and if 
someone is going to that much trouble, especially across custom setups 
and tiny spins (I don't know many people who use standard full-blown 
installs for remote logging machines...?) then they are good enough to 
have had your goose anyway.

My point is, I think server management is at least as much to blame as 
any specific piece of software involved here.

If that were not the case, why didn't my servers start doing the same thing?

> Well that's what I'm trying to determine.  Is there any set of default
> settings that will make a server secure without requiring the admin to
> spend more than, say, 30 minutes per week on maintenance tasks like reading
> security newsletters, and applying patches?  And if there isn't, are there
> design changes that could make it so that it was?
>
> Because if an OS/webserver/web app combination requires more than, say,
> half an hour per week of "maintenance", then for the vast majority of
> servers and VPSs on the Internet, the "maintenance" is not going to get
> done.  It doesn't matter what our opinion is about whose fault it is or
> whether admins "should" be more diligent.  The maintenance won't get done
> and the machines will continue to get hacked.  (And half an hour per week
> is probably a generous estimate of how much work most VPS admins would be
> willing to do.)
>
> On the other hand, if the most common causes of breakins can be identified,
> maybe there's a way to stop those with good default settings and automated
> processes.  For example, if exploitable web apps are a common source of
> breakins, maybe the standard should be to have them auto-update themselves
> like the operating system.  (Last I checked, WordPress and similar programs
> could *check* if updates were available, and alert you next time you signed
> in, but they didn't actually patch themselves.  So if you never signed in
> to a web app on a site that you'd forgotten about, you might never realize
> it needed patching.)

You just paraphrased the entire market position of professional hosting 
providers, the security community, China's (correct) assumptions for 
funding a cracking army, the reason browser security is impossible, etc.
___
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?

[夜神 岩男]

On 12/28/2011 02:01 PM, Bennett Haselton wrote:
> Yeah I know that most break-ins do happen using third-party web apps;
> fortunately the servers I'm running don't have or need any of those.
>
> But then what about what my friend said:
> "For example, there was a while back ( ~march ) a kernel exploit that
> affected CentOS / RHEL. The patch came after 1-2 weeks of the security
> announcement. The initial
> announcement provided a simple work around until the new version is
> released."
> Is that an extremely rare freak occurrence?  Or are you just saying it's
> rare *compared* to breakins using web apps?  Or am I misunderstanding what
> my friend was referring to in the above paragraph?

Yes, that is rare. There *are* holes in nearly everything, though, and 
there are workarounds and patches for nearly all of those holes.

But not all holes are equal. Not nearly so. For example, the vast 
majority of the security announcements for RHEL are rated as very minor, 
despite the enormous scrutiny Linux is subjected to. That we can find SO 
MANY tiny holes is a testament to the thoroughness of the community 
approach to common component development (which is a bit different from 
the dynamic found in niche applications development, despite what the 
RHSs of the world have to say).

It is important to ask your friend two things:

1- Was the vendor involved in the announcement, and if so was the 
workaround explained thoroughly in the announcement and permit 
reconfiguration of a functional system?

Sometimes people want to make a name for themselves by "finding a hole 
in the Linux kernel" and try to announce things without notifying the 
vendor, in which case the bad guys and good guys have a race to see who 
will develop first, the patchers or the exploiters.

Even IBM can get caught off-guard by things like this with Big Adult 
systems like z/OS. Being caught off-guard is the problem Google tries to 
solve by providing both paying and stroking the ego of people who find 
security problems with their infrastructure. Preventing the malicious 
use of such information is what the whole "Full Disclosure" concept is 
about (though the mailing list of the same name is often just nothing 
more than trollville)

2- Did the security hole, when exploited, grant root access? Without the 
ability to root the machine, the picture is a lot less grim. 
Understanding iptables, SELinux, what apps are installed, what Apache 
modules aren't necessary (quite a few), etc. can go a long way to 
providing intermediate barriers against a big scary hole in the kernel. 
Consider that the kernel has one huge hole by design called root. 
Getting access to it is the key, and the vast majority of security 
announcements permit marginal, not root, system access.


To answer your original question, the "announcement in March" is not 
anything I heard of. Or more correctly it isn't something I remember in 
particular, and I tend to keep up with things. I hear about *lots* of 
security holes in lots of different software daily. Most of it is 
patched before the announcement, or patched along with the announcement. 
The overwhelming majority of the announcements I see are XSS and SQL 
injections against web frameworks -- or various ways of re-verbing 
existing problems with new buzzwords.

As far as "what exact % of the time" that is impossible to determine 
until you at the very least put a threshold on the severity of a 
security issue. And when it comes to some issues, frankly what some 
people consider a needed feature another may consider a security hole. 
Take FTP and Telnet, for example. "Holy crap, wotmud.org: is WIDE 
OPEN to incoming telnet requests!" would be a ridiculous thing to 
proclaim, but I've seen it done. I've also seen people say "Ubuntu is 
WIDE OPEN because they have a new guest account by default with a 
consistent name!" -- as if names were equivalent to passwords.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] why not have yum-updatesd running by default?

[Bennett Haselton]

Ever since someone told me that one of my servers might have been hacked
(not the most recent instance) because I wasn't applying updates as soon as
they became available, I've been logging in and running "yum update"
religiously once a week until I found out how to set the yum-updatesd
service to do the equivalent automatically (once per hour, I think).

Since then, I've leased dedicated servers from several different companies,
and on all of them, I had to set up yum-updatesd to run and check for
updates -- by default it was off.  Why isn't it on by default?  Or is it
being considered to make it the default in the future?

Power users can always change it if they want; the question is what would
be better for the vast majority of users who don't change defaults.  In
that case it would seem better to have updates on, so that they'll get
patched if an exploit is released but a patch is available.

If the risk is that a buggy update might crash the machine, then that has
to be weighed against the possibility of *not* getting updates, and getting
hacked as a result -- usually the latter being worse.

After all, if users are exhorted to log in to their machines and check for
updates and apply them, that implies that the risk of getting hosed by a
buggy update is outweighed by the risk of getting hacked by not applying
updates.  If that's true for updates that are applied manually, it ought to
be true for updates that are downloaded and applied automatically,
shouldn't it?

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