Re: [CentOS] trac on CentOS 6
On Thu, 6 Mar 2014, m.r...@5-cent.us wrote: Paul Heinlein wrote: On Thu, 6 Mar 2014, m.r...@5-cent.us wrote: Oh, sure: nothing special at all - I knew about it, but have never set it up. Ah, the joys of Real pacakges and repositories - I did a yum install trac-agilo-plugin, and everything's there. Now: I see it's added /etc/httpd/conf.d/trac.conf - does it really have to be under /srv, or can I just create //trac, and edit the trac.conf? Will that get the basic up? Or, do I need to run trac-admin to create the directory, or, again, do I create the directory and then run trac-admin? You can put your Trac(s) anywhere you like, of course. I put them in /srv: /srv/trac/ ├── bin ├── conf ├── plugins ├── share ├── sites ├── templates └── tmp The sites themselves live in sites/, while shared resources go in the other directories. I then adjust my selinux rules: semanage fcontext -a -t httpd_sys_content_t "/srv/trac(/.*)?" semanage fcontext -a -t httpd_sys_script_exec_t "/srv/trac/bin(/.*)?" semanage fcontext -a -t httpd_config_t "/srv/trac/conf(/.*)?" You need to run trac-admin to setup your site(s). Each site has its own conf/trac.ini file. Trac's developers have seen fit to put some configuration bits into the trac.ini file, while some live in the database. If you like to keep your configuration files in a repository, then you'll need to do edit/push for trac.ini and web-based actions for the stuff that lives in the database. Will you have an associated code repository (git or svn)? That calls for some other thinking. -- Paul Heinlein heinl...@madboa.com 45°38' N, 122°6' W___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5 + Quagga + SELinux
On Wed, Mar 5, 2014 at 10:19 AM, Daniel J Walsh wrote:
>
> man zebra_selinux
>
Thank you for the quick reply.
~]# man zebra_selinux
No manual entry for zebra_selinux
This is a rather basic (headless) install of CentOS 5.10 from the
netinstall ISO.
I haven't ripped out any default selinux pieces, so should I really be
missing that manpage?
~]# cat /etc/*ele*
cat: /etc/lsb-release.d: Is a directory
CentOS release 5.10 (Final)
~]# apropos selinux | egrep 'zebra|quagga'
If I remove the pipe to egrep, I do see squid_selinux for example.
> ...
>If you want to allow zebra daemon to write it configuration files,
> you
>must turn on the zebra_write_config boolean. Disabled by default.
>
>setsebool -P zebra_write_config 1
>
// before
~]# getsebool -a | grep zebra
allow_zebra_write_config --> on
zebra_disable_trans --> off
Apparently the command from the Bugzilla ticket I linked to earlier took
and already had allow_zebra_write_config enabled.
setsebool -P allow_zebra_write_config=1
// trying to set that selinux boolean comes back with
~]# setsebool -P zebra_write_config 1
libsemanage.dbase_llist_set: record not found in the database
libsemanage.dbase_llist_set: could not set record value
Could not change boolean zebra_write_config
Could not change policy booleans
On an selinux, but different topic...
I had to modify the user (role and type were right) to allow dnsmasq to
write to /var/log/dnsmasq.log
~]# chcon -v --user=system_u --role=object_r --type=var_log_t
/var/log/dnsmasq.log
This may or may not be the best/proper way, but appears to have fixed the
dnsmasq logging + selinux clash.
And now to apply that to my quagga/zebra + selinux situation...
// before
~]# ls -Z /etc/quagga/ | egrep '(zebra|vtysh)\.conf'
-rw-r- quagga quaggavt root:object_r:zebra_conf_t vtysh.conf
-rwxr-x--- quagga quaggavt system_u:object_r:zebra_conf_t
vtysh.conf.sample
-rw--- quagga quagga root:object_r:zebra_conf_t zebra.conf
-rw-r--r-- root root system_u:object_r:zebra_conf_t
zebra.conf.sample
-rw-r- quagga quaggavt root:object_r:zebra_conf_t zebra.conf.sav
~]# chcon -v --user=system_u /etc/quagga/vtysh.conf /etc/quagga/zebra.conf
/etc/quagga/zebra.conf.sav
// after
~]# ls -Z /etc/quagga/ | egrep '(zebra|vtysh)\.conf'
-rw-r- quagga quaggavt system_u:object_r:zebra_conf_t vtysh.conf
-rwxr-x--- quagga quaggavt system_u:object_r:zebra_conf_t
vtysh.conf.sample
-rw--- quagga quagga system_u:object_r:zebra_conf_t zebra.conf
-rw-r--r-- root root system_u:object_r:zebra_conf_t
zebra.conf.sample
-rw-r- quagga quaggavt system_u:object_r:zebra_conf_t zebra.conf.sav
// but no dice ...
# write
Building Configuration...
Can't open configuration file /etc/quagga/zebra.conf.ZHwkuk.
[OK]
~]# tail /var/log/audit/audit.log | grep zebra | audit2why
...
type=AVC msg=audit(1394150156.203:30): avc: denied { add_name } for
pid=3111 comm="zebra" name="zebra.conf.fT434c"
scontext=root:system_r:zebra_t:s0
tcontext=system_u:object_r:zebra_conf_t:s0 tclass=dir
Was caused by:
Missing or disabled TE allow rule.
Allow rules may exist but be disabled by boolean settings;
check boolean settings.
You can see the necessary allow rules by running
audit2allow with this audit message as input.
~]# tail /var/log/audit/audit.log | grep zebra | audit2allow
#= zebra_t ==
allow zebra_t zebra_conf_t:dir add_name;
What am I doing wrong here?
( missing manpage , still AVC denied )
I'm learning a thing or two about SELinux with each bump in the road it
presents to me.
Thanks for the help and for bearing with me. ;)
--
---~~.~~---
Mike
// SilverTip257 //
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
[CentOS] trac on CentOS 6
Anyone have a pointer to a *current* set of instructions on configuring
trac after I've installed it via yum?
Thanks in advance.
mark, very glad that something called agilefant only works with
tomcat7*
* And they're short on descriptions, and missing nouns ("the software tool
(of what kind?) for agail and lean... agile and lean *what*?)
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] trac on CentOS 6
Paul Heinlein wrote: > On Thu, 6 Mar 2014, m.r...@5-cent.us wrote: > >> Anyone have a pointer to a *current* set of instructions on >> configuring trac after I've installed it via yum? > > Any chance you can add some specifics about what sort of configuration > you're after: integration with Apache, database setup, trac.ini > tweaks, selinux, etc? Oh, sure: nothing special at all - I knew about it, but have never set it up. Ah, the joys of Real pacakges and repositories - I did a yum install trac-agilo-plugin, and everything's there. Now: I see it's added /etc/httpd/conf.d/trac.conf - does it really have to be under /srv, or can I just create //trac, and edit the trac.conf? Will that get the basic up? Or, do I need to run trac-admin to create the directory, or, again, do I create the directory and then run trac-admin? mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] trac on CentOS 6
On Thu, 6 Mar 2014, m.r...@5-cent.us wrote: Anyone have a pointer to a *current* set of instructions on configuring trac after I've installed it via yum? Any chance you can add some specifics about what sort of configuration you're after: integration with Apache, database setup, trac.ini tweaks, selinux, etc? -- Paul Heinlein heinl...@madboa.com 45°38' N, 122°6' W___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] OT Help for Cyrillic/percent letters to UTF-8 conversion script
Hi. I found a script which converts file names with with Cyrillic names downloaded from internet. They have letters like "%20" = " "(space), etc. Script is using xargs: for i in $(find * -type f ); do j=$(echo $i | sed -e's/%\([0-9A-F][0-9A-F]\)/\x\1/g' | xargs echo -e); echo $j; mv "$i" "$j"; done or: for i in $(find * -type f ); do j=$(echo $i | sed -e's/%\([0-9A-F][0-9A-F]\)/\x\1/g' | xargs echo -e); echo $j; mv "$i" "$j"; done But I have to apply it on server with Jailkit that does not allow xargs command. Does someone know how I can do it differently? Thanks, -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5 + Quagga + SELinux
On Thu, Mar 6, 2014 at 2:53 PM, Daniel J Walsh wrote: >>> > Not sure what you mean but these are files on a file system, Which I guess you > define as a giant list of global variables. Yes, in the sense that there can only be one of each. And if you intend for it to be widely used there might someday be a lot of them. > The names tend to match the name > of the package they are confining. sshd.pp confined sshd for example. > > selinux-policy is a big upstream project hosted at tresys, where you would > discover the conflicting names. > > We don't tend to add few new policy packages to a major rhel release. > > So it is unlikely that we would have a conflict with a name in an Enterprise > release. Of course you won't have conflicts "in" an enterprise release, just like you don't have conflicts in rpm package names and contents - because you have someone managing that release.. But for users _running_ the enterprise release and adding other things run into those conflicts with packages all the time. Contexts/boolean names aren't quite as common as 3rd party packages, but shouldn't there be a plan for them to scale? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5 + Quagga + SELinux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2014 01:15 PM, Les Mikesell wrote: > On Thu, Mar 6, 2014 at 11:03 AM, Daniel J Walsh wrote: >>> >>> All in the world, or all that have been created for currently >>> installed packages? Is this as bad as rpm packaging where any two >>> different sources are likely to conflict in name and/or contents? >>> >> Well we have not had this problem over the years, since most people >> upstream their policy. Right now if a customer installed a policy file >> which conflicted with the base policy, it will get overwritten. I guess >> if they did it will rpm then it would get you an RPM error/warning. > > What does 'upstream' mean in the context of packages that aren't included > in RHEL base or EPEL? It just seems like a giant list of global variables > without any structure or namespace management. > Not sure what you mean but these are files on a file system, Which I guess you define as a giant list of global variables. The names tend to match the name of the package they are confining. sshd.pp confined sshd for example. selinux-policy is a big upstream project hosted at tresys, where you would discover the conflicting names. We don't tend to add few new policy packages to a major rhel release. So it is unlikely that we would have a conflict with a name in an Enterprise release. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMY4EIACgkQrlYvE4MpobNEKwCdG3do+6eBjN0U0An343JPxwaG LEcAn3XBR5C/CInC8cuRmyM1hQ3ZiwcD =UZlW -END PGP SIGNATURE- ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5 + Quagga + SELinux
On Thu, Mar 6, 2014 at 11:03 AM, Daniel J Walsh wrote: >> >> All in the world, or all that have been created for currently installed >> packages? Is this as bad as rpm packaging where any two different sources >> are likely to conflict in name and/or contents? >> > Well we have not had this problem over the years, since most people upstream > their policy. Right now if a customer installed a policy file which > conflicted with the base policy, it will get overwritten. I guess if they did > it will rpm then it would get you an RPM error/warning. What does 'upstream' mean in the context of packages that aren't included in RHEL base or EPEL? It just seems like a giant list of global variables without any structure or namespace management. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5 + Quagga + SELinux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2014 10:39 AM, Les Mikesell wrote: > On Thu, Mar 6, 2014 at 8:02 AM, Daniel J Walsh wrote: > setsebool -P zebra_write_config 1 >>> >>> Is there some global registration facility for selinux context names or >>> are you the only one that knows them all? >>> >> Don't really know what you mean by that. > > I mean, if different people make up new names for use in different new > applications, what keeps them from colliding/conflicting when the packaged > settings are later installed on the same computer? > >> getsebool -a >> >> Will list all booleans >> >> semanage boolean -l >> >> Will list them with a short description. > > All in the world, or all that have been created for currently installed > packages? Is this as bad as rpm packaging where any two different sources > are likely to conflict in name and/or contents? > Well we have not had this problem over the years, since most people upstream their policy. Right now if a customer installed a policy file which conflicted with the base policy, it will get overwritten. I guess if they did it will rpm then it would get you an RPM error/warning. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMYqn4ACgkQrlYvE4MpobOkkgCgscehnE73yYnJOCp7n75klAY6 AOgAniKXfCD4Mwv25TgrIPzqvrZTiPT2 =26MN -END PGP SIGNATURE- ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] gnutls bug
Les Mikesell wrote: > On Thu, Mar 6, 2014 at 12:57 AM, Cliff Pratt > wrote: >> I have some sympathy for Michael. There are organisations which are so >> paranoid that they will not allow updates between eg 6.4 and 6.5, either >> because they insist on rigorous (ie lengthy and time consuming) >> regression testing of applications or because a third party package vendor >> specifies a particular level of OS for their product (I can think of at least two). >> >> Who has not been caught in the "not supported here" trap? You install a >> package from the OS supplier, and have an issue with it. You go to the >> forum for the package and get the response "upgrade to the latest >> release", but the OS supplier will not support the OS if you upgrade the package >> to the latest release! > > A strict requirement based on arbitrary version numbers may be > foolish, but a requirement for thorough testing before any change to a > production environment is not - even though the changes that happen > through the minor releases of an 'enterprise' OS have already been > vetted for changes to existing APIs. However, you really have to > assume that whatever you are running has security flaws and you have > to be prepared to roll out the fixes as soon as possible after they > are released since at that point the vulnerabilities will be well > known. So, you need a fairly agile testing/deployment process to > match your policy and keep it from doing more harm than good. As the guy who does that here, what I do is to 0) arrange a monthly maintenance window (saves a *lot* of pleading and begging) 1) update the development system (or, in some cases, they prefer that I update the test system, making regression easier). 2) update the other (test or dev). 3) if everything looks ok, update the backup prod machine, for those that have them 4) finally, in the prearranged window, so that users know what's happening, update the prod machines and reboot. I'd have to think long and hard to *ever* needing to downgrade a prod server. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] gnutls bug
On 03/05/2014 03:19 PM, Michael Coffman wrote: > I am running centos6.4. Where do I find the updated gnutls packages?I > see the updated source file here: > http://vault.centos.org/6.5/updates/Source/SPackages/ > > But I don't see the correct version of the packages in the 6.4 tree here: > http://vault.centos.org/6.4/updates/x86_64/Packages/ > > Where should I be looking for the updated package for 6.4? > > Thanks. Just to be perfectly clear here ... CentOS-6.4 and CentOS-6.5 are just point in time snapshots of the CentOS-6 distribution. As such, CentOS only supports the latest snapshot in production. Red Hat backports updates (security, bug fix, and enhancements) to try to ensure that things which run on EL6.3 also run on EL6.5, etc. See the backport explanation: https://access.redhat.com/site/security/updates/backporting/ So, CentOS-6.5 is just 6.4 (or 6.3 or 6.2 or 6.1 or 6.0) plus all updates. Red Hat does provide some Extended Update Support: http://www.redhat.com/products/enterprise-linux-add-ons/extended-update-support/ signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Full screen in Dual Monitor setup.
This question is related to Centos 6.4 running on workstations with dual monitors attached using Nvidia drivers, twinview mode. We've gotten stuck on a window manager specific issue with getting 'vncviewer' (tigervnc) to go full screen to both monitors. If Gnome is the window manager, we have no issues. Hitting "F8" in vncviewer and selecting "full screen" expands the viewer across both displays as expected. If KDE is the window manager, vncviewer will only expand to completely fill one of the two displays, even if the 'vncviewr' option "enable full-screen over all monitors" is enabled. In the "Multiple Monitors" system settings all options are enabled, suggesting that multiple monitor full screen mode should be working. Any thoughts on how to get full screen to work across both displays properly on KDE? Extra information: VNC: tigervnc-1.3.0-16.el6.x86_64 (issue is seen with stock tigervnc-1.1.0-5.el6.x86_64.rpm) Nvidia driver packages installed: kmod-nvidia-310.44-1.el6.elrepo.x86_64 nvidia-x11-drv-310.44-1.el6.elrepo.x86_64 Ray Frush "Either you are part of the solution T:970.288.6223 or part of the precipitate." -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Avago Technologies | APD Technical Computing | IT Engineer ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] gnutls bug
On Thu, Mar 6, 2014 at 7:46 AM, Les Mikesell wrote: > On Wed, Mar 5, 2014 at 10:01 PM, Bart Schaefer > wrote: >> rpm -e --test gnutls.i386 gnutls.x86_64 >> >> This will tell you what other packages depend on the gnutls library. > > Wouldn't 'yum remove gnutls' be a better check since it will walk up > the dependency tree - and is interactive by default so it will show > the list and wait for confirmation? If you're willing to trust that the default is in place and you won't, accidentally, really start removing stuff, then yes. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] gnutls bug
On Thu, Mar 6, 2014 at 12:57 AM, Cliff Pratt wrote: > I have some sympathy for Michael. There are organisations which are so > paranoid that they will not allow updates between eg 6.4 and 6.5, either > because they insist on rigorous (ie lengthy and time consuming) regression > testing of applications or because a third party package vendor specifies a > particular level of OS for their product (I can think of at least two). > > Who has not been caught in the "not supported here" trap? You install a > package from the OS supplier, and have an issue with it. You go to the > forum for the package and get the response "upgrade to the latest release", > but the OS supplier will not support the OS if you upgrade the package to > the latest release! A strict requirement based on arbitrary version numbers may be foolish, but a requirement for thorough testing before any change to a production environment is not - even though the changes that happen through the minor releases of an 'enterprise' OS have already been vetted for changes to existing APIs. However, you really have to assume that whatever you are running has security flaws and you have to be prepared to roll out the fixes as soon as possible after they are released since at that point the vulnerabilities will be well known. So, you need a fairly agile testing/deployment process to match your policy and keep it from doing more harm than good. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] gnutls bug
On Wed, Mar 5, 2014 at 10:01 PM, Bart Schaefer wrote: > Before you update anything, I suggest you run > > rpm -e --test gnutls > > If this complains about "refers to more than one package" then use > > rpm -e --test gnutls.i386 gnutls.x86_64 > > This will tell you what other packages depend on the gnutls library. > It's probably fewer than you think, because RHEL/CentOS have openssl > packages as well. We determined that for our servers we could simply > remove gnutls (desktops are a different matter). > > (Ideally "rpm -q --whatrequires" would tell you this, but in fact it > does not unless you know the magic string that fully names > "libgnutls.so...") Wouldn't 'yum remove gnutls' be a better check since it will walk up the dependency tree - and is interactive by default so it will show the list and wait for confirmation? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5 + Quagga + SELinux
On Thu, Mar 6, 2014 at 8:02 AM, Daniel J Walsh wrote: > >>> >>> setsebool -P zebra_write_config 1 >> >> Is there some global registration facility for selinux context names or are >> you the only one that knows them all? >> > Don't really know what you mean by that. I mean, if different people make up new names for use in different new applications, what keeps them from colliding/conflicting when the packaged settings are later installed on the same computer? > getsebool -a > > Will list all booleans > > semanage boolean -l > > Will list them with a short description. All in the world, or all that have been created for currently installed packages? Is this as bad as rpm packaging where any two different sources are likely to conflict in name and/or contents? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] gnutls bug
Thanks for all the thoughtful responses. I have learned a couple of things. On Thu, Mar 6, 2014 at 7:26 AM, Leon Fauster wrote: > Am 06.03.2014 um 01:00 schrieb Michael Coffman < > michael.coff...@avagotech.com>: > > On Wed, Mar 5, 2014 at 4:44 PM, John R Pierce > wrote: > > > >> On 3/5/2014 3:36 PM, Michael Coffman wrote: > >>> Not sure what your environment looks like but the systems I manage are > >>> locked down and it's typically difficult to get them changed. We have > >>> hundreds of systems ( desktop, server and HPC systems) that are all the > >>> same rev with all the same packages. A large number of vendor > packages > >>> and internally developed packages have to be re-qualified everytime > >>> anything is changed. So we don't change them often. > >> > >> so you're a year behind on any security fixes why are you worried > >> about this one, then? > >> > > > > > > This seems like it has more potentiol to impact users in my environment > > that are using a web browser to access sites outside our firewall. It > > seemed like a reasonable question to me as it looke like it might be > easily > > updated. I did not realize that once the OS was vaulted, there were no > > more updates. Now I know so thanks... > > > The OS is not vaulted. I suggest to rethink the mental model of the OS > point releases. > > IMHO the above mentioned policy brings less security into the organization > then it > tries to suggest and do not forget that the most attacks came from > internal. > > There are more fixes to worry about > > https://rhn.redhat.com/errata/rhel-server-6-errata.html > > > -- > LF > > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > -- -MichaelC ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Digest, Vol 110, Issue 6
Testing On 3/6/2014 7:00 PM, centos-requ...@centos.org wrote: > Send CentOS mailing list submissions to > centos@centos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.centos.org/mailman/listinfo/centos > or, via email, send a message with subject or body 'help' to > centos-requ...@centos.org > > You can reach the person managing the list at > centos-ow...@centos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CentOS digest..." > > > Today's Topics: > > 1. CentOS-announce Digest, Vol 109, Issue 1 >(centos-announce-requ...@centos.org) > 2. Re: CentOS 6.5 install (SilverTip257) > 3. Re: CentOS 6.5 install (zGreenfelder) > 4. Re: CentOS 6.5 install (Kenny Noe) > 5. Replace failed disk in raid (Nikos Gatsis - Qbit) > 6. Re: Replace failed disk in raid (Nicolas Thierry-Mieg) > 7. Re: Replace failed disk in raid (John Doe) > 8. Re: Replace failed disk in raid (Nikos Gatsis - Qbit) > 9. Re: CentOS 6.5 install (James B. Byrne) >10. Re: Replace failed disk in raid (Dennis Jacobfeuerborn) >11. where can download CENTOS 5.X (mcclnx mcc) >12. Re: where can download CENTOS 5.X (Digimer) >13. Re: where can download CENTOS 5.X (Earl A Ramirez) >14. Re: CentOS 5 + Quagga + SELinux (Daniel J Walsh) >15. Re: CentOS 5 + Quagga + SELinux (Daniel J Walsh) >16. Re: CentOS 6.5 install (m.r...@5-cent.us) >17. Re: where can download CENTOS 5.X (John Doe) >18. Re: maraidb for el6 (Johnny Hughes) >19. Re: CentOS 5 + Quagga + SELinux (SilverTip257) >20. Re: CentOS 5 + Quagga + SELinux (Les Mikesell) >21. Re: maraidb for el6 (Farkas Levente) >22. gnutls bug (Michael Coffman) >23. Re: gnutls bug (Peter) >24. Re: gnutls bug (Frank Cox) >25. Re: gnutls bug (John R Pierce) >26. Re: gnutls bug (Dennis Jacobfeuerborn) >27. Re: CentOS 6.5 install (Les Mikesell) >28. Re: CentOS 6.5 install (m.r...@5-cent.us) >29. Full screen in Dual Monitor setup. (Ray Frush) >30. Re: gnutls bug (Michael Coffman) >31. Re: CentOS 6.5 install (Les Mikesell) >32. Re: gnutls bug (John R Pierce) >33. Re: gnutls bug (Les Mikesell) >34. Re: gnutls bug (Michael Coffman) >35. Re: gnutls bug (John R Pierce) >36. Re: gnutls bug (Michael Coffman) >37. Re: gnutls bug (Les Mikesell) >38. Re: gnutls bug (Stephen Harris) >39. Re: gnutls bug (David C. Miller) >40. Re: Replace failed disk in raid (Keith Keller) >41. Re: gnutls bug (Les Mikesell) >42. Re: gnutls bug (Bart Schaefer) >43. Re: gnutls bug (Cliff Pratt) >44. Centos6 - Apache + mod_dav_svn + ldap (Todor Petkov) > > > -- > > Message: 1 > Date: Wed, 05 Mar 2014 12:00:05 + > From: centos-announce-requ...@centos.org > Subject: [CentOS] CentOS-announce Digest, Vol 109, Issue 1 > To: centos-annou...@centos.org > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Send CentOS-announce mailing list submissions to > centos-annou...@centos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.centos.org/mailman/listinfo/centos-announce > or, via email, send a message with subject or body 'help' to > centos-announce-requ...@centos.org > > You can reach the person managing the list at > centos-announce-ow...@centos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CentOS-announce digest..." > > > Today's Topics: > > 1. CESA-2014:0247 Important CentOS 5 gnutls Update (Johnny Hughes) > 2. CESA-2014:0249 Important CentOS 5 postgresql Update >(Johnny Hughes) > 3. CESA-2014:0246 Important CentOS 6 gnutls Update (Johnny Hughes) > > > -- > > Message: 1 > Date: Tue, 4 Mar 2014 20:51:10 + > From: Johnny Hughes > Subject: [CentOS-announce] CESA-2014:0247 Important CentOS 5 gnutls > Update > To: centos-annou...@centos.org > Message-ID: <20140304205110.ga4...@chakra.karan.org> > Content-Type: text/plain; charset=us-ascii > > > CentOS Errata and Security Advisory 2014:0247 Important > > Upstream details at : https://rhn.redhat.com/errata/RHSA-2014-0247.html > > The following updated files have been uploaded and are currently > syncing to the mirrors: ( sha256sum Filename ) > > i386: > b603b43caa97ad8272ce87f1f736a29d87ecdc10564ff93bfdf5d46b8c2e4bd7 > gnutls-1.4.1-14.el5_10.i386.rpm > effe174cb91c216f5408f5d47ebb65c890857ae2af40b73e984bd1fe123a1837 > gnutls-devel-1.4.1-14.el5_10.i386.rpm > 7ef92c37156065ade2d3413864939f1c44990869115cd44c5e55a5a6d9fd5b8c > gnutls-utils-1.4.1-14.el5_10.i386.rpm > > x86_64: > b603b43caa97ad8272ce87f1f736a29d87ecdc10564ff93bfdf5d46b8c2e4bd7 > gnutls-1.4.1-14.el5_10.i386.rpm > 54562c8761782be33c37ab9eb5a33789832564bb1873
Re: [CentOS] gnutls bug
Am 06.03.2014 um 01:00 schrieb Michael Coffman : > On Wed, Mar 5, 2014 at 4:44 PM, John R Pierce wrote: > >> On 3/5/2014 3:36 PM, Michael Coffman wrote: >>> Not sure what your environment looks like but the systems I manage are >>> locked down and it's typically difficult to get them changed. We have >>> hundreds of systems ( desktop, server and HPC systems) that are all the >>> same rev with all the same packages. A large number of vendor packages >>> and internally developed packages have to be re-qualified everytime >>> anything is changed. So we don't change them often. >> >> so you're a year behind on any security fixes why are you worried >> about this one, then? >> > > > This seems like it has more potentiol to impact users in my environment > that are using a web browser to access sites outside our firewall. It > seemed like a reasonable question to me as it looke like it might be easily > updated. I did not realize that once the OS was vaulted, there were no > more updates. Now I know so thanks... The OS is not vaulted. I suggest to rethink the mental model of the OS point releases. IMHO the above mentioned policy brings less security into the organization then it tries to suggest and do not forget that the most attacks came from internal. There are more fixes to worry about https://rhn.redhat.com/errata/rhel-server-6-errata.html -- LF ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5 + Quagga + SELinux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/2014 02:11 PM, Les Mikesell wrote: > On Wed, Mar 5, 2014 at 9:19 AM, Daniel J Walsh wrote: >> >> man zebra_selinux ... If you want to allow zebra daemon to write it >> configuration files, you must turn on the zebra_write_config boolean. >> Disabled by default. >> >> setsebool -P zebra_write_config 1 > > Is there some global registration facility for selinux context names or are > you the only one that knows them all? > Don't really know what you mean by that. getsebool -a Will list all booleans semanage boolean -l Will list them with a short description. man DOMAIN_selinux Is available for over 1000 applications. system-config-selinux Also can list booleans. If you want to look at all the types available you can use seinfo. seinfo -t for example. If you want to look at all allow rules, sesearch will tell you. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMYgAAACgkQrlYvE4MpobOh4gCgsy/whuuitMzvH2p8Z1fyjzV5 CDcAn1/HLNGBJ0kwCUJbxOYe0plwy9+9 =KatO -END PGP SIGNATURE- ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5 + Quagga + SELinux
On 05/03/2014 19:11, Les Mikesell wrote: > On Wed, Mar 5, 2014 at 9:19 AM, Daniel J Walsh wrote: >> >> man zebra_selinux >> ... >> If you want to allow zebra daemon to write it configuration files, >> you >> must turn on the zebra_write_config boolean. Disabled by default. >> >> setsebool -P zebra_write_config 1 > > Is there some global registration facility for selinux context names > or are you the only one that knows them all? > You can see all the se booleans by running getsebool -a Tris * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmas...@bgfl.org The views expressed within this email are those of the individual, and not necessarily those of the organisation * ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] gnutls bug
On 03/06/2014 12:27 PM, Cliff Pratt wrote: > I have some sympathy for Michael. There are organisations which are so > paranoid that they will not allow updates between eg 6.4 and 6.5, either > because they insist on rigorous (ie lengthy and time consuming) regression > testing of applications or because a third party package vendor specifies a > particular level of OS for their product (I can think of at least two). > It is very unfortunate that many organisations and vendors put up restrictions without examining the technical details of specific environments, thus treating 6.4 and 6.5 like separate OS-es. The restrictions are put up with the intention of protecting the environment from getting broken by incompatibility that may be brought in by new packages, but the irony is that by sticking to these restrictions, they are broken already with respect to bug fixes and security fixes available with updates not being applied. They need to be educated that API and ABI compatibility will not be broken across minor releases of a single major version. It is essentially a confusion between update and upgrade, I feel. - rejy (rmc) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] maraidb for el6
On 05.03.2014 09:35, Farkas Levente wrote: > hi, > i put together a mariadb rpm for el6. it seem to be much more > complicated then i thought. > > the sources was: > - Karanbir's mariadb for centos6 5.5.29 > http://dev.centos.org/centos/6/mariadb/ > unfortunately the link disappear a few days ago but i've got the > src.rpm > - rhel7 mariadb-5.5.33a-3.el7.src.rpm > - fedora's mariadb-5.5.35-4.fc21.src.rpm > - rhel6's scl's mariadb55-mariadb-5.5.35-1.1.el6.src.rpm > > the problem doesn't seems to complicated but after a few hours i hope > we > created a good rpm which can update the previous el6's mysql packages. > > the packages are here: > http://lfarkas.org/linux/packages/redhat/6/mariadb/ > regards. I use this for a Galera cluster and it works great: http://yum.mariadb.org/5.5/centos6-amd64/ -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Centos6 - Apache + mod_dav_svn + ldap
Hello, I am using Apache with mod_svn authorization via 389-DS LDAP. Users are complaining, that after 10 minutes the SVN session hangs and they need to restart the client. There is no problem with .htpasswd authorization. I came across this url http://directory.fedoraproject.org/wiki/Howto:Subversion_Apache_LDAP, I set "LDAPCacheEntries 0", but the problem is still existing. Does anyone have similar problem and solution? Regards, ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
