Re: [CentOS] Apache and web content permissions

[Pete Travis]

Hi Niki,

The principle to work by here is 'least required access'.  There's two
functional types of users we care about, the one executing the PHP
code (probably apache or php-fpm) and admins like yourself with
FTP/shell access.  Upstream wordpress documents application write
requirements at
https://codex.wordpress.org/Hardening_WordPress#File_Permissions -
read it to know where the web server will expect write access, but
don't follow the instructions - especially the numbers for chmod - by
rote!

On Sat, Dec 2, 2017 at 3:30 AM, Nicolas Kovacs  wrote:
>
> Hi,
>
> Until a few months ago, when I had to setup a web server under CentOS, I
> assigned (I'm not sure about the correct english verb for "chown"ing)
> all the web pages to the apache user and group. To give you an example,
> let's say I have a static website under /var/www/myserver on a CentOS
> server running Apache. Then I would configure permissions for the web
> content like this:
>
> # chown -R apache:apache /var/www/myserver
> # find /var/www/myserver -type d -exec chmod 0750 {} \;
> # find /var/www/myserver -type f -exec chmod 0640 {} \;
>
> Some time ago a fellow sysadmin (Remi Collet on the fr.centos.org forum)
> pointed out that this is malpractice in terms of security, and that the
> stuff under /var/www should *not* be owned by the user/group running the
> webserver.


Right, this gives Apache write access over *everything*.  That means
that Apache could potentially change your site code.  Many attack
vectors rely on changing wordpress files or creating new files, so
this should not be possible.

> Which means that for the static website above, I could have
> something like this, for example:
>
> # chown -R microlinux:microlinux /var/www/myserver
> # find /var/www/myserver -type d -exec chmod 0755 {} \;
> # find /var/www/myserver -type f -exec chmod 0644 {} \;
>
> Or even this:
>
> # chown -R nobody:nobody /var/www/myserver
> # find /var/www/myserver -type d -exec chmod 0755 {} \;
> # find /var/www/myserver -type f -exec chmod 0644 {} \;


I don't like the convention of creating an arbitrarily named user to
own website files.  Nicolas is logging in and working on the server,
make an ie nkovacs user for yourself to do your work.  Shared hosting
companies tend to follow the "one FTP user named after website" or
"one shell user named after customer" model and expect their customers
to share a single login account, but if you have root access to the
server there's no restrict yourself this way.  It also leads to a
solution where a group of folks who need to work on the site will
share the single login account, making it impossible to answer
questions like "who changed this file" or "who is logged in right
now".  If any kind of compliance is a concern, generic/anonymous login
is a no-go.  If compliance is not a concern, there's still no real
benefit to making up usernames for yourself on a production system
that are not your own name, and sharing credentials is still bad
practice in principle.

>
> Now I'm hosting quite a few Wordpress sites on various CentOS servers.
> Some stuff in Wordpress has to be writable by Apache. If I want to keep
> stuff as secure as possible, here's the permissions I have to define.
>
> # cd /var/www
> # chown -R microlinux:microlinux wordpress-site/
> # find wordpress-site/ -type d -exec chmod 0755 {} \;
> # find wordpress-site/ -type f -exec chmod 0644 {} \;
> # cd wordpress-site/html
> # chown -R microlinux:apache wp-content/
> # find wp-content/ -type d -exec chmod 0775 {} \;
> # find wp-content/ -type f -exec chmod 0664 {} \;
>
> As far as I know, this is the most secure setup for Wordpress as far as
> permissions are concerned.


Wordpress plugins are in wp-content.  Allowing a wordpress plugin to
be compromised is functionally equivalent to allowing the core code to
be compromised, we do not want Apache to write plugin code.
`wp-content/uploads` is the only *stock* directory I'm aware of that
Wordpress *requires* write access too.  Some plugins might have
additional directories they write to, this should be documented for
each such plugin.

With an application like Wordpress, Apache only needs to create files
for things like images uploaded for posts.  It should never be allowed
to write in a directory where PHP files are.  Conversely, any
directory where it *can* write should not be used for PHP code.  You
can block that with the snippet below, again from upstream wordpress:


   # Kill PHP Execution
   
  deny from all
   


You might notice that I used a  block where the page I
linked to does not.  The upstream example has you drop a  block
into a .htaccess file; in that context, the  is implicitly
inherited from the immediate parent directory of the .htaccess file.
It's a convenient way to adjust Apache configuration if you do not
have privileged shell access, but it also means the .htaccess file
will be read and interpreted anew for *every request*.  You *do* have
privileged shell access, and can p

Re: [CentOS] OT: hardware, IBM 3650 M2 won't power on

[Pete Travis]

On Feb 22, 2017 4:27 PM,  wrote:

Styma, Robert (Nokia - US) wrote:
>
> Just for grins, pull off the cover and look at the electrolytic capacitors
> on the motherboard.
> Look for ones with the tops pushed up instead of being flat.  This can
> cause all sorts of odd behavior.  Often the machine with a blown capacitor
> will continue to run till it is powered off.Mostly I see this on Dell
> machines but have seen it on other machines as well.  They are pretty easy
> to unsolder and replace.  There are lots of pictures of failed
> electrolytic capacitors on the web. You can get decent capacitors cheap on
> Amazon.  I understand the problem when the powers that be will not allow
> you to spend money.  Now I work in a lab and have nice soldering equipment
> available  and can get away with a lot more than a production environment.
>  Maybe if your boss sees you taking a soldering iron to the machine he
> will let you buy a new machine. :-)
>
Thanks, that's a thought. The cover's already off But forget that, no
soldering here.

   mark



