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 

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-docs] Resources Needed for Doc Toolchain Project [GSoC]

[Pete Travis]

On Jun 5, 2015 6:15 AM, Sankarshan Mukhopadhyay 
sankarshan.mukhopadh...@gmail.com wrote:

 On Fri, Jun 5, 2015 at 1:33 PM, kunaal jain kunaa...@gmail.com wrote:
  Can you tell us about Fedora Docs toolchain? We can surely help each
other
  if our interests align.
 

 https://fedorahosted.org/documentation-guide/


 --
 sankarshan mukhopadhyay
 https://about.me/sankarshan.mukhopadhyay
 ___


That covers the bulk of it, thanks.  I'm working on new tooling for the
site publishing portion, but since that's closer to whiteboarding the than
proof-of-concept, it is probably better to discuss it out of band.

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

Re: [CentOS-docs] Resources Needed for Doc Toolchain Project [GSoC]

[Pete Travis]

On Jun 4, 2015 12:17 PM, Karsten Wade kw...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 06/01/2015 10:30 PM, Lei Yang wrote:
  Hi,
 
  As discussed earlier about the workflow, I and Kunaal will need a
  server space to host Bugzilla, a test repository at Github + a git
   repository at git.centos.org http://git.centos.org/. This is
  temporary, required for development and testing.
 
  Please let us know how do we obtain the same? We need it to get
  started on our project.

 Thanks for asking on centos-devel, I'll reply there with some
 specifics on requesting resources.

 I think you will get push back about Bugzilla. For example, someone
 has to continue to administer the system after the summer is done. The
 rest of the toolchain looks like it's something that the sysadmin team
 can handle with the proper documentation. An entire Bugzilla instance
 is another thing, however -- web server, PHP code, database, and so fort
 h.

 Are you sure that bugs.centos.org cannot work well enough?

 Regards,

 - - Karsten
 - --


I'm tentatively planning on working pagure[0] into the Fedora Docs
toolchain. It handles issue tracking, process documentation/contribution
guidelines, and of course repo management and pull requests.  It might fit
for CentOS docs as well.

[0] https://pagure.io/pagure

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

Re: [CentOS-docs] GSoC - Syncing docs between GitHub and CentOS's git repo

[Pete Travis]

On Apr 7, 2015 9:28 AM, 杨 垒 yltt1234...@gmail.com wrote:

 Hi Kunal!

 Thanks for your reply! I think the official mirroring is a great method
because of higher efficiency.

 Another thing I am trying to solve is how to retrieve and store all the
discussion / issue / PR on GitHub? These functions are great for a doc
toolchain. However we shouldn’t rely on GitHub as a part of our project. My
plan now is to use bugs.cents.org as a place to discuss about docs
contributions. Or we can create a new site to track / discuss about the
docs but it is a too huge job. Any ideas?

 Regards,
 Lei Yang
 ___

I've found bugzilla to be great for tracking actual flaws in the product,
but not great for internal discussion and process tracking.  Lists or Trac
can be better, respectively.  I'm also keeping a close eye on pagure,
http://blog.pingoured.fr/index.php?post/2015/03/25/Progit-is-dead%2C-long-live-pagure

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

Re: [CentOS] systemctl (again)

[Pete Travis]

On Apr 4, 2015 7:55 AM, J Martin Rushton martinrushto...@btinternet.com
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)


snip

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-docs] Docs strategy and tactics [RFC]

[Pete Travis]

On 03/12/2015 03:59 PM, Karsten Wade wrote:
 I've been thinking for a little while, and talking with people, about
 what would be a good documentation strategy for the CentOS Project.

 == tl;dnr aka Summary

 This is a proposal around creating new, short-format
 documentation about doing cool new things on top of CentOS
 Linux. These docs would support the work of the various SIGs (Cloud,
 Storage, Virt, etc.), in some cases living in the upstream project and
 rebuilt in to CentOS by SIGs.

 == Overview

 When it comes to all the documentation we can think about, there are
 several areas with clear importance:

 1. Base CentOS Linux materials, which are numerous and include the
 upstream RHEL documentation set. These are focused on installation,
 configuration, and administration of various parts of a CentOS Linux
 instance or set of instances.

 2. Doing cool things on top of CentOS Linux.

 3. Content for working within the project, such as part of a SIG, how to
 ask questions on IRC, and how to conduct oneself on mailing lists.

 For item 3, we have some fairly robust and growing content, and I think
 that can continue to grow somewhat organically. We may want to adopt
 tooling and workflow from this proposal as it matures.

 For item 1, we are currently blocked from moving ahead by not being
 able to easily rebrand and reuse the RHEL doc set without the XML
 sources. Reworking external content is also an idea, but a similar
 pain for different reasons. I want to set aside this item for the
 purposes of this thread.

 Item 2 is the one where we can get some great traction:

 * Content that shows how to do things on top CentOS Linux is key for
 adoption of new use cases.
 * It's an area where we can lower the barriers to contribution greatly.
 * Many upstream projects can benefit from better content on how to use
 their software on CentOS Linux, and the Project benefits from the shared
 exposure.

 The below strategy proposal is focused around item 2.

 ## BEGIN PROPOSAL

   You've just installed CentOS Linux, great, congratulations -- you
   now have an expensive heater. What people need is content on how to
   /do something/ with that installation.

   -- Jim Perrin

 == Overview

 The overall idea is two basic parts:

 1. Focus on short-form, how-to/tutorial content. In many cases, multiple
 docs/articles are linked together to show the various steps. For
 example, these ARMv8 posts from Jim:

 http://seven.centos.org/2015/03/centos-linux-7-and-arm/
 http://seven.centos.org/2015/03/building-centos-linux-7-for-armv8/

 2. Docs that are about combining an upstream (usually via a SIG) either
 i) live in the upstream repo and are rebuilt in to CentOS, or ii) live
 in CentOS but are shared/socialized into the upstream project and its
 ecosystem.

 Goal here is to minimize our own ongoing maintenance by following the
 same upstream first, carry minimal patches philosophy that goes in to
 the way Fedora is built and RHEL is maintained.

 This is an example of an upstream we could contribute in to, using
 OpenShift Origin on top of CentOS Linux:

 https://blog.openshift.com/new-platform-new-docs-part/

 A workflow might go like this; this is deliberately tooling unspecific,
 more on tools below.

 1. A person has an idea, a draft, or polished piece of content that is
 about doing something with CentOS Linux. If properly licensed, it can
 be from an outside person brought in to the Project by one of us.
 (I.e., you find a great how-to licensed CC BY SA.)

 2. Content is brought to centos-docs@centos.org for review of the next
 step.

 3. CentOS Docs SIG[1] reviews and decides next approach:

   3.1 If the doc is CentOS Linux or Project specific, canonical source
 goes to git.centos.org  is published to centos.org/docs. It may require
 conversion to the preferred source format for building as a doc.

   3.2 If the doc fits perfectly within an upstream as an example of
 how to deploy or use the upstream software on the CentOS platform, we
 push doc to the appropriate upstream(s). Link or copy is carried at
 centos.org/docs and appropriate wiki pages.

   3.3 Unclear where doc fits, so author and SIG members engage with
 upstream project(s) to find out best way forward.

