Re: [CentOS] Very slow disk I/O
Lol - spinning disks? Really? SSD is down to like 50cents a gig. And they have 1TB disks... slow disks = you get what you deserve... welcome to 2015. Autolacing shoes, self drying jackets, hoverboards - oh, yeah, and 110k IOPS 1TB SamSung Pro 850 SSD Drives for $449 on NewEgg. dumbass -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Les Mikesell Sent: Tuesday, February 03, 2015 12:42 AM To: CentOS mailing list Subject: Re: [CentOS] Very slow disk I/O On Mon, Feb 2, 2015 at 11:37 PM, Jatin Davey wrote: > > I will test and get the I/O speed results with the following and see > what works best with the given workload: > > Create 5 volumes each with 150 GB in size for the 5 VMs that i will be > running on the server Create 1 volume with 600GB in size for the 5 VMs > that i will be running on the server Try with LVM volumes instead of > files > > Will test and compare the I/O responsiveness in all cases and go with > the one which is acceptable. Unless you put each VM on its own physical disk or raid1 mirror you aren't really doing anything to isolate the vms from each other or to increase the odds that a head will be near the place the next access needs it to be. -- Les Mikesell lesmikes...@gmail.com ___ 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] Very slow disk I/O
Am 03.02.2015 um 10:14 schrieb Joseph L. Brunner: Lol - spinning disks? Really? SSD is down to like 50cents a gig. And they have 1TB disks... slow disks = you get what you deserve... welcome to 2015. Autolacing shoes, self drying jackets, hoverboards - oh, yeah, and 110k IOPS 1TB SamSung Pro 850 SSD Drives for $449 on NewEgg. dumbass Right, *consumer grade* SSD prices were coming down thzat much. But I am sure the appliance Jatin is building up (while he uses the @cisco.com mail domain) is intended for enterprise usage and has to have enterprise grade hardware components. Just like he used an enterprise grade HDD (though a SATA and not a SAS model with only 7.2krpm which is, as John pointed out, not a good choice for a virtualization host) to build the machine. Investigate about SSDs made to be used in servers, SLC and not MLC type of chips, SAS interface. Then lets speak again after you have checked their prices. Regards Alexander ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Squid3 on CentOS 6.6: IPv6 PTR endianess
Hey Max, You are using squid 3.1.x which is not supported anymore by the squid development team. It is possible that there is a bug in this version of squid and that it was not reported until now. Squid should not run a PTR record lookup unless there is an acl which requires\wants\needs it. Details on squid for CentOS at: http://wiki.squid-cache.org/KnowledgeBase/CentOS In any case the better place to seek for an answer on the issue you have described is in the squid-users mailing list. All The Bests, Eliezer Croitoru On 31/01/2015 20:36, Max Grobecker wrote: Is anyone else experiencing this? It seems to be happen on IPv6 client addresses only - with IPv4 it works just fine. And besides of these broken PTR lookups Squid is working as expected. Greetings from Wuppertal Max ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
Warren Young wrote:
> The new rules are:
>
> 1. At least 8 characters.
>
> 2. Nothing that violates the pwquality rules:
>
> http://linux.die.net/man/8/pam_pwquality
The 7 rules listed in this URL seem utterly bizarre to me.
The first is "Don't use a palindrome"
which makes me wonder if the author knows the meaning of this word.
I suspect he/she thinks it means "a known word backwards".
Of the remaing 6 rules one is optional ("repeated characters")
and 3 of the remaining 5 concern similarity to previous passwords.
Of the remaining 2, one is to avoid short passwords (unspecified),
and the other to avoid one's username.
--
Timothy Murphy
gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 03, 2015 at 01:53:45PM +, Timothy Murphy wrote: > > The 7 rules listed in this URL seem utterly bizarre to me. > > The first is "Don't use a palindrome" > which makes me wonder if the author knows the meaning of this word. > I suspect he/she thinks it means "a known word backwards". > That's what I would call it (or phrase or sequence of numbers.) When I read your post, I thought I was missing something, but some cursory googling indicates that I'm right. What am I missing here? (Looking stupid for the sake of everyone who wants to know, because I'm unselfish--and, having been married more than once, have a thick skin). -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
Valeri Galtsev wrote: >> What secret motive *could* there be?? The current security policy is >> weak, and this change fixes that. End of story. > > It's hard to not endorse everything you are saying. As far as motive is > concerned, it is not that secret. Security. RedHat doesn't like poorly > administered machined with RHEL linux get hacked, then many voices saying > saying in the internet: RHEL Linux is not secure, RHEL Linux machines are > getting hacked. Even though the reason is not what it sounds like. While I admire RedHat, and use CentOS on my home servers, I would expect RH to give priority to those paying for their services, who I imagine are almost all sysadmins of systems with many users. My interests as a tiny user may not coincide with theirs. This does not mean that I think there are evil spirits at RH trying to disrupt my life. But it does mean that the inconvenience of strong passwords may outweigh any additional security in my case. -- Timothy Murphy gayleard /at/ eircom.net School of Mathematics, Trinity College, Dublin ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
Palindrome : A word, phrase or sequence that reads the same backward as forward, e.g. ³madam" or "nurses run² Valère Binet [C] On 2/3/15, 9:16 AM, "Scott Robbins" wrote: >On Tue, Feb 03, 2015 at 01:53:45PM +, Timothy Murphy wrote: >> >> The 7 rules listed in this URL seem utterly bizarre to me. >> >> The first is "Don't use a palindrome" >> which makes me wonder if the author knows the meaning of this word. >> I suspect he/she thinks it means "a known word backwards". >> > >That's what I would call it (or phrase or sequence of numbers.) When I >read your post, I thought I was missing something, but some cursory >googling indicates that I'm right. What am I missing here? > >(Looking stupid for the sake of everyone who wants to know, because I'm >unselfish--and, having been married more than once, have a thick skin). > >-- >Scott Robbins >PGP keyID EB3467D6 >( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) >gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 > >___ >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] Another Fedora decision
On Mon, Feb 02, 2015 at 11:31:35PM +, Always Learning wrote: > If testing then a one character password is very acceptable to me. Why > should some arrogant nutter impose an arduous ultra secure password when > a simple one character password will suffice ? Who knows the machine, > the deploying environment and the circumstances better ? The user or > some anonymous and arrogant nutter perhaps many thousands of miles (or > kilometers) away ? I'm curious, were you upset when Java (and various other software packages that use SSL) were updated to stop using SSLv3? Surely this would have caused problems with any testing infrastructure that wasn't open to the world that used pre-generated SSL certificates. The decision to disable it was made by the packagers of the software because of security implications. Sure, SSLv3 still works, it's just not secure. It's just some arrogant nutter who thinks that maybe we shouldn't be using it anymore. -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
I think it well to recall that the change which instigated this tempest was not to the network operations of a RHEL based system but to the 'INSTALLER' process, Anaconda. Now, I might be off base on this but really, ask yourself: Who exactly uses an installer program? And what is the threat model being addressed by requiring that the installer set a suitably strong password for root? For what purpose? Because RHEL sets the sshd on and allows root access over ssh via password by default? Then is not the correct approach to disable that access instead? But wait! Is it not true that the network services are not started by default? So, exactly where is the threat? Does it not occur much, much later in the workflow than at the installer? Would it not be more sensible to require root access to start sshd (hu. . . is that not a requirement now?) and to ask for the root password at that time. And then of course, you could catch those sneaky people that change the root password after the install is complete. Surly, it is when starting network services that then, and only then, one should check that one of the following conditions are true: 1.) root access over the network is disabled; 2.) root access over the network is allowed via RSA only; 3.) if root can log in via ssh using a password then the root password must be strong? That process seems like something that could be setup in a network init script, upstart system job, or systemd service file without a great deal of effort. Why does arbitrarily requiring 'strengthening' of the root password have to go into the installer program? Yes, the alternative approach would adversely impact automatic system restarts. And your point? Is not the easy answer but to disallow root access over the network entirely; or to force the use of RSA certs for root logons? Are not these far, far superior approaches to dealing with this issue than requiring a 'strong' root password everywhere, all the time, regardless of what purpose the system is used for? This change to Anaconda is not security, it is theatre. It is directly equivalent to airport passenger security checks. Totally ineffectual but so intrusive and inconvenient that we have to believe that it works. For otherwise the inescapable conclusion is that we are all fools for putting up with it; and no-one likes to think of themselves as a fool. I call this the 'Buckley's Mixture' approach to social engineering. In any case, allowing an eight character password on credentials exposed to public network access is laughable. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Mon, February 2, 2015 21:34, PatrickD Garvey wrote: > OK, folks. You're doing a great job of describing the current milieu > with a rough description of some best practices. > > Now how about some specific sources you personally used to learn your > craft that we can use likewise? > > PatrickD > > Go to http://www.ccc.de/en/. Visit and view some of the videos of presentations from previous congresses and hackfests. Educate yourself on the threats. Once you see what you are up against then you will have some ideas about what questions to ask. Then you can find the material you need. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 09:24 -0500, Jonathan Billings wrote: > I'm curious, were you upset when Java (and various other software > packages that use SSL) were updated to stop using SSLv3? No. I do not use Java. Updating to prevent security breeches is *always* a good idea. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On 2015-02-03, Scott Robbins wrote: > On Tue, Feb 03, 2015 at 01:53:45PM +, Timothy Murphy wrote: >> >> The first is "Don't use a palindrome" >> which makes me wonder if the author knows the meaning of this word. >> I suspect he/she thinks it means "a known word backwards". > > That's what I would call it (or phrase or sequence of numbers.) When I > read your post, I thought I was missing something, but some cursory > googling indicates that I'm right. What am I missing here? I don't think anybody is missing anything. "Palindrome" in this context may not be limited to real words; the author may be suggesting that you not pick your password by picking a real word and tacking on its reverse to make a palindrome, e.g., "password1drowssap". --keith -- kkel...@wombat.san-francisco.ca.us ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Kickstart setup
Is there a way to use kickstart to boot a machine into a manual setup process? Basically what I'm getting to is this, the machine doesn't not have a CD drive in it (nor can I add one), but I can boot it via kickstart. The install media is on the network. What I'd like to do is boot this machine up and rather than have kickstart do everything for me as far as installing the OS and packages, instead present me with a manual setup (that I can get to via vnc) where I get to pick what I want or don't want on the machine. After it's all done, I'm going to go through the anaconda files and generate a base kickstart for all future installs. Does anyone have an example kickstart file I can go off of to do that? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart setup
Ashley M. Kirchner writes: > Is there a way to use kickstart to boot a machine into a manual setup > process? Basically what I'm getting to is this, the machine doesn't not > have a CD drive in it (nor can I add one), but I can boot it via kickstart. [...] When no kickstart file is provided in the configured location, you will be dropped into the manual installer. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, February 3, 2015 9:17 am, James B. Byrne wrote: > I think it well to recall that the change which instigated this > tempest was not to the network operations of a RHEL based system but > to the 'INSTALLER' process, Anaconda. Now, I might be off base on > this but really, ask yourself: Who exactly uses an installer program? > And what is the threat model being addressed by requiring that the > installer set a suitably strong password for root? For what purpose? > Because RHEL sets the sshd on and allows root access over ssh via > password by default? Then is not the correct approach to disable that > access instead? Dealing with [computer] security for long time I learned this: if factors A, B, and C affect the security, each of them should be tightened to required security level. A mere fact that A on its own provides necessary level of security can not be served as an excuse to leave B and C loose; they too should be brought to the same necessary level of security. This becomes a common sense if one takes into account that A might just not do its job even though appropriately tightened - merely due to some bug. This is the basics of security I was taught, and my long experience confirms this is right thing. My apologies if I misunderstood you and my comment is beyond your point. > > But wait! Is it not true that the network services are not started by > default? So, exactly where is the threat? Does it not occur much, > much later in the workflow than at the installer? Would it not be > more sensible to require root access to start sshd (hu. . . is > that not a requirement now?) and to ask for the root password at that > time. And then of course, you could catch those sneaky people that > change the root password after the install is complete. > > Surly, it is when starting network services that then, and only then, > one should check that one of the following conditions are true: 1.) > root access over the network is disabled; 2.) root access over the > network is allowed via RSA only; 3.) if root can log in via ssh using > a password then the root password must be strong? > > That process seems like something that could be setup in a network > init script, upstart system job, or systemd service file without a > great deal of effort. Why does arbitrarily requiring 'strengthening' > of the root password have to go into the installer program? Hm. whether or not my system is clever enough to tighten security at some point, I will keep doing my sysadmin's part by following security guidelines and practices worked out through ...hm... about a couple of decades. > > Yes, the alternative approach would adversely impact automatic system > restarts. And your point? Is not the easy answer but to disallow > root access over the network entirely; or to force the use of RSA > certs for root logons? Are not these far, far superior approaches to > dealing with this issue than requiring a 'strong' root password > everywhere, all the time, regardless of what purpose the system is > used for? Well, under some circumstances secret key can not be trusted more that a good password (passphrase). I've seen these, so I for one do not share widespread opinion that key pairs (or certificates) are more secure that passwords (meaning passwords in general and excluding people stupidity to have weak ones - I an sceptical that you can force stupid person stay safe by creating one or another environment for them - for everybody that is). > > This change to Anaconda is not security, it is theatre. It is directly > equivalent to airport passenger security checks. Yes, indeed we both seem to converge you can not force people who do not care to stay safe to stay safe. Even disagreeing with that I understand (not that I approve of) the reasons RedHat is going to enforce that. Valeri > Totally ineffectual > but so intrusive and inconvenient that we have to believe that it > works. For otherwise the inescapable conclusion is that we are all > fools for putting up with it; and no-one likes to think of themselves > as a fool. I call this the 'Buckley's Mixture' approach to social > engineering. > > In any case, allowing an eight character password on credentials > exposed to public network access is laughable. > > -- > *** E-Mail is NOT a SECURE channel *** > James B. Byrnemailto:byrn...@harte-lyne.ca > Harte & Lyne Limited http://www.harte-lyne.ca > 9 Brockley Drive vox: +1 905 561 1241 > Hamilton, Ontario fax: +1 905 561 0757 > Canada L8E 3C3 > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___
Re: [CentOS] Kickstart setup
On 02/03/2015 10:28 AM, Ashley M. Kirchner wrote:
Is there a way to use kickstart to boot a machine into a manual setup
process? Basically what I'm getting to is this, the machine doesn't not
have a CD drive in it (nor can I add one), but I can boot it via kickstart.
The install media is on the network. What I'd like to do is boot this
machine up and rather than have kickstart do everything for me as far as
installing the OS and packages, instead present me with a manual setup
(that I can get to via vnc) where I get to pick what I want or don't want
on the machine. After it's all done, I'm going to go through the anaconda
files and generate a base kickstart for all future installs. Does anyone
have an example kickstart file I can go off of to do that?
It sounds like you just want to do a VNC install. There is a write-up
in the RHEL installation guide on doing just that. You can either have
the installer accept incoming VNC connections for the session or have it
connect to a listening VNC client via boot arguments.
The documentation says that you can just put "vnc" (or
"vncconnect={host}") in the kickstart file in the command section and
proceed from there. Here's a link to an article in Red Hat Magazine
that has a pretty good overview:
http://www.redhat.com/magazine/024oct06/features/kickstart/
As usual, YMMV!
--
Jay Leafey - jay.lea...@mindless.com
Memphis, TN
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 03, 2015 at 07:52:53AM -0800, Keith Keller wrote: > On 2015-02-03, Scott Robbins wrote: > > On Tue, Feb 03, 2015 at 01:53:45PM +, Timothy Murphy wrote: > >> > >> The first is "Don't use a palindrome" > >> which makes me wonder if the author knows the meaning of this word. > >> I suspect he/she thinks it means "a known word backwards". > > > > That's what I would call it (or phrase or sequence of numbers.) When I > > read your post, I thought I was missing something, but some cursory > > googling indicates that I'm right. What am I missing here? > > I don't think anybody is missing anything. "Palindrome" in this context > may not be limited to real words; the author may be suggesting that you > not pick your password by picking a real word and tacking on its > reverse to make a palindrome, e.g., "password1drowssap". > Ah, that makes sense then, thanks. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Mon, 2015-02-02 at 20:26 -0800, PatrickD Garvey wrote: > > The CentOS wiki pages found by a title page search are: > http://wiki.centos.org/HelpOnConfiguration/SecurityPolicy > http://wiki.centos.org/HowTos/Security > http://wiki.centos.org/Security > http://wiki.centos.org/Security/Heartbleed > http://wiki.centos.org/Security/POODLE > http://wiki.centos.org/Security/Shellshock 1. HelpOnConfiguration/SecurityPolicy = 2007-04-01 1(a). Link 'SecurityPolicy' = HTML status code 404 1(b). Link 'MoinMoin' = 2007-04-01 2. HowTos/Security = 2010-02-19 (RHEL 5) 3. Security = 2014-10-16 and refer to Heartbleed, Shellshock, POODLE *** NOTHING about Firewalls (IP Tables) *** Perhaps it is a good time for those with harsh attitudes to abandon the practise of dissuading newcomers from contributing to the Centos Knowledge Pool for the ultimate benefit of everyone especially the newcomers, the shy, those whose English may not be ultra perfect and the curious. If a newcomer makes a mistake or suggests something which is a good idea but never been done before by the Old Timers, do not destructively criticise their efforts. Constructive criticism is always good but sheer negativity because the newcomer has a different attitude to established methods is detrimental to the Centos ethos. After all computers always have been (certainly for me) an endless Learning process. Inventions should have have occurred if everyone always had exactly the same attitude and beliefs as everyone else. Thinking differently is often beneficial. Sympathetic interaction and informed debate is superior to hash words which usually dissuade the newcomers from ever again making suggestions or offering a potentially innovative idea. Those who post on this list are probably less than 0.001% of the world-wide Centos users. Perhaps a Centos Newcomers List* environment would nurture a wider and better understanding of basic Centos whilst leaving the Data Centre things, the users of non-existent Clouds (actually just another Data Centre) and the technicalities of different RAIDs, motherboards, peripherals, disk speeds etc. to the main Centos List. * alternative name suggestions: Centos Learning ? Centos Basic ? The suggested list should have the possibility of linking to web pages to illustrate topics which means, perhaps, being able to forward diagrams etc. for publication on the Centos Learning web site. Centos Leaning could and should encourage people to submit articles on various aspects of Centos. Thus providing a continuous educational environment beneficial to all. Centos Learning is not a competitor to the main Centos Users List, but - probably for the first time ever - a genuine online learning and exploring asset for those using or thinking of using Centos (could even team-up with Scientific since it is the same Linux). Fedora has not got such a list, so my idea must be good ! Please excuse any inadvertent errors and misspellings. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 3, 2015 at 11:20 AM, Scott Robbins wrote: >> >> I don't think anybody is missing anything. "Palindrome" in this context >> may not be limited to real words; the author may be suggesting that you >> not pick your password by picking a real word and tacking on its >> reverse to make a palindrome, e.g., "password1drowssap". >> > > Ah, that makes sense then, thanks. I think the intent is: "Don't use a password likely to be included in the list that an attacker would try". Of course if services would rate-limit the failures by default or at least warn you about repeated failures and their source, brute-force attacks would rarely succeed. But fixing the problem doesn't seem to be the point here. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart setup
On 02/03/2015 11:19 AM, Jay Leafey wrote:
The documentation says that you can just put "vnc" (or
"vncconnect={host}") in the kickstart file in the command section and
proceed from there. Here's a link to an article in Red Hat Magazine
that has a pretty good overview:
http://www.redhat.com/magazine/024oct06/features/kickstart/
As usual, YMMV!
OK, not QUITE that simple after all. The "vnc" or "vncconnect" entries
have to be passed to the kernel via grub or syslinux/isolinux rather
than in the kickstart file. Your network install media would have to be
altered to do this if you cannot add the options to the command line
interactively.
Sorry!
--
Jay Leafey - jay.lea...@mindless.com
Memphis, TN
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart setup
With Lars' original comment of not having a ks file specified, I figured it
out from there. And appending vnc to the command line is really all I need
for it to work.
Thanks everyone for the replies. Always very helpful!
On Tue, Feb 3, 2015 at 10:43 AM, Jay Leafey wrote:
> On 02/03/2015 11:19 AM, Jay Leafey wrote:
>
>> The documentation says that you can just put "vnc" (or
>> "vncconnect={host}") in the kickstart file in the command section and
>> proceed from there. Here's a link to an article in Red Hat Magazine
>> that has a pretty good overview:
>>
>> http://www.redhat.com/magazine/024oct06/features/kickstart/
>>>
>>
>> As usual, YMMV!
>>
>
> OK, not QUITE that simple after all. The "vnc" or "vncconnect" entries
> have to be passed to the kernel via grub or syslinux/isolinux rather than
> in the kickstart file. Your network install media would have to be altered
> to do this if you cannot add the options to the command line interactively.
>
> Sorry!
>
> --
> Jay Leafey - jay.lea...@mindless.com
> Memphis, TN
> ___
> 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] Another Fedora decision
On Tue, February 3, 2015 11:37 am, Les Mikesell wrote: > On Tue, Feb 3, 2015 at 11:20 AM, Scott Robbins wrote: >>> >>> I don't think anybody is missing anything. "Palindrome" in this >>> context >>> may not be limited to real words; the author may be suggesting that you >>> not pick your password by picking a real word and tacking on its >>> reverse to make a palindrome, e.g., "password1drowssap". >>> >> >> Ah, that makes sense then, thanks. > > I think the intent is: "Don't use a password likely to be included in > the list that an attacker would try". Of course if services would > rate-limit the failures Which sysadmins do for ages when they configure their machines. And I don't think any system will ever come from system vendor fully prepared to serve anything necessary, and tightened to best requirements (which depend on box designation anyway). So, system vendors can do better, but there always will be need for you to do your sysadmin's part. Sounds almost like job security. As one of my friends says: all systems suck, and thanks to that got our jobs ;-) Valeri > by default or at least warn you about repeated > failures and their source, brute-force attacks would rarely succeed. > But fixing the problem doesn't seem to be the point here. > > -- >Les Mikesell > lesmikes...@gmail.com > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 17:34 +, Always Learning wrote: > Inventions should have have occurred if everyone always had exactly > the same attitude and beliefs as everyone else. Thinking differently > is often beneficial. Whoops ! Inventions *WOULD NEVER* have occurred if *PEOPLE* always had exactly the same attitude and beliefs as everyone else. Thinking differently is often beneficial. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 3, 2015 at 11:48 AM, Valeri Galtsev wrote: > >> I think the intent is: "Don't use a password likely to be included in >> the list that an attacker would try". Of course if services would >> rate-limit the failures > > Which sysadmins do for ages when they configure their machines. And I > don't think any system will ever come from system vendor fully prepared to > serve anything necessary, and tightened to best requirements (which depend > on box designation anyway). Really? Are vendors not capable of shipping something with good default settings? It seems like getting a new car and having to install a different engine yourself because the factory couldn't figure out how to do it. > So, system vendors can do better, but there > always will be need for you to do your sysadmin's part. If that were really true, then you also wouldn't be able to follow anyone else's advice about how to do it. That is, if your system really needs to be so different that it couldn't have been shipped with the configuration you need, then a book couldn't tell you that either. > Sounds almost like > job security. As one of my friends says: all systems suck, and thanks to > that got our jobs ;-) But wouldn't you rather be doing something new/different instead of just fixing things that should have been done right in the first place? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, February 3, 2015 12:08 pm, Les Mikesell wrote: > On Tue, Feb 3, 2015 at 11:48 AM, Valeri Galtsev > wrote: >> >>> I think the intent is: "Don't use a password likely to be included in >>> the list that an attacker would try". Of course if services would >>> rate-limit the failures >> >> Which sysadmins do for ages when they configure their machines. And I >> don't think any system will ever come from system vendor fully prepared >> to >> serve anything necessary, and tightened to best requirements (which >> depend >> on box designation anyway). > > Really? Are vendors not capable of shipping something with good > default settings? It seems like getting a new car and having to > install a different engine yourself because the factory couldn't > figure out how to do it. > >> So, system vendors can do better, but there >> always will be need for you to do your sysadmin's part. > > If that were really true, then you also wouldn't be able to follow > anyone else's advice about how to do it. That is, if your system > really needs to be so different that it couldn't have been shipped > with the configuration you need, then a book couldn't tell you that > either. > >> Sounds almost like >> job security. As one of my friends says: all systems suck, and thanks to >> that got our jobs ;-) > > But wouldn't you rather be doing something new/different instead of > just fixing things that should have been done right in the first > place? > Sounds so I almost have to feel shame for securing my boxes no matter what job vendor did ;-) Just a simple example: I have at least 3 classes of boxes configured ultimately different and having very different level of security/fortification. Do you seriously suggest that system vendor will ship all three level of security configurations? Do you seriously think that needing quite high level of security for some box I will not go over all settings influencing it myself? Will you not? We are not Windows admins, we rely on what we configure or check ourselves. And we do take security seriously, so, we do go over everything whether the system vendor does or does not claim they have done that part already (and and claim they did it better than I can do it). If you prefer to delegate what you are responsible for (security of your box) totally to someone else (even as good guys as system vendor is), then I don't know what to tell you. Yet, I'm sure, majority Unix sysadmins will still do what I do: go over everything themselves. No matter what someone says. Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 3, 2015 at 12:24 PM, Valeri Galtsev wrote: > > Sounds so I almost have to feel shame for securing my boxes no matter what > job vendor did ;-) Yes, computers and the way people access them are pretty much a commodity now. If you are spending time building something exotic for a common purpose, isn't that a waste? > Just a simple example: I have at least 3 classes of boxes configured > ultimately different and having very different level of > security/fortification. Do you seriously suggest that system vendor will > ship all three level of security configurations? Yes, 3 seems about right. > Do you seriously think > that needing quite high level of security for some box I will not go over > all settings influencing it myself? Will you not? Of course, but only because the vendor does not do it. I think Red Hat's engineers are capable of it if they wanted to. > We are not Windows > admins, we rely on what we configure or check ourselves. Not sure what you mean by that. Windows is much worse since the configurations tend to be hidden and the ways to do things interactively and scripted are wildly different. > Yet, I'm sure, majority Unix sysadmins will still do what I do: go over > everything themselves. No matter what someone says. There are probably still people that take their cars apart to check that they were assembled correctly too. But that doesn't mean that things should not be shipped with usable defaults. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, February 3, 2015 12:39 pm, Les Mikesell wrote: > On Tue, Feb 3, 2015 at 12:24 PM, Valeri Galtsev > wrote: >> >> Sounds so I almost have to feel shame for securing my boxes no matter >> what >> job vendor did ;-) > > Yes, computers and the way people access them are pretty much a > commodity now. If you are spending time building something exotic for > a common purpose, isn't that a waste? Do I have to take that people who are not sysadmins themselves just hate an existence of sysadmins? > >> Just a simple example: I have at least 3 classes of boxes configured >> ultimately different and having very different level of >> security/fortification. Do you seriously suggest that system vendor will >> ship all three level of security configurations? > > Yes, 3 seems about right. > >> Do you seriously think >> that needing quite high level of security for some box I will not go >> over >> all settings influencing it myself? Will you not? > > Of course, but only because the vendor does not do it. I think Red > Hat's engineers are capable of it if they wanted to. Here is the difference between us. I refuse to trust something ultimately important which I can check or tune without checking (and tuning if necessary). It will be my laziness. Note, that that I apply to myself. What you do is up to you (and you bear consequences of your decision, and I bare consequences oi mine). > >> We are not Windows >> admins, we rely on what we configure or check ourselves. > > Not sure what you mean by that. Windows is much worse since the > configurations tend to be hidden and the ways to do things > interactively and scripted are wildly different. > >> Yet, I'm sure, majority Unix sysadmins will still do what I do: go over >> everything themselves. No matter what someone says. > > There are probably still people that take their cars apart to check > that they were assembled correctly too. But that doesn't mean that > things should not be shipped with usable defaults. > No, I'm not the driver of my cars, I mean computers. I am a mechanic of racing car competition team, my cars go into competition, and the life of driver riding it depends on me having taken the whole mechanism apart, and making sure nothing breaks and kills driver and hundreds of spectators. I really hate these car analogies. They are counter-productive. In your eyes my server is indeed a commodity, which I refuse to agree with pretty much like I refuse to join ipad generation. My ipad would be commodity, but I for one will never trust that ipad and will not originate connection to secure box from it. Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 3, 2015 at 1:01 PM, Valeri Galtsev wrote: > >> >> Yes, computers and the way people access them are pretty much a >> commodity now. If you are spending time building something exotic for >> a common purpose, isn't that a waste? > > Do I have to take that people who are not sysadmins themselves just hate > an existence of sysadmins? No, I think there are better things for sysadmins to do than fix settings that should have had better defaults. >> There are probably still people that take their cars apart to check >> that they were assembled correctly too. But that doesn't mean that >> things should not be shipped with usable defaults. >> > > No, I'm not the driver of my cars, I mean computers. I am a mechanic of > racing car competition team, my cars go into competition, and the life of > driver riding it depends on me having taken the whole mechanism apart, and > making sure nothing breaks and kills driver and hundreds of spectators. So don't you think it would be a good thing if the thing was built so it didn't break in the first place? That is, so nobody gets killed running it as shipped, even it they don't have your magical expertise? > I really hate these car analogies. They are counter-productive. In your > eyes my server is indeed a commodity, which I refuse to agree with pretty > much like I refuse to join ipad generation. My ipad would be commodity, > but I for one will never trust that ipad and will not originate connection > to secure box from it. The point I'm trying to make is that whatever setting you might make on one computer regarding security would probably be suitable for a similar computer doing the same job in some other company. And might as well have been the default or one of a small range of choices. And in particular, rate limiting incorrect password attempts and/or providing notifications about them by default would not be a bad thing. Unless there's some reason you need brute-force attacks to work... -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 3, 2015 at 9:34 AM, Always Learning wrote: > > On Mon, 2015-02-02 at 20:26 -0800, PatrickD Garvey wrote: >> >> The CentOS wiki pages found by a title page search are: >> http://wiki.centos.org/HelpOnConfiguration/SecurityPolicy >> http://wiki.centos.org/HowTos/Security >> http://wiki.centos.org/Security >> http://wiki.centos.org/Security/Heartbleed >> http://wiki.centos.org/Security/POODLE >> http://wiki.centos.org/Security/Shellshock > > > 1. HelpOnConfiguration/SecurityPolicy = 2007-04-01 > > 1(a). Link 'SecurityPolicy' = HTML status code 404 > 1(b). Link 'MoinMoin' = 2007-04-01 > > 2. HowTos/Security = 2010-02-19 (RHEL 5) > > 3. Security = 2014-10-16 and refer to Heartbleed, Shellshock, POODLE > > > > *** NOTHING about Firewalls (IP Tables) *** > > I agree, this is not good. Come do as I have done. I followed the instructions at http://wiki.centos.org/Contribute#head-42b3d8e26400a106851a61aebe5c2cca54dd79e5 After I had edited my home page, I copied three pages into subpages of my home page (Be careful to remove any security restrictions.) and edited them as I saw fit. All three of my pull requests have been accepted. I'm working on further improvements to the Download page, at the moment. I would love to review the improvements you may make to any page of the wiki. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 12:39 -0600, Les Mikesell wrote: > There are probably still people that take their cars apart to check > that they were assembled correctly too. Its about taking personal responsibility for the security of your system(s). Trusting someone else's settings of what THEY think YOUR security should be, is very unwise. It is not car disassembly - it is checking the oil level, the benzin (petrol), the brake fluid, the window washer liquid, the tyre pressures including the 'spare wheel'. Pilots of aircraft do exactly the same. It is called a preflight check. Doing that on a new Centos installation is sensible and, if one cares about security, desirable. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 13:01 -0600, Valeri Galtsev wrote: > I for one will never trust that ipad and will not originate connection > to secure box from it. +1. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 13:15 -0600, Les Mikesell wrote: > No, I think there are better things for sysadmins to do than fix > settings that should have had better defaults. How can any SysAdmin (= System Administrator) administer something he or she is uncertain about ? The job of any system administrator is to poke their nose in and ensure everything is absolutely fine. No looking or no checking can not provide the necessary reassurance everything is absolutely fine *AND SAFE*. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 3, 2015 at 11:15 AM, Les Mikesell wrote: > On Tue, Feb 3, 2015 at 1:01 PM, Valeri Galtsev > wrote: >> Perhaps the Simplified Linux Server Special Interest Group http://wiki.centos.org/SpecialInterestGroup/SLS could benefit from contributions from each of you? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 3, 2015 at 1:30 PM, Always Learning wrote: > >> There are probably still people that take their cars apart to check >> that they were assembled correctly too. > > Its about taking personal responsibility for the security of your > system(s). Trusting someone else's settings of what THEY think YOUR > security should be, is very unwise. Maybe It is at least equally unwise to think that you are the only expert and all the people who are supposed to know what they are doing are wrong. That's why we have measles again... I'd rather see some real experts set up usable defaults instead of every person doing an install having to second-guess it. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, February 3, 2015 1:15 pm, Les Mikesell wrote: > On Tue, Feb 3, 2015 at 1:01 PM, Valeri Galtsev > wrote: >> >>> >>> Yes, computers and the way people access them are pretty much a >>> commodity now. If you are spending time building something exotic for >>> a common purpose, isn't that a waste? >> >> Do I have to take that people who are not sysadmins themselves just hate >> an existence of sysadmins? > > No, I think there are better things for sysadmins to do than fix > settings that should have had better defaults. Disagree. Ensure of security of the box is sysadmin's duty. It is in job description. Job to be done. > >>> There are probably still people that take their cars apart to check >>> that they were assembled correctly too. But that doesn't mean that >>> things should not be shipped with usable defaults. >>> >> >> No, I'm not the driver of my cars, I mean computers. I am a mechanic of >> racing car competition team, my cars go into competition, and the life >> of >> driver riding it depends on me having taken the whole mechanism apart, >> and >> making sure nothing breaks and kills driver and hundreds of spectators. > > So don't you think it would be a good thing if the thing was built so > it didn't break in the first place? That is, so nobody gets killed > running it as shipped, even it they don't have your magical expertise? I regret I let myself be dragged into car analogy. Once again, I'm not "driving" my machines. > >> I really hate these car analogies. They are counter-productive. In your >> eyes my server is indeed a commodity, which I refuse to agree with >> pretty >> much like I refuse to join ipad generation. My ipad would be commodity, >> but I for one will never trust that ipad and will not originate >> connection >> to secure box from it. > > The point I'm trying to make is that whatever setting you might make > on one computer regarding security would probably be suitable for a > similar computer doing the same job in some other company. And might > as well have been the default or one of a small range of choices. > And in particular, rate limiting incorrect password attempts and/or > providing notifications about them by default would not be a bad > thing. Unless there's some reason you need brute-force attacks to > work... It is possible that system vendor does what you call better job. I do welcome, e.g., "--hitcount" iptables option used in firewall CentOS comes with. (But some may hate that, and I respect their demand for their boxes). This doesn't mean I will not take a look into configuration at least once, and add what I have "certified" in my kickstart file. This probably is where we do diverge. I do not configure all end every box, I do necessary job with one system class for each of OS releases... --> kickstart, but minor tweaks may still be necessary depending on particular tasks on the box. Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, February 3, 2015 1:37 pm, PatrickD Garvey wrote: > On Tue, Feb 3, 2015 at 11:15 AM, Les Mikesell > wrote: >> On Tue, Feb 3, 2015 at 1:01 PM, Valeri Galtsev >> wrote: >>> > Perhaps the Simplified Linux Server Special Interest Group > http://wiki.centos.org/SpecialInterestGroup/SLS > could benefit from contributions from each of you? This sounds flattering, but no, I'm done with that, no noise from me here ;-) so... unless someone wants to pipe that. And improve the statements. And one can put his name under that. As at least what I was saying is so common knowledge IMHO. Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 11:21 -0800, PatrickD Garvey wrote: > > *** NOTHING about Firewalls (IP Tables) *** > I agree, this is not good. > Come do as I have done. > I followed the instructions at > http://wiki.centos.org/Contribute#head-42b3d8e26400a106851a61aebe5c2cca54dd79e5 3. Contribute to the Wiki Create a login with a username in the format: FirstnameLastname. For example, if your name is John Doe, the username to be created would be JohnDoe. Other variations, such as johndoe, John Doe, John_Doe, John, johnny123numbers, Mister Doe, JustSomeEditor etc. will not be accepted. That is a bad beginning. They don't want talent just complete subservience. Since when has a user name been more important that the donation of learning, advice, guidance etc ? 'AlwaysLearning', 'alwayslearning' and 'MrLearning' makes me ineligible to post a Centos wiki page. Far better to post on one of my sites than within the restrictive Centos environment. Seen 'Centos Pulse' ? http://wiki.centos.org/Newsletter "The CentOS Pulse Newsletter is an important tool to communicate within the community. It is run by the community to collect interesting bits from the wiki, mailinglist, fora, SIGs and other sources, and put them into the spotlight." First edition = 2009-06-02 Last edition = 2010-06-09 > I would love to review the improvements you may make to any page of the wiki. Post the URL of your page. I like the idea of a 'Centos Learning' mailing list, as previously described. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On 2/3/2015 11:57 AM, Always Learning wrote: 'AlwaysLearning', 'alwayslearning' and 'MrLearning' makes me ... ... an anonymous troll. -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 13:37 -0600, Les Mikesell wrote: > On Tue, Feb 3, 2015 at 1:30 PM, Always Learning wrote: > > > > Its about taking personal responsibility for the security of your > > system(s). Trusting someone else's settings of what THEY think YOUR > > security should be, is very unwise. > Maybe It is at least equally unwise to think that you are the only > expert and all the people who are supposed to know what they are doing > are wrong. That's why we have measles again... I'd rather see some > real experts set up usable defaults instead of every person doing an > install having to second-guess it. Nothing wrong with letting "an expert" preconfigure the system and then, after installation, the SysAdmin checking to ensure all the settings satisfy the SysAdmin's requirements. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 03, 2015 at 08:03:35PM +, Always Learning wrote: > Nothing wrong with letting "an expert" preconfigure the system and then, > after installation, the SysAdmin checking to ensure all the settings > satisfy the SysAdmin's requirements. Wouldn't that be like having the OS installer require strict passwords, and then have the sysadmin install a less-secure password on test systems after the system is loaded? -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 3, 2015 at 11:57 AM, Always Learning wrote: > > On Tue, 2015-02-03 at 11:21 -0800, PatrickD Garvey wrote: > >> I would love to review the improvements you may make to any page of the wiki. > > Post the URL of your page. > http://wiki.centos.org/PatrickDGarvey ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 3, 2015 at 2:03 PM, Always Learning wrote: > > Nothing wrong with letting "an expert" preconfigure the system and then, > after installation, the SysAdmin checking to ensure all the settings > satisfy the SysAdmin's requirements. > I'd just rather see them applying their expertise to actually making the code resist brute-force password attacks instead of stopping the install until I pick a password that I'll have to write down because they think it will take longer for the brute-force attack to succeed against their weak code. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 11:59 -0800, John R Pierce wrote: > On 2/3/2015 11:57 AM, Always Learning wrote: > > 'AlwaysLearning', 'alwayslearning' and 'MrLearning' makes me ... > > ... an anonymous troll. That type of reaction dissuades people from contributing to the List. Why don't you personally endorse the creation of a 'Centos Learning' mailing list to complement the other Centos Lists ? -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 15:05 -0500, Jonathan Billings wrote: > On Tue, Feb 03, 2015 at 08:03:35PM +, Always Learning wrote: > > Nothing wrong with letting "an expert" preconfigure the system and then, > > after installation, the SysAdmin checking to ensure all the settings > > satisfy the SysAdmin's requirements. > Wouldn't that be like having the OS installer require strict > passwords, and then have the sysadmin install a less-secure password > on test systems after the system is loaded? Flexibility is not excluded. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 12:06 -0800, PatrickD Garvey wrote: > On Tue, Feb 3, 2015 at 11:57 AM, Always Learning wrote: > > > > On Tue, 2015-02-03 at 11:21 -0800, PatrickD Garvey wrote: > > > >> I would love to review the improvements you may make to any page of the > >> wiki. > > > > Post the URL of your page. > > > > http://wiki.centos.org/PatrickDGarvey Impressive "Any time we aren't inclusive, we lose." but first it is necessary to have that sort of philosophy as a fundamental principle of Centos. How about some support, on this list, for the creation of a Centos Learning mailing list ? -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 03, 2015 at 02:10:31PM -0600, Les Mikesell wrote: > I'd just rather see them applying their expertise to actually making > the code resist brute-force password attacks instead of stopping the > install until I pick a password that I'll have to write down because > they think it will take longer for the brute-force attack to succeed > against their weak code. ... The installer has MANY MANY defaults that are decided to produce a good starting point. Setting a root password that meets an extremely low bar in terms of security was one of those decisions. Honestly, of all the faults and foibles in the Red Hat/CentOS installer, I'm amazed that someone is complaining about that. "Oh No! They released a product that's *incrementally* more secure than before! Heavens Above! (faints)" If you honestly are so unable to remember a password for longer than 20 minutes, then I suggest using a kickstart to set the root password with a crypted hash. Or have a %post script replace whatever you typed in the password prompt with your insecure password. This is one of those decisions many software products have to make: Weighing the general security gained by requiring somewhat more secure passwords against the inconvenience of having to remember a somewhat more secure password. Since it's possible to get around the requirement in multiple ways, it makes sense to lean toward the more secure option. Make it inconvenient to be less secure. -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 14:10 -0600, Les Mikesell wrote: > On Tue, Feb 3, 2015 at 2:03 PM, Always Learning wrote: > > > > Nothing wrong with letting "an expert" preconfigure the system and then, > > after installation, the SysAdmin checking to ensure all the settings > > satisfy the SysAdmin's requirements. > I'd just rather see them applying their expertise to actually making > the code resist brute-force password attacks instead of stopping the > install until I pick a password that I'll have to write down because > they think it will take longer for the brute-force attack to succeed > against their weak code. Very sensible comment. I absolutely agree. Why do the Fedora Bunch think poncing-around with password lengths and composition is more important than extremely strong external security ? There should be a basic defence that when the password is wrong 'n' occasions the IP address is blocked automatically and permanently unless it is specifically allowed in IP Tables. If specifically allowed in IP Tables, there should be a predetermined wait time before another attempt can be made. Simple ! So why does Fedora prefer allowing the hackers unlimited opportunities to brute-force passwords ? -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 3, 2015 at 2:44 PM, Always Learning wrote: > > There should be a basic defence that when the password is wrong 'n' > occasions the IP address is blocked automatically and permanently unless > it is specifically allowed in IP Tables. The people who are good at this will make the attempts from many different IPs - and sometimes cycle through a dictionary of different login names too. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, Feb 03, 2015 at 02:10:31PM -0600, Les Mikesell wrote: > I'd just rather see them applying their expertise to actually making > the code resist brute-force password attacks instead of stopping the > install until I pick a password that I'll have to write down because > they think it will take longer for the brute-force attack to succeed > against their weak code. Also, it isn't up to the *installer* to set up a system that resists brute-force password attacks. That's a job for the default configuration files in OpenSSH, GDM, KDM, and any other software product that reads the password database. All the installer can do is read in the plain-text password, check to make sure it passes a minimum policy, then crypt it and put it in the shadow file. There are certainly things that could change, like having the pam configuration have pam_faillock on by default. But I tend to think that having brute-force resistance *AND* slightly better password security should be the goal, not one to the exclusion of the other. -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 14:48 -0600, Les Mikesell wrote: > On Tue, Feb 3, 2015 at 2:44 PM, Always Learning wrote: > > > > There should be a basic defence that when the password is wrong 'n' > > occasions the IP address is blocked automatically and permanently unless > > it is specifically allowed in IP Tables. > > The people who are good at this will make the attempts from many > different IPs - and sometimes cycle through a dictionary of different > login names too. If 'n' is low, perhaps '2', then brute forcing will become more protracted. An addition to my proposal, is allocate all sensitive users to a special group and limit the membership of that group to a maximum of, for example, 3 wrong password attempts within a SysAdmin chosen time interval. Simple. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On 4 February 2015 at 02:17, James B. Byrne wrote: > I think it well to recall that the change which instigated this > tempest was not to the network operations of a RHEL based system but > to the 'INSTALLER' process, Anaconda. Now, I might be off base on > this but really, ask yourself: Who exactly uses an installer program? > And what is the threat model being addressed by requiring that the > installer set a suitably strong password for root? For what purpose? > Because RHEL sets the sshd on and allows root access over ssh via > password by default? Then is not the correct approach to disable that > access instead? Good points. Consider a user who installs RHEL with a poor root password and reboots while connected to the internet. At that point they are potentially vulnerable. How long will it take for them to get around to improving the password? Probably a long time, unless they are security conscious, in which case they probably would have opted for a strong password from the start. Not allowing root ssh access immediately after an install is a much bigger imposition. You would have to insist that there was a second user on the system with a strong password. I think that is a good idea too, by the way. Requiring a strong root password really is a small imposition, unless you are doing a lot of manual installs and in which case you should look into automation. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 15:51 -0500, Jonathan Billings wrote: > Also, it isn't up to the *installer* to set up a system that resists > brute-force password attacks. Give us the tools to do the job ! My amalgamated idea is:- (1) When external access gets a password wrong 'n' occasions, as determined by the SysAdmin, the external IP address is automatically permanently blocked unless that IP is included in a IP Tables 'allow' table. (2) If specifically allowed in IP Tables, that IP be blocked for 'm' minutes, as determined by the SysAdmin, before another attempt can be made. (3) All sensitive users be added to a special group. Limit the membership of that group to a collective maximum of 'n' SysAdmin chosen wrong password attempts within a time interval of 't' chosen by the SysAdmin. Baffled why it has never been done but then I'm Always Learning. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On 2/3/2015 1:22 PM, Always Learning wrote: Baffled why it has never been done but then I'm Always Learning. 'fail2ban' with a bit of configuration for your exceptions. -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On 2015-02-03 22:22, Always Learning wrote: > > On Tue, 2015-02-03 at 15:51 -0500, Jonathan Billings wrote: > >> Also, it isn't up to the *installer* to set up a system that resists >> brute-force password attacks. > > Give us the tools to do the job ! > > My amalgamated idea is:- > > (1) When external access gets a password wrong 'n' occasions, as > determined by the SysAdmin, the external IP address is automatically > permanently blocked unless that IP is included in a IP Tables 'allow' > table. > > (2) If specifically allowed in IP Tables, that IP be blocked for 'm' > minutes, as determined by the SysAdmin, before another attempt can be > made. > > (3) All sensitive users be added to a special group. Limit the > membership of that group to a collective maximum of 'n' SysAdmin chosen > wrong password attempts within a time interval of 't' chosen by the > SysAdmin. > > Baffled why it has never been done but then I'm Always Learning. > > > I am maybe mislead, but I thought that is exactly what fail2ban[1] would do and this is already a few years out. Also it is ,if I remember correctly, in epel. Regards, Markus [1] http://www.fail2ban.org/wiki/index.php/Main_Page ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Feb 3, 2015, at 8:17 AM, James B. Byrne wrote: > > Who exactly uses an installer program? We do. Kickstart never really met our needs, and all these now-common CM systems came out way after we had shell-scripted our post-install setup adequately. To go back and rebuild everything in Puppet or similar would be a pointless waste of time. > Because RHEL sets the sshd on and allows root access over ssh via > password by default? Then is not the correct approach to disable that > access instead? Red Hat should do that in EL8, too. Defense in depth. > Is it not true that the network services are not started by > default? So, exactly where is the threat? Does it not occur much, > much later in the workflow than at the installer? Not in our scheme. We set our NICs to come up on boot because we need that in order to pull all the post-installation configuration files, packages, resource files, etc. over from the file server. We also do a “yum update” pass early in the setup process to close any security holes that have opened up since the last EL point release was cut. We don’t assign a per-system unique password until the system is almost completely set up and ready to deploy. This step is part of our automatic registration of the new box with our dev ops system, so we can use the new hardened login credentials to get back into the box. Until that point, we need to have a password that’s easily type-able, so we use something short and weak. After that point, we’re using an automatic login scheme based on huge passwords and keys. Not that I’m suddenly crying about this EL8 change. We’ll just switch from our current pitiful temporary password to something that barely passes the new restrictions. No big deal. > 2.) root access over the > network is allowed via RSA only; If you check the “make this user an admin” box in EL7 on the screen that creates the non-root user, it gets added to the wheel group, which *finally* in EL7 allows it to use sudo out of the box. Therefore, a weak non-root admin user password is as good as a weak root password. So, your choice is to either not use this feature, or take the new EL8 password rules as the improvement they are intended to be. > 3.) if root can log in via ssh using > a password then the root password must be strong? Of course. SSH has rate-limiting built in, and I believe PAM has some that stacks with it, but if the password is too weak, you can still brute-force it despite that. > This change to Anaconda is not security, it is theatre. It is directly > equivalent to airport passenger security checks. I don’t think so. Defaults matter. An installer that lets you use weak passwords *guarantees* that people will use weak passwords, and never change them. A better airport analogy is the requirement to fasten seatbelts on takeoff and landing. This addresses an actual risk with an inexpensive and low-hassle fix: incidents almost never turn into crashes when the pilot has a lot of altitude to play with. > In any case, allowing an eight character password on credentials > exposed to public network access is laughable. I’m not so sure about that. While it is true that it is now possible to generate arbitrary 8-character random password rainbow tables without spending ridiculous sums of money, that does not mean you can use the same technology to brute-force a Linux box’s password. To do that, you’d have to have the contents of /etc/shadow, which means you’re already root. Game over. If the only attack vector is over a rate-limited remote connection, it will take you to the heat death of the universe to brute-force an 8-character password. The place you don’t want to use an 8-character password today is on a web site with poor security. Such a site probably isn’t salting passwords even if they hare hashing them, and pulling the credential table probably doesn’t require root privileges. It’s quite a different threat model from the one the Linux login system addresses. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] user nobody can't access file
Hey guys, I need to give the 'nobody' user (which is what our apache runs as) no password access to a file, via sudo. This is what I've tried: nobody ALL=(ALL) NOPASSWD: /var/www/qa/launchpadnew/site/ftp_check.php But if I become the nobody user and try to access the file, it tries to prompt me for a password: -bash-3.2$ php /var/www/qa/launchpadnew/site/ftp_check.php [sudo] password for nobody: Can someone please point out for me where I'm going wrong? Cuz I don't see it!! Thanks ! :) Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] user nobody can't access file
try "sudo php /var/www/qa/launchpadnew/site/ftp_check.php" and "sudo /var/www/qa/launchpadnew/site/ftp_check.php" You're giving the user the ability to run /var/www/qa/launchpadnew/site/ftp_check.php but not necessarily php. Your script might not need it, so try it each way. And, since you're using sudo, you need to call "sudo" before the command. On Tue, Feb 3, 2015 at 5:32 PM, Tim Dunphy wrote: > Hey guys, > > I need to give the 'nobody' user (which is what our apache runs as) no > password access to a file, via sudo. This is what I've tried: > > nobody ALL=(ALL) NOPASSWD: > /var/www/qa/launchpadnew/site/ftp_check.php > > But if I become the nobody user and try to access the file, it tries to > prompt me for a password: > > -bash-3.2$ php /var/www/qa/launchpadnew/site/ftp_check.php > [sudo] password for nobody: > > Can someone please point out for me where I'm going wrong? Cuz I don't see > it!! > > Thanks ! :) > > Tim > > > > > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > ___ > 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] Another Fedora decision
On 2015-02-03, Markus wrote: > On 2015-02-03 22:22, Always Learning wrote: >> >> (1) When external access gets a password wrong 'n' occasions, as >> determined by the SysAdmin, the external IP address is automatically >> permanently blocked unless that IP is included in a IP Tables 'allow' >> table. >> >> (2) If specifically allowed in IP Tables, that IP be blocked for 'm' >> minutes, as determined by the SysAdmin, before another attempt can be >> made. >> >> (3) All sensitive users be added to a special group. Limit the >> membership of that group to a collective maximum of 'n' SysAdmin chosen >> wrong password attempts within a time interval of 't' chosen by the >> SysAdmin. > > I am maybe mislead, but I thought that is exactly what fail2ban[1] would > do and this is already a few years out. Also it is ,if I remember > correctly, in epel. sshguard can also do this (not sure if it's in EPEL or another common repo). http://www.sshguard.net More paranoid sysadmins simply disable all password logins and make users use ssh keys instead. --keith -- kkel...@wombat.san-francisco.ca.us ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] user nobody can't access file
On Tue, February 3, 2015 4:32 pm, Tim Dunphy wrote: > Hey guys, > > I need to give the 'nobody' user (which is what our apache runs as) no > password access to a file, via sudo. This is what I've tried: > > nobody ALL=(ALL) NOPASSWD: > /var/www/qa/launchpadnew/site/ftp_check.php > > But if I become the nobody user and try to access the file, it tries to > prompt me for a password: > > -bash-3.2$ php /var/www/qa/launchpadnew/site/ftp_check.php > [sudo] password for nobody: > > Can someone please point out for me where I'm going wrong? Cuz I don't see > it!! > This whole thing sounds scary... Is there really no other (less scary) way to achieve what you want to achieve? Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] user nobody can't access file
On 2/3/2015 2:32 PM, Tim Dunphy wrote: -bash-3.2$ php /var/www/qa/launchpadnew/site/ftp_check.php [sudo] password for nobody: where did sudo even come into this picture? does this ftp_check.php script fork a shell with sudo or something? sounds like a VERY bad way of doing whatever it is you're trying to do. -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
Scott Robbins wrote: > On Tue, Feb 03, 2015 at 01:53:45PM +, Timothy Murphy wrote: >> >> The 7 rules listed in this URL seem utterly bizarre to me. >> >> The first is "Don't use a palindrome" >> which makes me wonder if the author knows the meaning of this word. >> I suspect he/she thinks it means "a known word backwards". > That's what I would call it (or phrase or sequence of numbers.) When I > read your post, I thought I was missing something, but some cursory > googling indicates that I'm right. What am I missing here? I don't follow your meaning. Do you think yraM is a palindrome? Merriam-Webster (online) a word, verse, or sentence (as “Able was I ere I saw Elba”) or a number (as 1881) that reads the same backward or forward I can't believe many people use palindromes as passwords. -- Timothy Murphy gayleard /at/ eircom.net School of Mathematics, Trinity College, Dublin ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Wed, Feb 04, 2015 at 12:34:20AM +, Timothy Murphy wrote: > Scott Robbins wrote: > > > On Tue, Feb 03, 2015 at 01:53:45PM +, Timothy Murphy wrote: > >> > >> The 7 rules listed in this URL seem utterly bizarre to me. > >> > >> The first is "Don't use a palindrome" > >> which makes me wonder if the author knows the meaning of this word. > >> I suspect he/she thinks it means "a known word backwards". > > > That's what I would call it (or phrase or sequence of numbers.) When I > > read your post, I thought I was missing something, but some cursory > > googling indicates that I'm right. What am I missing here? > > I don't follow your meaning. > Do you think yraM is a palindrome? Ah, your original sentence was originally quite clear, but I managed to misunderstand it, thinking you meant a word that is the same backwards and forwards, as opposed to what you clearly defined. Sorry. I guess my mind filled in the spaces or something. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On Tue, 2015-02-03 at 15:02 +1100, Kahlil Hodgson wrote: > Thinking about you systems from a penetration testing perspective can > be helpful. For example, "Always Learning" has just told us that he > uses single character root passwords on his testing machines, that he > is testing 7 days a week and does not turn off his test machines. Yes single character. Writing and testing usually 7 days weekly. Turn off everything when not in use including test machines. No connection to the Internet. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Another Fedora decision
On 4 February 2015 at 14:36, Always Learning wrote: >> Thinking about you systems from a penetration testing perspective can >> be helpful. For example, "Always Learning" has just told us that he >> uses single character root passwords on his testing machines, that he >> is testing 7 days a week and does not turn off his test machines. > > Yes single character. > Writing and testing usually 7 days weekly. > Turn off everything when not in use including test machines. > > No connection to the Internet. Sorry. Must have misunderstood your earlier comments. Sounds like a fairly specialized work-flow. You might want to consider using an updates.img that removes the password strength requirements (see http://fedoraproject.org/wiki/Anaconda/Updates). The anaconda installer is fairly straight forward Python code. I haven't got a copy on me at the moment, but at a guess, all you need to do is track down the relevant lines and comment them out. Hope this helps. Kal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] user nobody can't access file
Hi, On Wed, Feb 4, 2015 at 4:57 AM, John R Pierce wrote: > On 2/3/2015 2:32 PM, Tim Dunphy wrote: > >> -bash-3.2$ php /var/www/qa/launchpadnew/site/ftp_check.php >> [sudo] password for nobody: >> > In sudoers file, you have to provide the whole path of the "php" command to execute any php file. > > where did sudo even come into this picture? > > does this ftp_check.php script fork a shell with sudo or something? > > sounds like a VERY bad way of doing whatever it is you're trying to do. > I agree with John here. You should use better method to do this. --Regards Ashishkumar S. Yadav ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