I'd try a power drain next. Unplug it, short the prongs on the plug
together, hold the power button down, wait a bit.  Maybe try powering it on
with one PSU alone then the other, if that's an option.

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

Re: [CentOS] About mysql upgrade

[Pete Travis]

On Apr 28, 2016 7:46 AM, "Sergio Belkin"  wrote:
>
> Hi,
>
>
> I've found some issues upgrading mysql, some people recommends run
> mysql_upgrade. I wonder why such a script is not run from scriptlet of
> mysql-server rpm.
>
> Thanks in advance
>
> --
> --
> Sergio Belkin
> LPIC-2 Certified - http:// www.l 
pi.o rg 
> ___

The general SOP is to restart mysql, then run mysql_upgrade, so the RPM
script would need to do both.  This brings you into database and
application management territory, and out of package management territory.
The RPM cannot know if it is acceptable and safe for the database to go
down, for  both your environment and organization.   Accordingly, as a
rule, RPMs should not affect running services.

Ubuntu/Debian packages *do* perform these actions on package update, and
I've seen it go horribly wrong. Like, the restart command hangs because of
long running queries, and the tablespace changes happen anyway, leaving the
daemon in a state where it cannot accept new connections because it was
shutting down, but cannot cleanly shut down because of the other actions in
the script.  You really want an admin to do this work, not an unattended
script.

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

Re: [CentOS] firewalld being stupid

[Pete Travis]

On Nov 6, 2015 3:31 PM, "Nick Bright"  wrote:
>
> Greetings,
>
> One of my biggest frustrations with CentOS 7 has been firewalld.
>
> Essentially all of the documentation just flat doesn't work.
>
> One common thing that needs to be done is to change the zone of an
interface, however I've tried:
>
> firewall-cmd --permanent --zone=internal --change-interface=ens192
> firewall-cmd --permanent --zone=internal --add-interface=ens192
>
> I've also tried setting in /etc/sysconfig/network-scripts/ifcfg-ens192:
>
> ZONE=internal
> ZONE="internal"
>
> No matter what, when firewalld starts, ens192 will be in the public zone.
>
> What am I doing wrong? Why does the documented command structure not work?
>
> --
> ---
> -  Nick Bright-

Firewalld does physical interfaces, NetworkManager has profiles on top of
them.  NM can specify a zone and communicate it to firewalld - which should
work from your ifcfg edit - but the reverse currently doesn't happen.  Try
with nmcli:

nmcli con modify ens19p0 connection.zone internal

...btw, the insertion of the 'p' was deliberate, I've seen more device
names of that form.  doublecheck your device name too.

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

Re: [CentOS] systemctl (again)

[Pete Travis]

On Apr 4, 2015 7:55 AM, "J Martin Rushton" 
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thanks Andrew.
>
> One more problem solved, as I discovered last thing yesterday there
> was a missing "[Install]".  Using your copy of the httpd service I
> cut-and-pasted it onto the end of the service file you'd given me
> earlier and at last was able to load the service.  It wouldn't run,
> but at least it was some progress.
>
> I ran systemctl daemon-reload and rebooted.
>
> It is still failing though:
>
> # systemctl status timidity
> timidity.service - timidity daemon
>Loaded: loaded (/etc/systemd/system/timidity.service; enabled)
>Active: failed (Result: exit-code) since Sat ...
>   Process: 955 ExecStop=/bin/kill -s TERM $MAINPID (code=exited,
> status=1/FAILURE)
>   Process: 790 ExecStart=/usr/bin/timidity -iAD (code=exited,
> status=0/SUCCESS)
>  Main PID: 790 (code=exited, status=0/SUCCESS)
>



The process exited, so systemd thinks the service has exited.  You have a
'-D' option, which probably means daemonize, but you haven't set an
appropriate Type declaration in the service file.