3.3.1 Write down each upstream preference as we learn.

 4. Content is prepared for target location and delivered.

   4.1 Document is edited for style, grammar, punctuation, etc.

   4.2 Document is edited for ease of translation.

   4.3 Conversion to a standard format, if required.

   4.4 Check-in to version controlled system.

 5. Publicity around document being available -- @centos, proper links
 across CentOS wiki and at /docs, possibly a blog post highlighting a new
 series of content, etc.

   5.1 Potential interaction with Promo SIG here.

 == Tooling

 There are a few levels to think about here where it comes to thinking
 about a chunk of content:

 A. The markup used, standards around how it's written (avoid idioms,
 use the 

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
 kahlil.hodg...@dealmax.com.au wrote:
 On 10 February 2015 at 10:15, PatrickD Garvey
patrickdgarv...@gmail.com 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] Another Fedora decision

[Pete Travis]

On 02/09/2015 11:11 PM, Kahlil Hodgson wrote:
 On 10 February 2015 at 16:39, Pete Travis li...@petetravis.com 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 li...@petetravis.com 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] 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 henne...@web.cs.ndsu.nodak.edu
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 henne...@web.cs.ndsu.nodak.edu
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
 
  http://www.msi.com/support/mb/K9N_SLI_Platinum.html#down-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-docs] Documentation SIG

[Pete Travis]

On Mar 13, 2014 6:12 AM, Jim Perrin jper...@centos.org wrote:



 On 03/12/2014 09:39 AM, Tim Krupinski wrote:
  Hey all -
 
  Just curious to find out if there's any activity with the documentation
  SIG?  I'd like to join.  One thing i've noticed is that it seems like
  documentation for CentOS ends at 5.  While the documentation is more or
  less mirrored from RedHat's site, this can be confusing to beginners
since
  they may get the impression that documentation isn't there.

 Most of the activity has been around things other than docs, but you do
 bring up a good point. We *need* to address this.

 With the 6.x documentation, there was a licensing change that
 complicates things for us. Changes to the documentation mean that you
 can't redistribute. Oracle appears to work around this by shipping the
 official pdf documentation.
...
 --
 Jim Perrin

Can you be more specific about this licencing change? As far as I've read
so far, RHEL7 guides are CC-BY-SA 3.0 -
https://creativecommons.org/licenses/by-sa/3.0/ - which makes them fair
game for adaptation and redistribution as long as you give attribution.

The docbook sources are a different issue, but IMO there's an argument to
be made for sharing them given the increased collaboration potential.

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

Re: [CentOS] starting/stopping services

[Pete Travis]

On Nov 1, 2013 2:02 PM, Wes James compte...@gmail.com wrote:

 On Fri, Nov 1, 2013 at 1:56 PM, Reindl Harald h.rei...@thelounge.net
wrote:

 
 
  Am 01.11.2013 20:49, schrieb Wes James:
  
 

 snip


  
   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 cen...@plnet.rs 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 gene.po...@macys.com 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 jd...@yahoo.com wrote:

 From: jiten jha jitenjh...@googlemail.com

  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=ento=hia=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 vvma...@gmail.com 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]

On Jan 3, 2012 12:36 PM, Ljubomir Ljubojevic off...@plnet.rs 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 Haseltonbenn...@peacefire.org
  wrote:
  snip
  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] 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] megaraid/PERC

[Pete Travis]

On Nov 29, 2011 1:36 PM, m.r...@5-cent.us 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] megaraid/PERC

[Pete Travis]

On Nov 29, 2011 1:50 PM, m.r...@5-cent.us wrote:

 Pete Travis wrote:
  On Nov 29, 2011 1:36 PM, m.r...@5-cent.us 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.
 snip

 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] 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 heinl...@madboa.com 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