If the service offers it, the best way to do simple services with systemd
is with *foreground* options in ExecStart.  Then set Type=simple.
STDOUT/STDERR all goes to the journal, making it easier to see what happens
if the service legitimately fails.

Take a look at packaged files in /usr/lib/systemd/system - plenty of
examples to work from.

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

Re: [CentOS] Another Fedora decision

[Pete Travis]

On 02/09/2015 11:11 PM, Kahlil Hodgson wrote:
> On 10 February 2015 at 16:39, Pete Travis  wrote:
>> Officially, no, the "Fedora Documentation" bz product isn't there for
>> Red Hat guides.  If you want to file a bug against a RHEL guide, choose
>> your version of RHEL then look for the guide's component - these days,
>> they all start with "doc-", which should make the search easy.
>
> Thanks for the heads up. Was not aware of the 'doc-' prefix.
>
>> Unofficially, there's a nonzero chance that your bug will find a writer
>> that plays in both spaces, or that we'll be able reassign the bug to the
>> correct component for you.  But please, don't make work for Fedora
>> volunteers when there are people standing by getting paid to handle your
>> bugs :)
>
> As previously noted, the authors of both documents are the same, and
> appear to be RedHat employees.
> ___
>

Right, that's the non-zero thing I mentioned. Some Red Hat writers also
contribute to Fedora Docs, often on their own time.

-- 
-- Pete

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

Re: [CentOS] Another Fedora decision

[Pete Travis]

On 02/09/2015 11:11 PM, Kahlil Hodgson wrote:
> On 10 February 2015 at 16:39, Pete Travis  wrote:
>> Officially, no, the "Fedora Documentation" bz product isn't there for
>> Red Hat guides.  If you want to file a bug against a RHEL guide, choose
>> your version of RHEL then look for the guide's component - these days,
>> they all start with "doc-", which should make the search easy.
>
> Thanks for the heads up. Was not aware of the 'doc-' prefix.
>
>> Unofficially, there's a nonzero chance that your bug will find a writer
>> that plays in both spaces, or that we'll be able reassign the bug to the
>> correct component for you.  But please, don't make work for Fedora
>> volunteers when there are people standing by getting paid to handle your
>> bugs :)
>
> As previously noted, the authors of both documents are the same, and
> appear to be RedHat employees.
> ___
>

Right, that's the non-zero thing I mentioned. Some Red Hat writers also
contribute to Fedora Docs, often on their own time.

-- 
-- Pete

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

Re: [CentOS] Another Fedora decision

[Pete Travis]

On 02/09/2015 04:25 PM, PatrickD Garvey wrote:
> On Mon, Feb 9, 2015 at 3:23 PM, Kahlil Hodgson
>  wrote:
>> On 10 February 2015 at 10:15, PatrickD Garvey
 wrote:
>>> Please allow me to make sure I am perceiving this correctly,
>>> reports of errors found in RedHat documentation are to be reported
>>> against the Fedora Documentation product type in the RedHat bugzilla?
>>> and
>>> reports of errors found in Fedora documentation are, also, to be
>>> reported against the Fedora Documentation product type in the RedHat
>>> bugzilla?
>>
>> I don't know officially, but I'm making a guess that, since the two
>> documents are clearly related and have the same authors, if you see
>> the same error in the Fedora document and you report it, it will
>> probably get fixed in both.  The Fedora document explicitly solicits
>> bug reports, but I don't see the same in the RedHat one.  Worth a shot
>> don't you think?  Maybe submit a small bug report and see what the
>> response is like?
>
>
> That's a testable starting point. Thanks.
> ___
Officially, no, the "Fedora Documentation" bz product isn't there for
Red Hat guides.  If you want to file a bug against a RHEL guide, choose
your version of RHEL then look for the guide's component - these days,
they all start with "doc-", which should make the search easy.

Unofficially, there's a nonzero chance that your bug will find a writer
that plays in both spaces, or that we'll be able reassign the bug to the
correct component for you.  But please, don't make work for Fedora
volunteers when there are people standing by getting paid to handle your
bugs :)

-- 
-- Pete

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

Re: [CentOS] Documentation link on new Firefox CentOS 7 splash screen

[Pete Travis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/18/2015 12:29 PM, Digimer wrote:
> On 18/01/15 03:45 AM, Karanbir Singh wrote:
>> On 01/18/2015 02:14 AM, Mark LaPierre wrote:
>>> On 01/15/15 22:55, Darr247 wrote:
>>>> On 16 January 2015 @00:34 zulu, Digimer wrote:
>>>>> So either the link should be changed or the linked page should be
>>>>> updated.
>>>>>
>>>>
>>>> Well, until someone rewrites the redhat docs so they don't violate
>>>> copyright laws, and links to them on that centos.org/docs page, I'll
>>>> continue perusing and referring to the RHEL 6 and 7 documentation.
>>>> ___
>>>
>>> Alright then.  May I suggest a solution that might satisfy both
opinions.
>>>
>>> On the documentation page where the links to CentOS [345] are found
>>> place a statement to this effect:
>>>
>>> "CentOS is functionally equivalent to Red Hat Enterprise Linux (RHEL)
>>
>> but its not.
>>
>>> and is based on the same code, as released by Red Hat, and rebuilt by
>>> the CentOS community."  At this point briefly explain the moral
>>
>> that does not make it functionally equivalent.
>>
>>> conundrum that prevents you from linking directly to the RHEL
>>> documentation.  Then provide the appropriate link to the appropriate
>>> RHEL documentation with the explanation that, "this is a link to the
>>> documentation for RHEL upon which CentOS is based."  There you have a
>>> disclaimer as well as an attribution.
>>>
>>> What say yea to this proposal?
>>
>> why not just say 'CentOS Linux is derived from Red Hat Enterprise Linux
>> sources as released via git.centos.org and therefore documentation
>> applicable to Red Hat Enterprise Linux should largely apply to CentOS
>> Linux of the same version, architecture and release.'
>>
>> And leave it at that ( note: no linking, therefore no assertions of
>> compatibility or equivallencce ).
>>
>>> An undocumented computer program differs only slightly from a video
>>> game.  Both are filled with mysteries, puzzles, and unanswered
questions.
>>
>> Therefore, lets do the right thing - get the means together in community
>> to adapt those docs, brand them accordingly and publish them under
>> centos.org
>
> Is it legal to copy the documentation and replace trademarks? IANAL... :)
>
> Alternatively, if we can't copy RHEL docs, can we copy Fedora 12~13,
18~19 docs and adapt as needed? Or would be have to write everything
from scratch?
>

Yes, you can absolutely use the sources for Fedora Docs, providing the
already stated measures to deal with the trademark issues are
performed.  Everything is at https://git.fedorahosted.org/cgit/docs/ .

I would encourage anyone interested to delve in a bit more than copy +
regex though.  There are entities to interpolate, for example; we'd take
patches to replace "Fedora" with "&PRODUCT;" to make things easier for
the CentOS folks, for example - and in many places, you'll see things
like that already, because RHEL docs are downstream too.  A CentOS
publican brand would give the derivative books a distinct identity
without diverging the sources.  Or, some CentOS writers might want to
Storage Administration Guide, which hasn't been updated for a Fedora in
quite a while, and most updates for el7 would be great for the current
Fedora users too.

I'm sure there are many areas where active collaboration would be a win
for both distributions.  At this point, maybe the centos-docs and/or
d...@lists.fp.o lists would be a better venue?

- -- 
- -- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanet...@fedoraproject.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUvKSfAAoJEL1wZM0+jj2Z86IH/2aAgYYix4d3iJ0O9SEzXh6m
DEeD2PvNTigdWjrOIJ9+k32SEXWrdYOhUN4cN/72eHhKkU1XNOqFv90GLlCC85xH
4mDqYpudZfGQ2SbSNYEXtqo63C7/edAWdZ9WiaQRlehHLS0G8H6Cy8aSEsQu9OCU
ofg59TDbWmqy7YogPLZWTfoy/NEe+g9taRK0w0Zkv51Qy6sprH1Wl0cKF1FLqVUD
7Q2AOGGKWqmlze4VFpuZMPHhz3ieoge+yTYtUdt0bxFn8ZrXqBq9ldYOG/vSDPJY
5m0MqOdXKXhMy+XNQmrBnfX+C6+kNqFkbNe+7wH9FtOjhdqLJtpdtIKRqw/jQdE=
=pYSJ
-END PGP SIGNATURE-


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

Re: [CentOS] beeps and a slow boot

[Pete Travis]

On Jul 8, 2014 10:02 AM, "Michael Hennebry" 
wrote:
>
> On Mon, 7 Jul 2014, Pete Travis wrote:
>
> > Asus and the like don't make BIOS, they get it from AMI or Phoenix or
> > whatever.  It will usually say in POST screens or in the setup itself;
> > failing that, it  might be etched on the chip itself.
>
> Thanks.  That enabled me to find
> http://www.bioscentral.com/beepcodes/amibeep.htm
>
> > In my experience, though, 97% of problems whose symptoms include beep
codes
> > are memory issues.  Well, maybe that's a contrived figure, but it is
enough
> > that I'd look for spare memory first and a beep code reference after.
>
> The beep codes say memory.
> I ran memtest86 overnight and it passed.
> That said, I'm not sure how good memtest86 is.
> Could you suggest a memory test program that might find
> in a few hours what POST found in less than two minutes?
>
> To me, cracking the case is a *really* big deal.
> I don't want to do it unless I know I have to.
> Static, ribbons, fear and trepidation.
> I certainly do not want to have to buy some more DDR2 memory.
>
>
> On Tue, 8 Jul 2014, Ljubomir Ljubojevic wrote:
>
> > http://www.computerhope.com/beep.htm
>
> Also good.
>
> --
> Michael   henne...@web.cs.ndsu.nodak.edu
> "SCSI is NOT magic. There are *fundamental technical
> reasons* why it is necessary to sacrifice a young
> goat to your SCSI chain now and then."   --   John Woods
> ___

Just to reiterate :  *no matter what* the book says the beep code is, the
actual problem is usually memory.

Sometimes you have to run memtest for days before it sees anything.
Sometimes, you just need to open the chassis, clear out the fuzz, and
reseat the memory.  If you're that adverse to cracking the case, I'm
guessing you're due for it.

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

Re: [CentOS] beeps and a slow boot

[Pete Travis]

On Jul 7, 2014 5:40 PM, "Michael Hennebry" 
wrote:
>
> On Mon, 7 Jul 2014, m.r...@5-cent.us wrote:
>
> > Michael Hennebry wrote:
> >> On boot, my computer has been beeping at me and
> >> showing the BIOS screen for almost two minutes.
> >> During that time, it does not respond to tab or delete.
> >>
> >> Where do I find the beep codes for a
> >> MSI K9N SLI Platinum Series motherboard?
> >> My google-fu has failed me.
> >>
> > google search:  MSI K9N SLI Platinum Series manual
> > got me to MSI's page, and support under the pic got me to manual
> >
> > 
>
> I have the manual.
> I should have mentioned that the manual does not have the beep codes.
>
> --
> Michael   henne...@web.cs.ndsu.nodak.edu
> "SCSI is NOT magic. There are *fundamental technical
> reasons* why it is necessary to sacrifice a young
> goat to your SCSI chain now and then."   --   John Woods
>

Asus and the like don't make BIOS, they get it from AMI or Phoenix or
whatever.  It will usually say in POST screens or in the setup itself;
failing that, it  might be etched on the chip itself.

In my experience, though, 97% of problems whose symptoms include beep codes
are memory issues.  Well, maybe that's a contrived figure, but it is enough
that I'd look for spare memory first and a beep code reference after.

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

Re: [CentOS] starting/stopping services

[Pete Travis]

On Nov 1, 2013 2:02 PM, "Wes James"  wrote:
>
> On Fri, Nov 1, 2013 at 1:56 PM, Reindl Harald wrote:
>
> >
> >
> > Am 01.11.2013 20:49, schrieb Wes James:
> > >
> >
>
> 
>
>
> > >
> > > Thanks.  But why do some commands require service service-name command
> > > (like sshd) where postfix works without the service command in front
of
> > it?
> >
> > you still do not realize the difference between start/stop/restart
> > and enable/disable a service, they *all* behave identically
> >
> > some are enabled by default after install, some are not
> > __
> >
> > service *whatever* start
> > service *whatever* restart
> > service *whatever* stop
> >
> > chkconfig *whatever* on
> > chkconfig *whatever* off
> > __
> >
> > start/stop/restart acts *now*
> > on/off acts at boot
> >
> > please read some basic documentations!
> >
> > http://www.linuxmail.info/how-to-start-stop-services-centos-6/
> >
> >
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-services-chkconfig.html
> >
> >
> I do understand that.
>
> But why can you do
>
> postfix stop/start
>
> but not
>
> sshd stop/start.  With sshd you need to use service sshd stop/start.  It
> seems inconsistent.
>
> -wes
> ___

Services are also executables. The name of the service and the name of the
executable often but not always match.  Utilities like `service` and
`chkconfig` work with the init system to manage services.  You can also
invoke the executables by hand from the command line, but it would get
tedious. The initscripts control the arguments an executable is given at
start.

`service` is also an executable.  It takes different arguments from other
executables, primarily the name of the service to act on and the action to
be taken.  You don't expect different utilities to have identical command
syntax, because they do different work.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/part-Infrastructure_Services.htmlexplains
this better than I have.

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

Re: [CentOS] Motherboard and chipset compatibility

[Pete Travis]

On Aug 12, 2013 1:57 PM, "Ljubomir Ljubojevic"  wrote:
>
> On 08/12/2013 07:30 PM, Glenn Eychaner wrote:
> > Since the reqirements are (relatively) modest (except those two), I was
> > hoping to squeeze something in.
> >
> > Looks like I'm out of luck, and buying another full tower to hold a
> > motherboard, a disk drive, and one expansion card.
> >
>
> Have you considered "Desktop" type of cases? You could maybe place them
> bellow the existing Desktops, to conserve the horizontal space.
>
> You can also think about Building a "beast" system that would run
> original CentOS and one or more guest systems (CentOS, Windows,
> whatever). If you use KVM Virtualization, and buy MB with "IOMMU" BIOS
> option
> (https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware), you
> could pass PCI devices (second graphics card, telemetry PCI card, etc)
> to guest system, thus making current systems obsolete.
>
> So far I have only heard about IOMMU and PCI passthrough, so do not hold
> me to my words, but they say it works.
>
>
> --
> Ljubomir Ljubojevic
> (Love is in the Air)
> PL Computers
> Serbia, Europe
>
> StarOS, Mikrotik

I've been following GPU passthrough with KVM casually for a while, testing
andon stacks from EL6 up to Fedora Rawhide. Passthrough on other devices
work great - you loose guest migration ability, of course - for everything
*except * graphics devices. I would not consider this a viable option.

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

Re: [CentOS] What's The Odds?

[Pete Travis]

On Nov 27, 2012 8:25 AM, "Gene Poole"  wrote:
>
> What's the odds of retaining the data in a software raid-1 array when
> falling back to CentOS 5.8 x86_64 from CentOS 6.3 x86_64? The array is
> made up of 2 - 1.5 TB hard disks.  The original array was defined under
> CentOS 5.3 x86_64, then CentOS 6.1 x86_64 was installed and over time
> upgraded to CentOS 6.3. I need to back-level to test some software not
> certified for CentOS/RHEL 6.
>
> Thanks,
> Gene Poole
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

Centos 6 x86_64 has KVM/QEMU effectively out of the box. Does your testing
require bare metal?

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

Re: [CentOS] Configure Kickstart

[Pete Travis]

On Jun 19, 2012 9:04 AM, "John Doe"  wrote:
>
> From: jiten jha 
>
> > I want you help to configure kickstart on my centos5.4 server . I
search on
> > google and found so many way to configure it even on centos web site
also.
> > But It is not working and i am know so I can not understand it. So
please
> > send me link that i can understand and configure it.
>
>
http://www.microsofttranslator.com/bv.aspx?from=en&to=hi&a=http://fedoraproject.org/wiki/Anaconda/Kickstart
>
> JD
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

The anaconda guys update that resource as they go along. As the bleeding
edge of anaconda docs, many described features won't even be realized in
the most recent Fedora release.  However, the Installation Guides at
https://docs.fedoraproject.org should reflect the feature set of a given
anaconda version, and are already translated into many languages.

The RHEL Installation Guide also documents the kickstart process.

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

Re: [CentOS] A simplistic parental-control setup

[Pete Travis]

It won't help more than /etc/hosts entries, but I've found using OpenDNS
with a free account and a script / client to keep the IP in sync to be very
effective. DNS redirects can be applied categorically or with a per domain
blacklist.  The metrics and charts are interesting too, on a nicely basis
or to check on what's slipping through the filters.

--Pete
On Jan 5, 2012 7:47 AM, "Marko Vojinovic"  wrote:

> On Thursday 05 January 2012 01:39:49 Ljubomir Ljubojevic wrote:
> > On 01/05/2012 12:58 AM, Marko Vojinovic wrote:
> > > I am looking at the simplest (implementation-wise) solution to the
> > > following problem (on CentOS 6.2):
> > >
> > > I have a list of web addresses (like http://www.example.com,
> > > https://1.2.3.4/, etc.) that should be "forbidden" to access from a
> > > particular host. On access attempt, the browser should be redirected to
> > > a local web page (file on the hard disk) with the explanation that
> > > those addresses are forbidden. The possible ways of disallowed access
> > > include:
> > >
> > > * typing www.example.com or http://1.2.3.4/ in the browser
> > > * typing www.example.com/anyfolder/somefile.html in the browser
> > > * clicking on www.example.com when listed as a link on some other web
> > > site (say, Google search results)
> > > * nothing else.
> > >
> > > The last point above assumes that the users will never try any other
> > > method of accessing the site. These user's knowledge about computers in
> > > general is known to be elementary, so I don't need protection against
> > > geniouses who can figure out some obscure way to circumvent the
> > > lockdown (and please don't tell me that this is an irrational
> > > assumption, I know it is...).
> > >
> > > If possible, all this should be on a "per user" basis, but if
> > > implementing it system-wide would be much simpler, I could live with
> > > it. :-)
> > >
> > > The point is that I need a simple, easy-to-implement, easy-to-configure
> > > and easy-to-maintain solution for this particular usecase. What I don't
> > > need is some over-engineered solution that covers my usecase along with
> > > a whole bunch of stuff I will never need, and takes two months to
> > > configure properly. It should also be F/OSS, preferably included in
> > > CentOS repos or elsewhere.
> > >
> > > Or alternatively I could go along with manually setting up a bogus
> > > httpd/dns/iptables configuration which would do all this, but I have a
> > > feeling that it would not be the easiest thing to maintain...
> > >
> > > I'd appreciate any suggestions. :-)
> >
> > There is squidguard in RepoForge repository. It's a plugin for squid.
> > There is also dansguardian.
>
> I'll take a look at both of these, thanks! :-)
>
> > If you use separate firewall box, you can use ClearOS, it has
> > dansguardian set up.
>
> No, the machine is already installed with CentOS. Furthermore, I am
> supposed
> to set up all this remotely (via ssh), since I don't have physical access
> to
> the box itself...
>
> Best, :-)
> Marko
>
>
>
>
>
>
> ___
> 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] an actual hacked machine, in a preserved state

[Pete Travis]

Here's the qualifying statement I made, in an attempt to preempt pedantic
squabbles over my choice of arbitrary figures and oversimplified math:
> > I am not a statistician,  but

Here is a statement intended to startle you into re-examining your position:
> > Simplistic probability puts the odds of success
> > at 50% - either the attacker gets it right, or they don't.

Here's the intended take home message:
> >The next guess has the same
> > rough odds of being correct as the 100563674th guess.
>

Yes, you have to worry about a brute force attack succeeding, every hour of
every day that you give it a window to knock on.

Here is you nitpicking over figures; acknowledging the opportunity for an
improvement of several orders of magnitude and disregarding it, stuck in
your misconceptions; and wholly missing the point.
> Actually, each time you make a guess and it's wrong, the probability of
> success goes up slightly for your next guess.  Imagine having 10 cups
> with a ball under one of them.  The probability of turning over the
> right cup on the first try is 1/10.  If you're wrong, though, then the
> probability of getting it right on the next cup goes up to 1/9, and so on.
>
> But it's all a moot point if there are 10^24 possible passwords and the
> odds of finding the right one in any conceivable length of time are
> essentially zero.
>
> > Of course, no amount of guessing will succeed on a system that doesn't
> > accept passwords.   System security, in terms of probability, seems to
be
> > an 'every little bit helps' sort of endeavour.
>
> Well it depends on how literally you mean "every little bit" :)  If the
> chance of a break-in occurring in the next year from a given attack is 1
> in 10^10, you can reduce it to 1 in 10^20, but it's already less likely
> than your data center being hit by a meteorite.  The real problem is
> that it takes away from time that can be used for things that have a
> greater likelihood of reducing the chance of a break-in.  If I had taken
> the advice about ssh keys at the beginning of the thread, I never would
> have gotten to the suggestion about SELinux.
>
> Bennett
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

I'm moving on from this - much better men than I have tried and failed here.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Pete Travis]

On Jan 3, 2012 12:36 PM, "Ljubomir Ljubojevic"  wrote:
>
> On 01/03/2012 04:47 PM, m.r...@5-cent.us wrote:
> > Having been on vacation, I'm coming in very late in this
> >
> > Les Mikesell wrote:
> >> On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haselton
> >> wrote:
> > 
> >>> OK but those are *users* who have their own passwords that they have
> >>> chosen, presumably.  User-chosen passwords cannot be assumed to be
> >>> secure against a brute-force attack.  What I'm saying is that if
you're
> >>> the only user, by my reasoning you don't need fail2ban if you just
use a
> >>> 12-character truly random password.
> >>
> >> But you aren't exactly an authority when you are still guessing about
> >> the cause of your problem, are you?  (And haven't mentioned what your
> >> logs said about failed attempts leading up to the break in...).
> >
> > Further, that's a ridiculous assumption. Without fail2ban, or something
> > like it, they'll keep trying. You, instead, Bennett, are presumably
> > generating that "truly random" password[1] and assigning it to all your
> > users[2], and not allowing them to change their passwords, and you will
be
> > changing it occasionally and informing them of the change.[3]
> >
> > Right?
> >
> >  mark
> >
> > 1. How will you generate "truly random"? Clicks on a Geiger counter?
There
> > is no such thing as a random number generator.
> > 2. Which, being "truly random", they will write down somewhere, or store
> > it on a key, labelling the file "mypassword" or some such.
> > 3. How will you notify them of their new password - in plain text?
>
> Bennet was/is the only one using those systems, and only as root. No
> additional users existed prior to breach. And he is very persisting in
> placing his own opinion/belief above those he asks for help. That is why
> we have such a long long long thread. It came to the point where I am
> starting to believe him being a troll. Not sure yet, but it is getting
> there.
>
> I am writing this for your sake, not his. I decided to just watch from
> no on. This thread WAS very informative, I did lear A LOT, but enough is
> enough, and I spent far to much time reading this thread.
>
>
> --
>
> 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

I'm subscribed to this list just because of threads like this.  I want to
thank you all for exposing me to knowledge and discussion that reveals far
more than manpages or readmes - it helps a lot to know where to start
reading, and about what.

I am not a statistician,  but I feel an observation should be made on the
idea of an 'unguessable password.'  A 12 character string may have 12^42
possible permutations, but you are assuming that the correct guess will be
the last possible guess.  Simplistic probability puts the odds of success
at 50% - either the attacker gets it right, or they don't.   An intelligent
brute forcing tool could be making some assumptions about the minimum
length and complexity of your password, and ruling out the dictionary words
and strings based on them happens quickly.  The next guess has the same
rough odds of being correct as the 100563674th guess.

Of course, no amount of guessing will succeed on a system that doesn't
accept passwords.   System security, in terms of probability, seems to be
an 'every little bit helps' sort of endeavour.

Thanks again for the insights,

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

Re: [CentOS] megaraid/PERC

[Pete Travis]

On Nov 29, 2011 1:50 PM,  wrote:
>
> Pete Travis wrote:
> > On Nov 29, 2011 1:36 PM,  wrote:
> >>
> >> I've got two drives from a now-dead server, they were RAIDed, a mirror,
> >> I'd assume. I need to see if there's anything on them I need to
transfer
> >> to the replacement, so I just shoved them into another Dell server,
with
> >> a PERC 5 controller - I think that's what the dead one had. I fired up
> >> MegaRAID storage manager... but can't see any way to tell it to
recreate
> >> that RAID. Anyone done this?
> >
> > Correct me if I'm wrong, but isn't MSM for LSI/3ware cards?
>
> Right, and Dell's PERC is an OEM-rebranded LSI controller. MSM understands
> them fine.
>
> Of course, I don't seem to have the command line tool, and when I click on
> Go To, and try controller, everything is greyed out.
> 
>
> mark
>
>
I thought I might be pointing out the obvious   I'll be on front of a
box with MSM later, will take a look.

___
> 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] megaraid/PERC

[Pete Travis]

On Nov 29, 2011 1:36 PM,  wrote:
>
> I've got two drives from a now-dead server, they were RAIDed, a mirror,
> I'd assume. I need to see if there's anything on them I need to transfer
> to the replacement, so I just shoved them into another Dell server, with a
> PERC 5 controller - I think that's what the dead one had. I fired up
> MegaRAID storage manager... but can't see any way to tell it to recreate
> that RAID. Anyone done this?
>
>mark
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

Correct me if I'm wrong, but isn't MSM for LSI/3ware cards?

If the drives didn't come off a PERC, you probably can't recreate the array
on a PERC - I'm sure you know this, but it's worth verification.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Interactive PXE install

[Pete Travis]

I found the info on the Centos wiki helpful when I had these questions:

http://wiki.centos.org/HowTos/PXE/PXE_Setup

Note the last line links to the oxen menu guide.  I skipped the trouble of
dhcp option entries.
On Aug 4, 2011 6:43 PM, "Paul Heinlein"  wrote:
> On Thu, 4 Aug 2011, Kenneth Porter wrote:
>
>> The guides for a LAN install I've found all want to do an automated
>> kickstart install. Are there any guides that explain how to use eg.
>> CentOS-6.0-i386-netinstall.iso for an interactive PXE installation?
>>
>> I think I understand the DHCP config and I've got tftpd installed on
>> my CentOS 5 server and see the empty /tftpboot directory. I'm
>> guessing I need to unpack some of the files in the iso image into
>> /tftpboot in some special layout and add some files from
>> /usr/lib/syslinux. What's not clear is what files in the image go
>> where in the tftpboot system, and what the menu stanza should look
>> like in the menu file.
>
> LABEL centos-6-text.x86_64
> MENU LABEL CentOS 6 x86_64 text installer
> KERNEL images/centos/6/x86_64/vmlinuz
> APPEND initrd=images/centos/6/x86_64/initrd.img ramdisk_size=10 text
>
> The images/ directory lives in /tftpboot on our tftp server.
>
> The vmlinuz and initrd.img both come from the images/pxeboot directory
> in the install tree, e.g.,
>
> http://mirrors.cat.pdx.edu/centos/6/os/x86_64/images/pxeboot/
>
> Of course, you might not want a text installation, given that it's
> braindead compared to its graphical counterpart...
>
> --
> Paul Heinlein <> heinl...@madboa.com <> http://www.madboa.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