Re: [CentOS] Weird bandwith behaviour (download throughput) on CentOS based gateway

[Jobst Schmalenbach]

On Mon, Oct 09, 2017 at 03:05:51PM +0200, hw (h...@adminart.net) wrote:
> Jobst Schmalenbach  writes:
> 
> > On Thu, Oct 05, 2017 at 02:57:18PM +1300, Clint Dilks 
> > (cli...@scms.waikato.ac.nz) wrote:
> >> On Thu, Oct 5, 2017 at 2:41 PM, Jobst Schmalenbach 
> 
> Is there a dependency on which machine you test first?  Perhaps the file
> has been stored in some cache along the way and for the second test, it
> can be delivered from the cache instead of from the source, which might
> yield higher speeds.

Very good question, answer is no for the following reasons:

 - it happens for all downloads - yum, wget etc
 - I have looked at the interfaces using ngrep, all traffic goes straight out 
through the closest (as in hops) interface
 - As you raised this I have disabled caching on the command line using wget, 
still happens
 - As you raised this I have checked whether there are any (environment) 
options set, none
   I, too, use the same bash scripts on all machines I have

I though about the interfaces, but can't be. The last two interfaces are on the 
problem machine, but when downloading on the LAN I get a throughput of ~28mbs, 
only when downloading on the gateway I only get <10mbs.

So still baffled.

Jobst




-- 
Computing power increases as the square of the cost. If you want to do it twice 
as cheaply, you have to do it four times as fast.

  | |0| |   Jobst Schmalenbach, General Manager
  | | |0|   Barrett & Sales Essentials
  |0|0|0|   +61 3 9533 , POBox 277, Caulfield South, 3162, Australia
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Samba won't start on Centos 7.3.1611

[Alan McKay]

Ug - can't believe it.

[root@centos-gig ~]# rpm -qa | grep samba
samba-libs-4.4.4-14.el7_3.x86_64
samba-client-4.4.4-14.el7_3.x86_64
samba-client-libs-4.4.4-14.el7_3.x86_64
samba-common-tools-4.4.4-14.el7_3.x86_64
samba-common-libs-4.4.4-14.el7_3.x86_64
samba-common-4.4.4-14.el7_3.noarch
[root@centos-gig ~]# yum -y install samba

(and it goes on to install the one missing package)

Not sure how I ended up with everything but that one ... thanks
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Samba won't start on Centos 7.3.1611

[me]

On Mon, 9 Oct 2017, Alan McKay wrote:


Hi folks,

I've been googling for an hour on this which seems to be awfully
basic.  But I cannot find anything definitive.

[root@centos-gig ~]# systemctl enable smb.service
Failed to execute operation: Access denied
[root@centos-gig ~]# setenforce 0
[root@centos-gig ~]# systemctl enable smb.service
Failed to execute operation: No such file or directory


Does /usr/lib/systemd/system/smb.service exist? It does not look like it
based on the error above.

Does "rpm -V samba" show anything useful?



Have tried things like :
chcon -t samba_share_t /home/amckay

Also took the output from:
getsebool -a | grep samba

and set all them to "on"


The selinux stuff means nothing if you have selinux set to permissive.



Stripped my config down to the most basic.

What am I missing?


# Global parameters
[global]
netbios name = centos
security = USER
idmap config * : backend = tdb


Is this a standalone server?



[homes]
comment = Home Directories
browseable = No
inherit acls = Yes
read only = No
valid users = %S %D%w%S


Does testparm show any errors?

HTH,

--
Tom m...@tdiehl.org
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Samba won't start on Centos 7.3.1611

[Alan McKay]

Also tried this :

[root@centos-gig ~]# cat allow
type=USER_AVC msg=audit(1507584974.134:166105): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='avc:  received setenforce notice (enforcing=1)
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
type=USER_AVC msg=audit(1507584974.137:166106): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='avc:  denied  { enable } for auid=1000 uid=0 gid=0
cmdline="systemctl enable smb.service"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=system_u:system_r:init_t:s0 tclass=service
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

[root@centos-gig ~]# audit2allow -i ./allow -M samba
 IMPORTANT ***
To make this policy package active, execute:

semodule -i samba.pp

[root@centos-gig ~]# semodule -i ./samba.pp
libsemanage.semanage_direct_install_info: Overriding samba module at
lower priority 100 with module at priority 400.
Failed to resolve typeattributeset statement at
/etc/selinux/targeted/tmp/modules/100/ksmtuned/cil:78
semodule:  Failed!
[root@centos-gig ~]# audit2allow -i ./allow -M samba-new
 IMPORTANT ***
To make this policy package active, execute:

semodule -i samba-new.pp

[root@centos-gig ~]# semodule -i ./samba-new.pp
[root@centos-gig ~]# systemctl enable smb.service
Failed to execute operation: No such file or directory
[root@centos-gig ~]# setenforce 1
[root@centos-gig ~]# systemctl enable smb.service
Failed to execute operation: No such file or directory
[root@centos-gig ~]# setenforce 1
[root@centos-gig ~]# systemctl enable smb.service
Failed to execute operation: No such file or directory
[root@centos-gig ~]#
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Samba won't start on Centos 7.3.1611

[Alan McKay]

Hi folks,

I've been googling for an hour on this which seems to be awfully
basic.  But I cannot find anything definitive.

[root@centos-gig ~]# systemctl enable smb.service
Failed to execute operation: Access denied
[root@centos-gig ~]# setenforce 0
[root@centos-gig ~]# systemctl enable smb.service
Failed to execute operation: No such file or directory

Have tried things like :
chcon -t samba_share_t /home/amckay

Also took the output from:
getsebool -a | grep samba

and set all them to "on"

Stripped my config down to the most basic.

What am I missing?


# Global parameters
[global]
netbios name = centos
security = USER
idmap config * : backend = tdb

[homes]
comment = Home Directories
browseable = No
inherit acls = Yes
read only = No
valid users = %S %D%w%S

-- 
"You should sit in nature for 20 minutes a day.
 Unless you are busy, then you should sit for an hour"
 - Zen Proverb
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to prevent files and directories from being deleted?

[Anand Buddhdev]

On 09/10/2017 13:54, hw wrote:

Mark,

> It is quite obvious that Centos causes issues because it is not
> following the FHS.

Stop right there. CentOS *is* following the FHS. Can you please stop
this whiny complaint against CentOS, and just accept that the packages
you're using are not properly packaged for CentOS 7?

Then, if you still wish to use them, then apply fixes as I have
suggested, and also file bug reports.

You entire basis, by claiming that CentOS is not following the FHS, is
wrong. Now stop propagating it.

Regards,
Anand
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to prevent files and directories from being deleted?

[Anand Buddhdev]

On 09/10/2017 12:38, hw wrote:

>> 4. Finally, if you as a sysadmin are using a package from a repo that
>> isn't CentOS or EPEL, and this package is not following the CentOS
>> packaging protocol for data in /run, then it is YOUR own responsibility
>> to fix the package, or create your own tmpfiles.d snippet to create the
>> required directories.
> 
> Lighttpd is from epel.

Then it's a big bug, and you should immediately file a bug report for
it, so that the packager can fix it. Packages in CentOS as well as EPEL
aren't perfect, and sometimes need to be fixed. We can help by filing
bug reports.

> I´m not whining, and it´s not my fault that someone came up with the
> extremely stupid idea to use a ramdisk for /var/run.  It´s also not my
> fault that lighttpd appears not to be packaged the way it would need to
> be, and the same goes for the mariadb packages provided for Centos by
> the mariadb people.

CentOS 7 was released in August 2015, which is over 2 years ago. Any
package that hasn't adapted to CentOS 7's temporary /var/run by now is
badly broken. I would either avoid using it, or file a bug report for it
(and use my own tmpfiles.d file in the meantime).

Or, you can download the SRPM of the package, introduce a tmpfiles.d
snippet and rebuild the package yourself.

You have many choices to make it work properly.

> Perhaps you should complain to whomever made this change for not waiting
> until all packages have been modified and to the package managers who
> didn´t modify them before actually deploying it, for not to mention the
> stupidity of the idea, rather than accusing me of whining.

I shouldn't, because I'm not using the package in question. I *have*
used other packages from EPEL, where I've seen this problem, and I've
filed bug reports for them, repackaged them myself, or used my own
custom tmpfiles.d file to work around the package's deficiency.

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

Re: [CentOS] how to prevent files and directories from being deleted?

[Valeri Galtsev]

On Mon, October 9, 2017 3:31 pm, Jon LaBadie wrote:
> On Mon, Oct 09, 2017 at 08:32:32PM +0200, Alexander Dalloz wrote:
>> Am 09.10.2017 um 17:54 schrieb Jonathan Billings:
>> > I think that the important learning points today are:
>> >
>> > 1.) CentOS7 (and any other distro that uses systemd) will have /run as
>> > a tmpfs filesystem, and /var/run points to /run on CentOS7, so even if
>> > you think this disagrees with the FHS, that's the way it is for
>> > CentOS.
>>
>> And fun fact: not only RHEL 7 and thus CentOS 7 does so, but too Debian
>> 9
>> and Ubuntu 16.04 LTS (I have no newer test install of that distro).
>>
>> And frankly speaking, I don't see any indication that this violates with
>> the
>> FHS and that /var/run must persist reboots.
>>
> Just the opposite, the FHS condones the CentOS arrangement.
>
> Under /var/run it says:
>
>   "In general, the requirements for /run shall also apply to /var/run.
>It is valid to implement /var/run as a symlink to /run."

Indeed, there are many UNIX ties Linux had that were severed by hard work
of developing systemd and friends. I guess we just have to live with that
(sigh).

Valeri

>
> jl
> --
> Jon H. LaBadie j...@jgcomp.com
>  11226 South Shore Rd.  (703) 787-0688 (H)
>  Reston, VA  20190  (703) 935-6720 (C)
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

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

Re: [CentOS] how to prevent files and directories from being deleted?

[Jon LaBadie]

On Mon, Oct 09, 2017 at 08:32:32PM +0200, Alexander Dalloz wrote:
> Am 09.10.2017 um 17:54 schrieb Jonathan Billings:
> > I think that the important learning points today are:
> > 
> > 1.) CentOS7 (and any other distro that uses systemd) will have /run as
> > a tmpfs filesystem, and /var/run points to /run on CentOS7, so even if
> > you think this disagrees with the FHS, that's the way it is for
> > CentOS.
> 
> And fun fact: not only RHEL 7 and thus CentOS 7 does so, but too Debian 9
> and Ubuntu 16.04 LTS (I have no newer test install of that distro).
> 
> And frankly speaking, I don't see any indication that this violates with the
> FHS and that /var/run must persist reboots.
> 
Just the opposite, the FHS condones the CentOS arrangement.

Under /var/run it says:

  "In general, the requirements for /run shall also apply to /var/run.
   It is valid to implement /var/run as a symlink to /run."

jl
-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to prevent files and directories from being deleted?

[Jon LaBadie]

> 
> Best practises also involve to generally not delete files unless you can
> be sure that they can be deleted.  That is probably what the FHS
> intended by specifying that files in /var/run must be deleted/truncated
> at boot time, assuming that the programs that created them would do this
> (and then create them anew if needed), which can be assumed to be
> reasonably safe since it implies that unknown files remain.
> 
> For all I know, someones life could depend on a file that was placed
> somewhere mistakenly.
> 
What a strawman.  You mean that person would still be alive
if the file disappeared during boot rather than shutdown?

jl
-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to prevent files and directories from being deleted?

[Alexander Dalloz]

Am 09.10.2017 um 17:54 schrieb Jonathan Billings:

I think that the important learning points today are:

1.) CentOS7 (and any other distro that uses systemd) will have /run as
a tmpfs filesystem, and /var/run points to /run on CentOS7, so even if
you think this disagrees with the FHS, that's the way it is for
CentOS.


And fun fact: not only RHEL 7 and thus CentOS 7 does so, but too Debian 
9 and Ubuntu 16.04 LTS (I have no newer test install of that distro).


And frankly speaking, I don't see any indication that this violates with 
the FHS and that /var/run must persist reboots.


Can we please end this stupid discussion? Enough arguments have been 
exchanged to make clear that packages are broken if they ignore the fact 
that /var/run content is ephemeral.


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

Re: [CentOS-es] OT Imagen de disco

[Ricardo J. Barberis]

El Sábado 07/10/2017 a las 13:20, Cesar Martinez escribió:
> Saludos amigos listeros espero todos se encuentren bien acudo a ustedes
> para hacerles una pregunta haber si alguien tiene experiencia y me puede
> orientar con esta consulta.
>
> Tengo un cliente en el cuál inicialmente instalé un servidor proxy con
> centos 7 y de acuerdo a sus necesidades a ido creciendo en tema de
> servicios ya tiene un sistema con mysql un servidor de correo y una vpn,
> por temas de seguridad he sacado un respaldo de todos los archivos de
> configuración y tengo un script que se ejecuta cada noche y genera un
> respaldo de las bases de datos de mysql y lo saca fuera de este
> servidor, ahora por temas de velocidad en caso de un desastre, que el
> disco falle se dañe la maquina o peor aún se lleven la máquina el tiempo
> de volver a levantar todo puede ser alto para ello me preguntaba si
> alguien sabe o a implementado algún sistema que se pueda ejecutar una
> imagen completa de todo el disco tipo una ISO, de tal forma que si pasa
> algo poder usar esta ISO en un nuevo disco y el tiempo de estar fuera
> con estos servicios sea mínimo.
>
> De antemano gracias a todos.

Hace poco RedHat (y por lo tanto CentOS) incorporo ReaR a sus repositorios,
creo que es exactamente lo que buscas (aunque no lo he usado personalmente):

[root@centos7 ~] # LANG=C yum info rear
Loaded plugins: changelog, fastestmirror, keys, priorities
Loading mirror speeds from cached hostfile
Available Packages
Name: rear
Arch: x86_64
Version : 2.00
Release : 2.el7
Size: 434 k
Repo: base/7/x86_64
Summary : Relax-and-Recover is a Linux disaster recovery and system 
migration tool
URL : http://relax-and-recover.org/
License : GPLv3
Description : Relax-and-Recover is the leading Open Source disaster recovery 
and system
: migration solution. It comprises of a modular
: frame-work and ready-to-go workflows for many common situations 
to produce
: a bootable image and restore from backup using this image. As a 
benefit,
: it allows to restore to different hardware and can therefore be 
used as
: a migration tool as well.
:
: Currently Relax-and-Recover supports various boot media (incl. 
ISO, PXE,
: OBDR tape, USB or eSATA storage), a variety of network protocols 
(incl.
: sftp, ftp, http, nfs, cifs) as well as a multitude of backup 
strategies
: (incl.  IBM TSM, HP DataProtector, Symantec NetBackup, EMC 
NetWorker,
: Bacula, Bareos, rsync).
:
: Relax-and-Recover was designed to be easy to set up, requires no 
maintenance
: and is there to assist when disaster strikes. Its 
setup-and-forget nature
: removes any excuse for not having a disaster recovery solution 
implemented.
:
: Professional services and support are available.


Saludos,
-- 
Ricardo J. Barberis
Usuario Linux Nº 250625: http://counter.li.org/
Usuario LFS Nº 5121: http://www.linuxfromscratch.org/
Senior SysAdmin / IT Architect - www.DonWeb.com
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS] how to prevent files and directories from being deleted?

[Jonathan Billings]

On Mon, Oct 09, 2017 at 12:38:41PM +0200, hw wrote:
> I´m not whining, and it´s not my fault that someone came up with the
> extremely stupid idea to use a ramdisk for /var/run.  It´s also not my
> fault that lighttpd appears not to be packaged the way it would need to
> be, and the same goes for the mariadb packages provided for Centos by
> the mariadb people.
> 
> Perhaps you should complain to whomever made this change for not waiting
> until all packages have been modified and to the package managers who
> didn´t modify them before actually deploying it, for not to mention the
> stupidity of the idea, rather than accusing me of whining.

I think that the important learning points today are:

1.) CentOS7 (and any other distro that uses systemd) will have /run as
a tmpfs filesystem, and /var/run points to /run on CentOS7, so even if
you think this disagrees with the FHS, that's the way it is for
CentOS.

2.) If you are using non-CentOS packages (and that includes EPEL) to
run a service, you might need to create your own tmpfiles.d files.
This is just a fact of life now.  You can also file bugs against the
software telling them that /var/run is ephemeral so don't store
important files there.

3.) Systemd developers aren't going to sit around and wait for
developers to change how they put files.  They've made a lot of
significant changes to how systems are managed, for better or for
worst, and as people who maintain CentOS systems, we've got to learn
to use it appropriately.

There's a lot of conversations that end, "This is how it's done."
"But that's stupid!" "Well, tough, that's how it is..." when managing
computers, and I'm sure this won't be the last like it.  (I remember
early in my career wondering why creat() was spelled that way...)

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

Re: [CentOS] how to prevent files and directories from being deleted?

[Jonathan Billings]

On Mon, Oct 09, 2017 at 02:06:35PM +0200, hw wrote:
> > If the EPEL package did too, then there could be serious problems with
> > that package. However, I see that it has a
> > /usr/lib/tmpfiles.d/lighttpd.conf, so it is ok.
> 
> Hm, then how come it´s so troublesome?
> 
> I have /usr/lib/tmpfiles.d/httpd.conf.  It seems to have remained
> because I had httpd (which is apache) installed and then switched to
> lighttpd and removed httpd.
> 
> httpd is no longer installed.  The only installed package referring to
> it is apache-commons-logging, and I don´t know why it hasn´t been
> removed.
> 
> The contents of /usr/lib/tmpfiles.d/httpd.conf indicate that this file
> is for apache.  Why hasn´t this file been removed when httpd was
> removed?
> 
> There is no file lighttpd.conf in /usr/lib/tmpfiles.d.
> 
> Does this mean that both packages, httpd and lighttpd, have serious
> problems because they do not remove and do not install files correctly?

You are right, the EPEL version of lighttpd doesn't have a tmpfiles.d
file.  I foolishly expected the Fedora package to be similar to the
EPEL package, but looking at the RPM spec file, it only installs the
tmpfiles.d file for Fedora 15 or greater.  Probably worth filing a bug
against EPEL about that.

I can't explain why your httpd tmpfiles.d file is still there, other
than if it was saved as part of an upgrade/removal because of local
changes. (and even then, it should have a .rpmsave extension, I
think).  It's not marked as a config file in the RPM, so that's
unlikely.

It is owned by the httpd package:
$ rpm -qf /usr/lib/tmpfiles.d/httpd.conf
httpd-2.4.6-67.el7_4.2.x86_64


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

Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

[Nux!]

That's great, thanks

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Richard Grainger" 
> To: "CentOS mailing list" 
> Sent: Monday, 9 October, 2017 16:07:09
> Subject: Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

> Nux!:
> 
> SRPMS published: https://harbottle.gitlab.io/wine32/7/SRPMS/
> 
> Cheers!
> 
> On Mon, Oct 9, 2017 at 1:28 PM, Richard Grainger  wrote:
> 
>> Yes, I will look into getting the SRPMS up on the site (though they are
>> just the ones from EPEL anyway).
>>
>> On Mon, Oct 9, 2017 at 11:54 AM, Nux!  wrote:
>>
>>> Hello,
>>>
>>> That's great, I know many people were looking for this.
>>>
>>> Any chance you can also publish the SRPMs?
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> - Original Message -
>>> > From: "Richard Grainger" 
>>> > To: "CentOS mailing list" 
>>> > Sent: Sunday, 8 October, 2017 19:43:57
>>> > Subject: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7
>>>
>>> > Hi all
>>> >
>>> > I've created a yum repo for 32 bit wine packages on RHEL and CentOS 7:
>>> >
>>> > https://harbottle.gitlab.io/wine32/7/i386/
>>> >
>>> > The Wine packages work on both 32 bit and 64 bit RHEL/CentOS 7. There
>>> is no
>>> > 32 bit version of the EPEL repo, where the standard RHEL/CentOS Wine
>>> > packages can be found, so you may find this new repo useful if you need
>>> to
>>> > run Windows software that requires the 32 bit version of Wine.
>>> >
>>> > The packages are all built from the EPEL source RPMs.  I had to tweak
>>> the
>>> > spec file for wine itself slightly, but for the dependencies it's all
>>> pure
>>> > rebuilds.
>>> >
>>> > Instructions:
>>> >
>>> > Code:
>>> > yum -y install https://harbottle.gitlab.io/wi
>>> ne32/7/i386/wine32-release.rpm
>>> > yum -y install wine.i686
>>> >
>>> >
>>> > Please give it a try and tell me what you think!  It probably needs more
>>> > testing.
>>> > ___
>>> > CentOS mailing list
>>> > CentOS@centos.org
>>> > https://lists.centos.org/mailman/listinfo/centos
>>> ___
>>> CentOS mailing list
>>> CentOS@centos.org
>>> https://lists.centos.org/mailman/listinfo/centos
>>>
>>
>>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

[Richard Grainger]

Nux!:

SRPMS published: https://harbottle.gitlab.io/wine32/7/SRPMS/

Cheers!

On Mon, Oct 9, 2017 at 1:28 PM, Richard Grainger  wrote:

> Yes, I will look into getting the SRPMS up on the site (though they are
> just the ones from EPEL anyway).
>
> On Mon, Oct 9, 2017 at 11:54 AM, Nux!  wrote:
>
>> Hello,
>>
>> That's great, I know many people were looking for this.
>>
>> Any chance you can also publish the SRPMs?
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>> > From: "Richard Grainger" 
>> > To: "CentOS mailing list" 
>> > Sent: Sunday, 8 October, 2017 19:43:57
>> > Subject: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7
>>
>> > Hi all
>> >
>> > I've created a yum repo for 32 bit wine packages on RHEL and CentOS 7:
>> >
>> > https://harbottle.gitlab.io/wine32/7/i386/
>> >
>> > The Wine packages work on both 32 bit and 64 bit RHEL/CentOS 7. There
>> is no
>> > 32 bit version of the EPEL repo, where the standard RHEL/CentOS Wine
>> > packages can be found, so you may find this new repo useful if you need
>> to
>> > run Windows software that requires the 32 bit version of Wine.
>> >
>> > The packages are all built from the EPEL source RPMs.  I had to tweak
>> the
>> > spec file for wine itself slightly, but for the dependencies it's all
>> pure
>> > rebuilds.
>> >
>> > Instructions:
>> >
>> > Code:
>> > yum -y install https://harbottle.gitlab.io/wi
>> ne32/7/i386/wine32-release.rpm
>> > yum -y install wine.i686
>> >
>> >
>> > Please give it a try and tell me what you think!  It probably needs more
>> > testing.
>> > ___
>> > CentOS mailing list
>> > CentOS@centos.org
>> > https://lists.centos.org/mailman/listinfo/centos
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
>
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

[Richard Grainger]

Ah, no, those are just wine dependencies from epel. No base updates :)

On Mon, Oct 9, 2017 at 2:48 PM, Nux!  wrote:

> Richard,
>
> I haven't checked, but I see more than wine packages in that repo, hence
> my thoughts about that.
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Richard Grainger" 
> > To: "CentOS mailing list" 
> > Sent: Monday, 9 October, 2017 14:29:03
> > Subject: Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS
> 7
>
> > Shouldn't be anything overwriting Base...what do you think does so?
> >
> > On Mon, Oct 9, 2017 at 2:01 PM, Nux!  wrote:
> >
> >> Ah, ok. I was wondering how you  managed to build that, because when I
> >> tried it did not work, but I see you have backported also other bits and
> >> bobs.
> >> If those overwrite Base, perhaps add a warning of sorts.
> >>
> >> --
> >> Sent from the Delta quadrant using Borg technology!
> >>
> >> Nux!
> >> www.nux.ro
> >>
> >> - Original Message -
> >> > From: "Richard Grainger" 
> >> > To: "CentOS mailing list" 
> >> > Sent: Monday, 9 October, 2017 13:28:22
> >> > Subject: Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and
> CentOS
> >> 7
> >>
> >> > Yes, I will look into getting the SRPMS up on the site (though they
> are
> >> > just the ones from EPEL anyway).
> >> >
> >> > On Mon, Oct 9, 2017 at 11:54 AM, Nux!  wrote:
> >> >
> >> >> Hello,
> >> >>
> >> >> That's great, I know many people were looking for this.
> >> >>
> >> >> Any chance you can also publish the SRPMs?
> >> >>
> >> >> --
> >> >> Sent from the Delta quadrant using Borg technology!
> >> >>
> >> >> Nux!
> >> >> www.nux.ro
> >> >>
> >> >> - Original Message -
> >> >> > From: "Richard Grainger" 
> >> >> > To: "CentOS mailing list" 
> >> >> > Sent: Sunday, 8 October, 2017 19:43:57
> >> >> > Subject: [CentOS] Announcement: 32 bit Wine repo for RHEL and
> CentOS 7
> >> >>
> >> >> > Hi all
> >> >> >
> >> >> > I've created a yum repo for 32 bit wine packages on RHEL and
> CentOS 7:
> >> >> >
> >> >> > https://harbottle.gitlab.io/wine32/7/i386/
> >> >> >
> >> >> > The Wine packages work on both 32 bit and 64 bit RHEL/CentOS 7.
> There
> >> is
> >> >> no
> >> >> > 32 bit version of the EPEL repo, where the standard RHEL/CentOS
> Wine
> >> >> > packages can be found, so you may find this new repo useful if you
> >> need
> >> >> to
> >> >> > run Windows software that requires the 32 bit version of Wine.
> >> >> >
> >> >> > The packages are all built from the EPEL source RPMs.  I had to
> tweak
> >> the
> >> >> > spec file for wine itself slightly, but for the dependencies it's
> all
> >> >> pure
> >> >> > rebuilds.
> >> >> >
> >> >> > Instructions:
> >> >> >
> >> >> > Code:
> >> >> > yum -y install https://harbottle.gitlab.io/
> >> wine32/7/i386/wine32-release.
> >> >> rpm
> >> >> > yum -y install wine.i686
> >> >> >
> >> >> >
> >> >> > Please give it a try and tell me what you think!  It probably needs
> >> more
> >> >> > testing.
> >> >> > ___
> >> >> > CentOS mailing list
> >> >> > CentOS@centos.org
> >> >> > https://lists.centos.org/mailman/listinfo/centos
> >> >> ___
> >> >> CentOS mailing list
> >> >> CentOS@centos.org
> >> >> https://lists.centos.org/mailman/listinfo/centos
> >> >>
> >> > ___
> >> > CentOS mailing list
> >> > CentOS@centos.org
> >> > https://lists.centos.org/mailman/listinfo/centos
> >> ___
> >> CentOS mailing list
> >> CentOS@centos.org
> >> https://lists.centos.org/mailman/listinfo/centos
> >>
> > ___
> > CentOS mailing list
> > CentOS@centos.org
> > https://lists.centos.org/mailman/listinfo/centos
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

[Nux!]

Richard,

I haven't checked, but I see more than wine packages in that repo, hence my 
thoughts about that.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Richard Grainger" 
> To: "CentOS mailing list" 
> Sent: Monday, 9 October, 2017 14:29:03
> Subject: Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

> Shouldn't be anything overwriting Base...what do you think does so?
> 
> On Mon, Oct 9, 2017 at 2:01 PM, Nux!  wrote:
> 
>> Ah, ok. I was wondering how you  managed to build that, because when I
>> tried it did not work, but I see you have backported also other bits and
>> bobs.
>> If those overwrite Base, perhaps add a warning of sorts.
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>> > From: "Richard Grainger" 
>> > To: "CentOS mailing list" 
>> > Sent: Monday, 9 October, 2017 13:28:22
>> > Subject: Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS
>> 7
>>
>> > Yes, I will look into getting the SRPMS up on the site (though they are
>> > just the ones from EPEL anyway).
>> >
>> > On Mon, Oct 9, 2017 at 11:54 AM, Nux!  wrote:
>> >
>> >> Hello,
>> >>
>> >> That's great, I know many people were looking for this.
>> >>
>> >> Any chance you can also publish the SRPMs?
>> >>
>> >> --
>> >> Sent from the Delta quadrant using Borg technology!
>> >>
>> >> Nux!
>> >> www.nux.ro
>> >>
>> >> - Original Message -
>> >> > From: "Richard Grainger" 
>> >> > To: "CentOS mailing list" 
>> >> > Sent: Sunday, 8 October, 2017 19:43:57
>> >> > Subject: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7
>> >>
>> >> > Hi all
>> >> >
>> >> > I've created a yum repo for 32 bit wine packages on RHEL and CentOS 7:
>> >> >
>> >> > https://harbottle.gitlab.io/wine32/7/i386/
>> >> >
>> >> > The Wine packages work on both 32 bit and 64 bit RHEL/CentOS 7. There
>> is
>> >> no
>> >> > 32 bit version of the EPEL repo, where the standard RHEL/CentOS Wine
>> >> > packages can be found, so you may find this new repo useful if you
>> need
>> >> to
>> >> > run Windows software that requires the 32 bit version of Wine.
>> >> >
>> >> > The packages are all built from the EPEL source RPMs.  I had to tweak
>> the
>> >> > spec file for wine itself slightly, but for the dependencies it's all
>> >> pure
>> >> > rebuilds.
>> >> >
>> >> > Instructions:
>> >> >
>> >> > Code:
>> >> > yum -y install https://harbottle.gitlab.io/
>> wine32/7/i386/wine32-release.
>> >> rpm
>> >> > yum -y install wine.i686
>> >> >
>> >> >
>> >> > Please give it a try and tell me what you think!  It probably needs
>> more
>> >> > testing.
>> >> > ___
>> >> > CentOS mailing list
>> >> > CentOS@centos.org
>> >> > https://lists.centos.org/mailman/listinfo/centos
>> >> ___
>> >> CentOS mailing list
>> >> CentOS@centos.org
>> >> https://lists.centos.org/mailman/listinfo/centos
>> >>
>> > ___
>> > CentOS mailing list
>> > CentOS@centos.org
>> > https://lists.centos.org/mailman/listinfo/centos
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] New CentOS/RHEL group on Facebook

[H]

On October 9, 2017 2:25:46 PM GMT+02:00, Richard 
 wrote:
>I second this. I find it rather ironic that one would try to initiate
>discussion of an open source operating system and environment in a
>proprietary walled off world. This seems rather antithetical to the
>whole intent of centos. 
>
>  - Richard
>
>
> Original Message 
>> Date: Monday, October 09, 2017 12:14:55 +0100
>> From: Nux! 
>>
>> I personally dislike Facebook, but even so, I think a basic
>> requirement for any web site striving to share knowledge is to be
>> publicly accessible to all which at the moment it is not. Search
>> engines won't be able to crawl it, people without an account won't
>> be able to access it.
>> 
>> Can this be changed?
>> 
>> Thanks
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
>> 
>> - Original Message -
>>> From: "Nicolas Kovacs" 
>>> To: "CentOS mailing list" 
>>> Sent: Sunday, 8 October, 2017 15:48:29
>>> Subject: [CentOS] New CentOS/RHEL group on Facebook
>> 
>>> Hi,
>>> 
>>> There are currently two competing CentOS groups on Facebook. The
>>> "main" group is managed by a small group of autocrats with very
>>> unilateral communication skills. The other one is not managed at
>>> all, judged by the amount of non-CentOS-related stuff published
>>> there (Ubuntu tutorials, Windows games, cheap Ray-Ban sunglasses).
>>> 
>>> I was a bit frustrated by this state of things, the more so since
>>> I've successfully managed the Slackware Linux Facebook group for a
>>> couple of years, regulating publications, keeping folks on topic
>>> and banning the odd spammer.
>>> 
>>> So I decided to do the same thing I would do in a software
>>> development context. Fork the project and create a different
>>> CentOS/RHEL Facebook group. The goal of this group would simply be
>>> to provide a no-nonsense discussion platform for all the CentOS
>>> and Red Hat Enterprise Linux users out there. Publications would
>>> be strictly CentOS/RHEL-centered, but on the other hand, you'd be
>>> free to share your CentOS-related blog posts, tutorials and
>>> documentation without getting flamed or banned by an admin.
>>> 
>>> Anyway, feel free to join the new group:
>>> 
>>> https://www.facebook.com/groups/2136021589748759/
>>> 
>>> Cheers from the sunny South of France,
>>> 
>>> Niki Kovacs
>>> --
> End Original Message 
>
>
>___
>CentOS mailing list
>CentOS@centos.org
>https://lists.centos.org/mailman/listinfo/centos

+1
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

[Richard Grainger]

Shouldn't be anything overwriting Base...what do you think does so?

On Mon, Oct 9, 2017 at 2:01 PM, Nux!  wrote:

> Ah, ok. I was wondering how you  managed to build that, because when I
> tried it did not work, but I see you have backported also other bits and
> bobs.
> If those overwrite Base, perhaps add a warning of sorts.
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Richard Grainger" 
> > To: "CentOS mailing list" 
> > Sent: Monday, 9 October, 2017 13:28:22
> > Subject: Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS
> 7
>
> > Yes, I will look into getting the SRPMS up on the site (though they are
> > just the ones from EPEL anyway).
> >
> > On Mon, Oct 9, 2017 at 11:54 AM, Nux!  wrote:
> >
> >> Hello,
> >>
> >> That's great, I know many people were looking for this.
> >>
> >> Any chance you can also publish the SRPMs?
> >>
> >> --
> >> Sent from the Delta quadrant using Borg technology!
> >>
> >> Nux!
> >> www.nux.ro
> >>
> >> - Original Message -
> >> > From: "Richard Grainger" 
> >> > To: "CentOS mailing list" 
> >> > Sent: Sunday, 8 October, 2017 19:43:57
> >> > Subject: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7
> >>
> >> > Hi all
> >> >
> >> > I've created a yum repo for 32 bit wine packages on RHEL and CentOS 7:
> >> >
> >> > https://harbottle.gitlab.io/wine32/7/i386/
> >> >
> >> > The Wine packages work on both 32 bit and 64 bit RHEL/CentOS 7. There
> is
> >> no
> >> > 32 bit version of the EPEL repo, where the standard RHEL/CentOS Wine
> >> > packages can be found, so you may find this new repo useful if you
> need
> >> to
> >> > run Windows software that requires the 32 bit version of Wine.
> >> >
> >> > The packages are all built from the EPEL source RPMs.  I had to tweak
> the
> >> > spec file for wine itself slightly, but for the dependencies it's all
> >> pure
> >> > rebuilds.
> >> >
> >> > Instructions:
> >> >
> >> > Code:
> >> > yum -y install https://harbottle.gitlab.io/
> wine32/7/i386/wine32-release.
> >> rpm
> >> > yum -y install wine.i686
> >> >
> >> >
> >> > Please give it a try and tell me what you think!  It probably needs
> more
> >> > testing.
> >> > ___
> >> > CentOS mailing list
> >> > CentOS@centos.org
> >> > https://lists.centos.org/mailman/listinfo/centos
> >> ___
> >> CentOS mailing list
> >> CentOS@centos.org
> >> https://lists.centos.org/mailman/listinfo/centos
> >>
> > ___
> > CentOS mailing list
> > CentOS@centos.org
> > https://lists.centos.org/mailman/listinfo/centos
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Intel turbo mode

[hw]

Stephen John Smoogen  writes:

> On 3 October 2017 at 13:01, hw  wrote:
>> Stephen John Smoogen  writes:
>>
>>> On 1 October 2017 at 11:34, hw  wrote:
 Hi,

 is there a way in Centos to find out if the Intel turbo mode will be
 used?

 Using the 'stress' utility and checking the frequency with cpupower
 tells me that a CPU is running at it´s maximum frequency as reported by
 cpupower --- and this frequency is less than the frequency it would run
 at if it used the turbo mode.  All the other CPUs are at their minimum
 frequency.  I have verified that turbo mode is enabled in the BIOS.

 Is cpupower unable to report frequencies used in turbo mode despite it
 always says it gets its information from the hardware?

>>>
>>> It would seem that there are multiple ways to get the information you
>>> are looking for. I expect you have seen this already
>>>
>>> https://haypo.github.io/intel-cpus.html
>>>
>>> but I figured I would pass it on for others. They found that cpupower
>>> is less reliable in how it reports the data because of the values it
>>> gets them from.
>>
>> Thanks, I didn´t see that one yet.  At least I noticed that cpupower
>> says that turbo mode is available, and turbostat seems to indicate that
>> CPUs sometimes run at higher frequencies like they would when in turbo
>> mode.
>>
>> It´s strange that there is no tool to definitely figure this out,
>> especially since RH seems to have done a lot of research into improving
>> performance.
>>
>
> My limited understanding is that it isn't very reliable to show it and
> the Windows ones distort reality a lot (aka say you are in it when you
> aren't actually in it) because they do a moving average to show what
> is going on so it doesn't look as jagged as it really is.

I guess the same could be said for turbostat because it show some
computed frequency.

> It is also not all that useful for general software needs. The CPU is
> going to be waiting a lot longer now for memory and io to catch up for
> most transactions.

Does it hurt anything when it waits faster?  It might have the advantage
that it doesn´t wait longer than it otherwise would and processes things
somewhat faster when it finally does.  For how long it takes until
processing is finished, it doesn´t matter if the CPU waits longer when
it still takes the same amount of time, and chances are it might not
take as long.

Or am I mistaken?

Anyway, it seems to me as if there´s actually no way to figure out if
the CPU is at turbo frequencies because it decides that for itself.  But
then, I have an E3-1230 V2 here, and even cpupower reports its turbo
frequencies.


-- 
"Didn't work" is an error.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Weird bandwith behaviour (download throughput) on CentOS based gateway

[hw]

Jobst Schmalenbach  writes:

> On Thu, Oct 05, 2017 at 02:57:18PM +1300, Clint Dilks 
> (cli...@scms.waikato.ac.nz) wrote:
>> On Thu, Oct 5, 2017 at 2:41 PM, Jobst Schmalenbach 
>> wrote:
>> [snip]
>> Hi,
>> 
>> Are you sure  that your issue  isn't related to the mirror that your
>> systems are selecting ?  If they are using different mirrors I would try
>> using the fastestmirror plugin to make the gateway select the same mirror
>> as you other host.
>
> Darn
>
> I should have included in the initial email that I actually ran EXTRA
> tests from a {local} CentOS mirror using wget after I figured there
> was some differences in the "yum update" times ...
>
> The Gateway:
>
>   [root@GATEWAY /tmp] #>wget 
> http://mirror.internode.on.net/pub/centos/6.9/isos/x86_64/CentOS-6.9-x86_64-bin-DVD1.iso
>   --2017-10-05 14:59:55--  
> http://mirror.internode.on.net/pub/centos/6.9/isos/x86_64/CentOS-6.9-x86_64-bin-DVD1.iso
>   Resolving mirror.internode.on.net... 150.101.135.3
>   Connecting to mirror.internode.on.net|150.101.135.3|:80... connected.
>   HTTP request sent, awaiting response... 200 OK
>   Length: 3972005888 (3.7G) [application/octet-stream]
>   Saving to: “CentOS-6.9-x86_64-bin-DVD1.iso”
>   0% [
>   ] 4,454,198680K/s
>
> One of the hosts behind it:
>
>   [root@piquet /tmp] #>wget 
> http://mirror.internode.on.net/pub/centos/6.9/isos/x86_64/CentOS-6.9-x86_64-bin-DVD1.iso
>   --2017-10-05 15:01:32--  
> http://mirror.internode.on.net/pub/centos/6.9/isos/x86_64/CentOS-6.9-x86_64-bin-DVD1.iso
>   Resolving mirror.internode.on.net... 150.101.135.3
>   Connecting to mirror.internode.on.net|150.101.135.3|:80... connected.
>   HTTP request sent, awaiting response... 200 OK
>   Length: 3972005888 (3.7G) [application/octet-stream]
>   Saving to: `CentOS-6.9-x86_64-bin-DVD1.iso'
>   0% [
>   ] 13,616,730  2.4M/s

Is there a dependency on which machine you test first?  Perhaps the file
has been stored in some cache along the way and for the second test, it
can be delivered from the cache instead of from the source, which might
yield higher speeds.


-- 
"Didn't work" is an error.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to prevent files and directories from being deleted?

[hw]

Mark Haney  writes:

> On 10/04/2017 08:46 AM, Gary Stainburn wrote:
>> On Wednesday 04 October 2017 13:39:30 Mark Haney wrote:
>>> I'll end this by saying, I hope the production servers you have don't
>>> provide critical services that could jeopardize the lives of people.
>>> I'd ask who you work for, to make sure I avoid them at all costs, but
>>> I'm not sure I'd be told.
>> The company I work for, and the livelihood of the hundreds of employees 
>> depend
>> on my servers. In the 30 years I've been in the industry, I've never had
>> problems as you've described
>> ___
>
> In 30 years you've obviously learned nothing about Unix/Linux.  I'd be
> embarrassed to claim that length of IT service and do something as
> catastrophically stupid as what you're doing now.  Just because it
> hasn't been a problem' doesn't mean it won't.  Seriously, if it were
> me, I'd either retire or hire someone better than you with production
> servers.
>
> You'd think, with your supposed experience, you wouldn't use the 'well
> it's never happened before' as a viable reason for doing something. 
> That's ignorant, immature and far more dangerous for your organization
> than I would be happy with as a CEO or Manager. That attitude is never
> excusable.

What do you propose as an alternative?

You can test something, like some software, over and over again in any
way that comes to mind, and at some point, you may conclude that it
seems to be working and may go into production.  That conclusion is
solely based upon "it hasn´t happened yet", simply because whatever bug
of what you´re testing hasn´t shown any effect yet.

Following your argumentation, you would never have a reason to put
something into production, or to use it.

> This conversation is over. You refuse to listen to literally EVERYONE
> ELSE ON THE LIST and therefore not worth anyone else's time trying to
> help you.  (Especially mine.)

Who else?

> I showed my daughter this thread, she's a freshman in the Honors
> College of Engineering at Virginia Tech majoring in Math and CpE, has
> been using linux since she was old enough to sit at a keyboard and
> even she was appalled.  If that doesn't tell you something, nothing
> will.

What was she appalled about?

> Do us all a favor and don't post to the list unless you are willing to
> listen to rational human beings.


-- 
"Didn't work" is an error.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to prevent files and directories from being deleted?

[hw]

Gary Stainburn  writes:

> On Tuesday 03 October 2017 18:24:01 Mark Haney wrote:
>> What issue? That the PID is dropped on reboot?  What else are you
>> putting in there?  I'm beginning to question whether you know what
>> you're doing or not.  Lighttpd doesn't store any persistent info in
>> /var/run/ because, like everything else, /var/run isn't for persistent
>> data.
>
> Mark, Many Non-Centos originated packages create directories in /var/run as 
> part of the install, and expect them to still exist after a reboot.

I would also expect that.

> They then fail when starting the service because they're trying to create a 
> PID / Lock file in a directory that no longer exists.  This problem has been 
> around ever since /var/run was moved to tmpfs.

A ramdisk?  That´s an incredibly stupid idea.  Ramdisks should not be
used by default.

Is there a way to change that?

> Unfortunately, sometimes we have to use packages other than the official 
> Centos ones, usually as in this case because we need newer versions.
>
> There is a solution that saves /var/run to disk at shutdown and restores it 
> at 
> bootup but I can't remember what it is.

That doesn´t protect you in case of a power failure and may increase
shutdown durations to a point where the amount of time it takes to
shutdown isn´t fully covered by the UPS.


-- 
"Didn't work" is an error.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to prevent files and directories from being deleted?

[hw]

Gordon Messmer  writes:

> On 10/04/2017 04:54 AM, Mark Haney wrote:
>> Why is it so hard for people to understand that var/run IS NOT
>> PERSISTENT and was never meant to be?  Do they not teach basic Unix
>> concepts anymore?
>
>
> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA
>
> While FHS notes that *files* should be cleared during the boot
> process, it does not indicate that directories should be, and that is
> the source of this problem.

That´s a really good point, thank you.

> Packages on recent Fedora, RHEL, or CentOS releases should use
> tmpfiles.d to define directory structure within /var/run, but that is
> a unique and recent development.
>
> Please chill out.  There is no need to berate users, here.


-- 
"Didn't work" is an error.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to prevent files and directories from being deleted?

[hw]

Mark Haney  writes:

> On 10/04/2017 04:23 AM, Gary Stainburn wrote:
>>
>> Mark, Many Non-Centos originated packages create directories in /var/run as
>> part of the install, and expect them to still exist after a reboot.
>>
>> They then fail when starting the service because they're trying to create a
>> PID / Lock file in a directory that no longer exists.  This problem has been
>> around ever since /var/run was moved to tmpfs.
>>
>> Unfortunately, sometimes we have to use packages other than the official
>> Centos ones, usually as in this case because we need newer versions.
>>
>> There is a solution that saves /var/run to disk at shutdown and restores it 
>> at
>> bootup but I can't remember what it is.
> Sorry, but if you have to use packages that don't originate from
> CentOS and they do that, then I wouldn't use them. Period.  I'd
> compile from source before I used something configured that way.
>
> Why is it so hard for people to understand that var/run IS NOT
> PERSISTENT and was never meant to be?

This isn´t true, the directory is persistent, and the FHS says:

"Files under this directory must be cleared (removed or truncated as
appropriate) at the beginning of the boot process."[1]

[2] doesn´t tell you that files in /var/run will disappear at shutdown.

Using a ramdisk to store such files is not compliant with the FHS
because the files are neither truncated, nor removed; they are being
disappeared, and not at the beginning of the boot process but at
shutdown.  Using a ramdisk is not appropriate.

The safe and compliant way would be to truncate the files and not to
remove or to disappear them.

The FHS doesn´t say /which/ files should be cleared or removed.  I would
say that all files the removal or truncation of is not explicitly
specified must neither be removed, nor truncated, and that automatically
removing files is generally questionable and needs to be done, if at
all, with great care.

I can only speculate (and hope) that the intention of the FHS here is
that programs creating files under /var/run are supposed to remove or
truncate the files they created during the previous runtime, and only
those, when the system boots, which would be the time when those
programs are being started.


[1]:
http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA

[2]:
https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-filesystem-fhs.html


> Do they not teach basic Unix concepts anymore?  If you think that
> setup is acceptable, I wouldn't hire you to water my lawn as you'd
> likely water the electrical box along with said lawn.
>
> These are VERY VERY basic concepts.  Banging a square peg into a round
> hole, even in a test environment is a good way to get fired and become
> unemployable.  And believe me, word gets around quickly in IT
> circles.  If you can't build from source to keep from using
> non-standard packages, then you really shouldn't be doing whatever it
> is you were hired to do.
>
> This is extremely basic arithmetic here.  You don't do surgery with
> dirty scalpels, you don't drive without brakes, these are axiomatic
> just like /var/run isn't persistent.  It's been that way at least
> since I was in HS and college in the 80s and very very likely since
> the early Unix days.

Then how come that the first time I´m seeing an issue like this is only
after someone made the utterly stupid decision to use a ramdisk for
/var/run?

It is a change that has been made at some time, and we weren´t told
about it.  Assuming that people not being informed about a change are
stupid because they don´t know about it is a stupid thing to do.

> Honestly, I feel bad for your employer if you think this is an
> acceptable way to get a system working.
>
> There, I've said my piece. Call it a flame if you want, truth hurts
> and ignoring basic rules is a good way to hurt yourself or other
> people.

Making things worse by providing dirty scalpels or vehicles without
brakes --- with or without telling those who are going to use them ---
doesn´t make things better, and it can be argued that someone providing
those should be fired because of their stupidity.

Alas, the only thing that helps against stupidity is more stupidity.
Getting upset about it does not.


-- 
"Didn't work" is an error.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to prevent files and directories from being deleted?

[hw]

Mark Haney  writes:

> It's quite obvious you aren't using Centos packages.

Again: lighttpd is from epel.

See [1]: "EPEL packages are usually based on their Fedora counterparts
and will never conflict with or replace packages in the base Enterprise
Linux distributions."

If there wasn´t some sort of conflict, then there wouldn´t be an issue
with lighttpd.

Mariadb is from the mariadb repo.

It is quite obvious that Centos causes issues because it is not
following the FHS.


[1]: http://fedoraproject.org/wiki/EPEL

> If you refuse to do as best practices insist (and have for nearly HALF

I´m not insisting on anything, I´m merely pissed that things are broken.
It has turned out that this is due to the way Centos doesn´t follow the
FHS.

Not following the FHS probably doesn´t exactly fall under best
practises, but Centos insists on doing so.

> A CENTURY) then no one here can help you.  It seems to me that 1)
> you'd be better off compiling from source for your environment,

And you guarantee that if I was to compile lighttpd from source, there
wouldn´t be any issues?  Who says that it is better to compile lighttpd
from source rather than using a package specifically made for Centos
that provides it?

Who says that compiling your own packages falls under best practises? Do
you compile all software you´re using yourself because otherwise you´d
be refusing best practises?

I thought it needless to say, but compiling from source instead of using
packages provided by or for the distribution I´m using is virtually the
opposite of following best practises, for a number of reasons.  I only
do that when there isn´t a better alternative.

> or 2) that you need to follow practices established (probably) before
> you were born

Living in the past seldwhen is a good idea.  Lots of practises that were
established before I was born have disappeared, been replaced by others,
or were revised.  Why should I follow outdated practises?

> or 3) that you stop asking the
> list for thing no one in their right mind would do.
>
> How hard is that math?

It doesn´t compute at all.

Please don´t feel insulted by the following; it is not my intention to
insult you.  It´s merely what I´m thinking:

I can see you saying repeatedly that things should be like you want them
to be because you think that they have been the way you think they are
for a long time and that everyone who doesn´t think the same way must be
either out of their right mind, or stupid or both.  That makes me think
that you´re living in the past and, spinning around in that circle, lack
the flexibility often times required nowadays, letting aside that there
seem to be things you´re mistaken about.

My understanding is also that your way of thinking tries to gain
orientation by looking at structures and neglects the contents of those
very structures; which is not a good idea because structures without
content are hollow and rather meaningless, and anything but seldwhen,
the content of these structures is far more relevant than the structures
themselves, and requires to adjust ones ways of thinking --- and
eventually the structures --- accordingly for to come up with desirable
and adequate results.  (IMHO this is something you really need to show
your daughter, even if it probably doesn´t compute for you.)

I´m much more understanding than mathematical.  Unfortunately, math
doesn´t make sense to me, and it is even illogical.  That may very well
qualify as "being out of my right mind" from your perspective, and I can
live with that because from my perspective, it is not true that I am.


-- 
"Didn't work" is an error.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to prevent files and directories from being deleted?

[hw]

Jonathan Billings  writes:

> On Oct 3, 2017, at 13:12, hw  wrote:
>> 
>> I´m using the packages from mariadb.org.  The old version that comes in
>> Centos isn´t recommended, and I need features only the newer versions
>> provide.
>> 
>> 
>> Lighttpd is from epel, and it has basically the same issue.
>
> If the mariadb.org package thinks /var/run is persistent, then it’s not 
> intended for CentOS7. 

Or it is intended for Centos and not done how it needs to be because
Centos differs from the FHS ...

> If the EPEL package did too, then there could be serious problems with
> that package. However, I see that it has a
> /usr/lib/tmpfiles.d/lighttpd.conf, so it is ok.

Hm, then how come it´s so troublesome?

I have /usr/lib/tmpfiles.d/httpd.conf.  It seems to have remained
because I had httpd (which is apache) installed and then switched to
lighttpd and removed httpd.

httpd is no longer installed.  The only installed package referring to
it is apache-commons-logging, and I don´t know why it hasn´t been
removed.

The contents of /usr/lib/tmpfiles.d/httpd.conf indicate that this file
is for apache.  Why hasn´t this file been removed when httpd was
removed?

There is no file lighttpd.conf in /usr/lib/tmpfiles.d.

Does this mean that both packages, httpd and lighttpd, have serious
problems because they do not remove and do not install files correctly?


-- 
"Didn't work" is an error.

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

Re: [CentOS] how to prevent files and directories from being deleted?

[hw]

Anand Buddhdev  writes:

> On 05/10/2017 11:32, hw wrote:
>
>>> That directory isn't temporary.  The files almost always are, but not
>>> the directories.  As I said, whatever it is you're doing, it's wrong. 
>>> I wouldn't continue to keep a setup like that as it's not standard
>>> practice to keep data in /var/run that isn't temporary.
>> 
>> Well, what am I supposed to do?  The socket (or what it was) needs to be
>> put somewhere, and IIRC, it wasn´t my choice to put it there but is a
>> default.  With mariadb, there are some defaults you can´t reasonably
>> change because other software expects files where they usually are.  And
>> I don´t want to change that, I just want mariadb and lighttpd and other
>> things to start on reboots rather than being broken because someone
>> decided that files/directories they require are to be deleted on reboots
>> before they can start.
>
> I can't believe people are still asking this question after being given
> appropriate advice. So let me repeat it, and don't ask again unless
> you've read this properly:

I haven´t had time to read all of this thread before today.

> 1. /var/run is a symlink to /run, which is a tmpfs mounted in RAM.
>
> 2. At reboot, /run vanishes, and EVERYTHING that was in it, vanishes
> with it.
>
> 3. For this reason, systemd ships with a utility called
> systemd-tmpfiles, which is run early in the boot process, to create any
> appropriate files and directories in /run. Packages that require
> directories to be present in /run (for keeping PID files or sockets),
> should ship with the appropriate tmpfiles.d snippets to have these
> directories created for them on boot.
>
> 4. Finally, if you as a sysadmin are using a package from a repo that
> isn't CentOS or EPEL, and this package is not following the CentOS
> packaging protocol for data in /run, then it is YOUR own responsibility
> to fix the package, or create your own tmpfiles.d snippet to create the
> required directories.

Lighttpd is from epel.

> 5. Learn about systemd-tmpfiles by reading the man pages of
> "systemd-tmpfiles" and "tmpfiles.d".
>
> This is as clear as crystal. If, despite this instruction, you cannot,
> or do not want to work with CentOS as it was intended, then stop whining
> about things here.

I´m not whining, and it´s not my fault that someone came up with the
extremely stupid idea to use a ramdisk for /var/run.  It´s also not my
fault that lighttpd appears not to be packaged the way it would need to
be, and the same goes for the mariadb packages provided for Centos by
the mariadb people.

Perhaps you should complain to whomever made this change for not waiting
until all packages have been modified and to the package managers who
didn´t modify them before actually deploying it, for not to mention the
stupidity of the idea, rather than accusing me of whining.


-- 
"Didn't work" is an error.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to prevent files and directories from being deleted?

[hw]

Mark Haney  writes:

> On 10/04/2017 08:22 AM, Gary Stainburn wrote:
>> On Wednesday 04 October 2017 12:54:44 Mark Haney wrote:
>>> Sorry, but if you have to use packages that don't originate from CentOS
>>> and they do that, then I wouldn't use them. Period.  I'd compile from
>>> source before I used something configured that way.
>> This perspective to some extent employs cutting your nose of dispite youre
>> face.  Before Packages were introduced, everyone compiled from source. That
>> was a pain, and a long process, especially when you had dependancies that you
>> also had to compile.  Packages eased this process but kept the dependancy
>> issue.
> If you think using non-standard packages that put /persistent/ items
> in non-persistent locations like /var/run in production environments
> is far more acceptable than compiling from source because of package
> management 'benefits' then (to me anyway) you're lazy and dangerous
> with critical data.  My statement still stands.  Let me be clear:

Please explain how compiling packages yourself turns such packages into
standard packages.

> THIS. IS. NOT. ACCEPTABLE.

It is not acceptable to create the system in such a way that files
indiscriminately disappear, without any check whatsoever if that´s ok.

> The fact you'd rather bandaid a problem (in production no less) than
> follow proper standards or compile from source to avoid said bandaid
> would be a fire-able offense in any IT shop I've ever worked at.

Did they require you to verify all the sources of packages you compiled
yourself to make sure that they behave exactly like the packages that
come with the distribution?

How is compiling packages yourself not another bandaid?

>> Package managers got round (mostly) both the dependancy problem and updating
>> too. The problem with package maintainers not keeping up to date shows that
>> this still isn't perfect.
>>
>> However, if you go back to compiling from source then you lose all of these
>> benefits.
>>
>> Thankfully I do not earn my keep by watering lawns.  I do not believe that
>> this is acceptable, but by the same token I have to earn my keep and that
>> involves having working production servers and services.
>>
>> I have managed to get round this problem in the past through manually doing
>> the same function as systemd-tmpfiles. It is a small price to pay to have a
>> working, (relatively) up to date server.
> The fact you find this acceptable means you're either the only
> qualified' (and even that is subject to doubt) person there, or your
> management is too ignorant to understand the danger.

How is compiling your own packages not a danger?

> I'm sorry, but in no way is this acceptable for production level
> servers. I'm sure, if you asked 100 IT people you'd get 100 to agree
> with me.  Being flippant with production servers is never acceptable.

Then you have to agree that defaulting to using a ramdisk for /var/run
--- or anything else --- is an utterly stupid idea.

> Of course, most people refuse to listen to logic and reason because
> they are convinced they are right despite evidence (and best practices
> over 40+ years of Unix) to the contrary.

I don´t see how compiling your own packages or randomly disappearing
files falls under best practises.

> I'll end this by saying, I hope the production servers you have don't
> provide critical services that could jeopardize the lives of people. 
> I'd ask who you work for, to make sure I avoid them at all costs, but
> I'm not sure I'd be told.
>
> Again, denying 40+ years of Unix design and  best practices because
> you're too lazy to manage compiling from source to avoid denying those
> practices is truly one of the most astonishing things I've ever seen
> in the 25 years I've been in IT.
>
> Then again, maybe I'm old-fashioned when I expect to do something and
> do it right rather than half-ass it.

People always make mistakes.  Best practises can´t be best practises
unless they take this into account, and that involves not deleting,
truncating or disappearing files that have been placed somewhere,
mistakenly or otherwise, lightheadedly.  That particularly applies to
unknown files, like files in /var/run, which have been placed there and
have not been specified for removal, perhaps due to a mistake of the
package manager.

Best practises also involve to generally not delete files unless you can
be sure that they can be deleted.  That is probably what the FHS
intended by specifying that files in /var/run must be deleted/truncated
at boot time, assuming that the programs that created them would do this
(and then create them anew if needed), which can be assumed to be
reasonably safe since it implies that unknown files remain.

For all I know, someones life could depend on a file that was placed
somewhere mistakenly.


-- 
"Didn't work" is an error.
___
CentOS mailing list
CentOS@centos.org

Re: [CentOS] how to prevent files and directories from being deleted?

[hw]

Harold Toms  writes:

> On 01/10/17 16:21, hw wrote:
>> Hi,
>>
>> how can I prevent files/directories like /var/run/mariadb from being
>> deleted on reboot?  Lighttpd has the same problem.
>>
>> This breaks services and makes servers non-restartable by anyone else
>> but the administrator who needs to re-create the needed files and
>> directories every time and has to figure out what selinux labels they
>> need.  This causes unnecessary downtimes.
>>
>> This is entirely inacceptable.  This totally sucks.
>>
>>
> Assuming that your /usr/lib/tmpfiles.d/mariadb.conf file contains:
>
> d /var/run/mariadb 0755 mysql mysql -

Thanks!  There is no such file.


Apparently we are not supposed to create such files, and now I must
compile mariadb from source because otherwise I wouldn´t be following
best practises an be out of my right mind ... ;)

Somehow, I doubt I would have a file like that if I did that.  I might
even get stuck in a compiling loop, following best practises
indefinitely ...

> the /var/run/mariadb should be recreated on every reboot... if it is
> not, perhaps either the mysql user or group do not exist. Check
> /etc/passwd and /etc/group.

They do exist.


The server isn´t in production yet, so I can create the file and see
what happens when rebooting it.  Let´s hope that it doesn´t vanish when
I do that ...


-- 
"Didn't work" is an error.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] New CentOS/RHEL group on Facebook

[Giles Coochey]

On 09/10/2017 13:59, Nux! wrote:

So, there is no switch there to make the group public?
It requires login now, that's what I was moaning about basically.
I think the point of it is that it is a Facebook group, i.e. It is a 
group for Facebook users who have an interest in CentOS/RHEL.


If it were to be an open-source group, then it would be over an 
open-source medium.




--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -

From: "Nicolas Kovacs" 
To: "CentOS mailing list" 
Sent: Monday, 9 October, 2017 13:26:57
Subject: Re: [CentOS] New CentOS/RHEL group on Facebook
Le 09/10/2017 à 13:14, Nux! a écrit :

I personally dislike Facebook, but even so, I think a basic
requirement for any web site striving to share knowledge is to be
publicly accessible to all which at the moment it is not. Search
engines won't be able to crawl it, people without an account won't be
able to access it.

Can this be changed?

Facebook is what it is, and as far as I'm concerned, I use the good bits
while ignoring the bad bits. It's OK for sharing links to new blog posts
and tutorials in tech groups, but that's pretty much it. For technical
questions, the mailing list and the forums are much more suited, and
this is also stated in the Facebook group's welcome message.

Consider it as "Twitter with unlimited characters".

Cheers,

Niki

--
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Web  : http://www.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

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



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

Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

[Nux!]

Ah, ok. I was wondering how you  managed to build that, because when I tried it 
did not work, but I see you have backported also other bits and bobs.
If those overwrite Base, perhaps add a warning of sorts.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Richard Grainger" 
> To: "CentOS mailing list" 
> Sent: Monday, 9 October, 2017 13:28:22
> Subject: Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

> Yes, I will look into getting the SRPMS up on the site (though they are
> just the ones from EPEL anyway).
> 
> On Mon, Oct 9, 2017 at 11:54 AM, Nux!  wrote:
> 
>> Hello,
>>
>> That's great, I know many people were looking for this.
>>
>> Any chance you can also publish the SRPMs?
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>> > From: "Richard Grainger" 
>> > To: "CentOS mailing list" 
>> > Sent: Sunday, 8 October, 2017 19:43:57
>> > Subject: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7
>>
>> > Hi all
>> >
>> > I've created a yum repo for 32 bit wine packages on RHEL and CentOS 7:
>> >
>> > https://harbottle.gitlab.io/wine32/7/i386/
>> >
>> > The Wine packages work on both 32 bit and 64 bit RHEL/CentOS 7. There is
>> no
>> > 32 bit version of the EPEL repo, where the standard RHEL/CentOS Wine
>> > packages can be found, so you may find this new repo useful if you need
>> to
>> > run Windows software that requires the 32 bit version of Wine.
>> >
>> > The packages are all built from the EPEL source RPMs.  I had to tweak the
>> > spec file for wine itself slightly, but for the dependencies it's all
>> pure
>> > rebuilds.
>> >
>> > Instructions:
>> >
>> > Code:
>> > yum -y install https://harbottle.gitlab.io/wine32/7/i386/wine32-release.
>> rpm
>> > yum -y install wine.i686
>> >
>> >
>> > Please give it a try and tell me what you think!  It probably needs more
>> > testing.
>> > ___
>> > CentOS mailing list
>> > CentOS@centos.org
>> > https://lists.centos.org/mailman/listinfo/centos
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] New CentOS/RHEL group on Facebook

[Nux!]

So, there is no switch there to make the group public? 
It requires login now, that's what I was moaning about basically.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Nicolas Kovacs" 
> To: "CentOS mailing list" 
> Sent: Monday, 9 October, 2017 13:26:57
> Subject: Re: [CentOS] New CentOS/RHEL group on Facebook

> Le 09/10/2017 à 13:14, Nux! a écrit :
>> I personally dislike Facebook, but even so, I think a basic
>> requirement for any web site striving to share knowledge is to be
>> publicly accessible to all which at the moment it is not. Search
>> engines won't be able to crawl it, people without an account won't be
>> able to access it.
>> 
>> Can this be changed?
> 
> Facebook is what it is, and as far as I'm concerned, I use the good bits
> while ignoring the bad bits. It's OK for sharing links to new blog posts
> and tutorials in tech groups, but that's pretty much it. For technical
> questions, the mailing list and the forums are much more suited, and
> this is also stated in the Facebook group's welcome message.
> 
> Consider it as "Twitter with unlimited characters".
> 
> Cheers,
> 
> Niki
> 
> --
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Web  : http://www.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

[Richard Grainger]

Yes, I will look into getting the SRPMS up on the site (though they are
just the ones from EPEL anyway).

On Mon, Oct 9, 2017 at 11:54 AM, Nux!  wrote:

> Hello,
>
> That's great, I know many people were looking for this.
>
> Any chance you can also publish the SRPMs?
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Richard Grainger" 
> > To: "CentOS mailing list" 
> > Sent: Sunday, 8 October, 2017 19:43:57
> > Subject: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7
>
> > Hi all
> >
> > I've created a yum repo for 32 bit wine packages on RHEL and CentOS 7:
> >
> > https://harbottle.gitlab.io/wine32/7/i386/
> >
> > The Wine packages work on both 32 bit and 64 bit RHEL/CentOS 7. There is
> no
> > 32 bit version of the EPEL repo, where the standard RHEL/CentOS Wine
> > packages can be found, so you may find this new repo useful if you need
> to
> > run Windows software that requires the 32 bit version of Wine.
> >
> > The packages are all built from the EPEL source RPMs.  I had to tweak the
> > spec file for wine itself slightly, but for the dependencies it's all
> pure
> > rebuilds.
> >
> > Instructions:
> >
> > Code:
> > yum -y install https://harbottle.gitlab.io/wine32/7/i386/wine32-release.
> rpm
> > yum -y install wine.i686
> >
> >
> > Please give it a try and tell me what you think!  It probably needs more
> > testing.
> > ___
> > CentOS mailing list
> > CentOS@centos.org
> > https://lists.centos.org/mailman/listinfo/centos
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] New CentOS/RHEL group on Facebook

[Nicolas Kovacs]

Le 09/10/2017 à 13:14, Nux! a écrit :
> I personally dislike Facebook, but even so, I think a basic
> requirement for any web site striving to share knowledge is to be
> publicly accessible to all which at the moment it is not. Search
> engines won't be able to crawl it, people without an account won't be
> able to access it.
> 
> Can this be changed?

Facebook is what it is, and as far as I'm concerned, I use the good bits
while ignoring the bad bits. It's OK for sharing links to new blog posts
and tutorials in tech groups, but that's pretty much it. For technical
questions, the mailing list and the forums are much more suited, and
this is also stated in the Facebook group's welcome message.

Consider it as "Twitter with unlimited characters".

Cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Web  : http://www.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] New CentOS/RHEL group on Facebook

[Richard]

I second this. I find it rather ironic that one would try to initiate
discussion of an open source operating system and environment in a
proprietary walled off world. This seems rather antithetical to the
whole intent of centos. 

  - Richard


 Original Message 
> Date: Monday, October 09, 2017 12:14:55 +0100
> From: Nux! 
>
> I personally dislike Facebook, but even so, I think a basic
> requirement for any web site striving to share knowledge is to be
> publicly accessible to all which at the moment it is not. Search
> engines won't be able to crawl it, people without an account won't
> be able to access it.
> 
> Can this be changed?
> 
> Thanks
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Nicolas Kovacs" 
>> To: "CentOS mailing list" 
>> Sent: Sunday, 8 October, 2017 15:48:29
>> Subject: [CentOS] New CentOS/RHEL group on Facebook
> 
>> Hi,
>> 
>> There are currently two competing CentOS groups on Facebook. The
>> "main" group is managed by a small group of autocrats with very
>> unilateral communication skills. The other one is not managed at
>> all, judged by the amount of non-CentOS-related stuff published
>> there (Ubuntu tutorials, Windows games, cheap Ray-Ban sunglasses).
>> 
>> I was a bit frustrated by this state of things, the more so since
>> I've successfully managed the Slackware Linux Facebook group for a
>> couple of years, regulating publications, keeping folks on topic
>> and banning the odd spammer.
>> 
>> So I decided to do the same thing I would do in a software
>> development context. Fork the project and create a different
>> CentOS/RHEL Facebook group. The goal of this group would simply be
>> to provide a no-nonsense discussion platform for all the CentOS
>> and Red Hat Enterprise Linux users out there. Publications would
>> be strictly CentOS/RHEL-centered, but on the other hand, you'd be
>> free to share your CentOS-related blog posts, tutorials and
>> documentation without getting flamed or banned by an admin.
>> 
>> Anyway, feel free to join the new group:
>> 
>> https://www.facebook.com/groups/2136021589748759/
>> 
>> Cheers from the sunny South of France,
>> 
>> Niki Kovacs
>> --
 End Original Message 


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

Re: [CentOS] New CentOS/RHEL group on Facebook

[Nux!]

I personally dislike Facebook, but even so, I think a basic requirement for any 
web site striving to share knowledge is to be publicly accessible to all which 
at the moment it is not.
Search engines won't be able to crawl it, people without an account won't be 
able to access it.

Can this be changed?

Thanks

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Nicolas Kovacs" 
> To: "CentOS mailing list" 
> Sent: Sunday, 8 October, 2017 15:48:29
> Subject: [CentOS] New CentOS/RHEL group on Facebook

> Hi,
> 
> There are currently two competing CentOS groups on Facebook. The "main"
> group is managed by a small group of autocrats with very unilateral
> communication skills. The other one is not managed at all, judged by the
> amount of non-CentOS-related stuff published there (Ubuntu tutorials,
> Windows games, cheap Ray-Ban sunglasses).
> 
> I was a bit frustrated by this state of things, the more so since I've
> successfully managed the Slackware Linux Facebook group for a couple of
> years, regulating publications, keeping folks on topic and banning the
> odd spammer.
> 
> So I decided to do the same thing I would do in a software development
> context. Fork the project and create a different CentOS/RHEL Facebook
> group. The goal of this group would simply be to provide a no-nonsense
> discussion platform for all the CentOS and Red Hat Enterprise Linux
> users out there. Publications would be strictly CentOS/RHEL-centered,
> but on the other hand, you'd be free to share your CentOS-related blog
> posts, tutorials and documentation without getting flamed or banned by
> an admin.
> 
> Anyway, feel free to join the new group:
> 
> https://www.facebook.com/groups/2136021589748759/
> 
> Cheers from the sunny South of France,
> 
> Niki Kovacs
> --
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Web  : http://www.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

[Nux!]

Hello,

That's great, I know many people were looking for this.

Any chance you can also publish the SRPMs?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Richard Grainger" 
> To: "CentOS mailing list" 
> Sent: Sunday, 8 October, 2017 19:43:57
> Subject: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

> Hi all
> 
> I've created a yum repo for 32 bit wine packages on RHEL and CentOS 7:
> 
> https://harbottle.gitlab.io/wine32/7/i386/
> 
> The Wine packages work on both 32 bit and 64 bit RHEL/CentOS 7. There is no
> 32 bit version of the EPEL repo, where the standard RHEL/CentOS Wine
> packages can be found, so you may find this new repo useful if you need to
> run Windows software that requires the 32 bit version of Wine.
> 
> The packages are all built from the EPEL source RPMs.  I had to tweak the
> spec file for wine itself slightly, but for the dependencies it's all pure
> rebuilds.
> 
> Instructions:
> 
> Code:
> yum -y install https://harbottle.gitlab.io/wine32/7/i386/wine32-release.rpm
> yum -y install wine.i686
> 
> 
> Please give it a try and tell me what you think!  It probably needs more
> testing.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] SCSI block device name/multipath question

[Matthias Leopold]

hi,

i have a host with a LSI SAS 3108 RAID controller in JBOD mode with 4 
SSD SATA disks. i installed oVirt node (= CentOS 7) on the first two 
disks configured as SW RAID 1 (in the oVirt node/CentOS installer). when 
i look at the device names in the running OS i get


# lsscsi --scsi_id -g
[0:0:0:0]diskATA  SAMSUNG MZ7LM480 204Q  /dev/sda   -  /dev/sg0
[0:0:1:0]diskATA  SAMSUNG MZ7LM480 204Q  /dev/sdb   -  /dev/sg1
[0:0:2:0]diskATA  SAMSUNG MZ7LM480 204Q  /dev/sdc 
SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102216  /dev/sg2
[0:0:3:0]diskATA  SAMSUNG MZ7LM480 204Q  /dev/sdd 
SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102214  /dev/sg3


# ls -l /dev/disk/by-id/*SAMSUNG*
lrwxrwxrwx. 1 root root  9  9. Okt 12:07 
/dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102212 -> ../../sdb
lrwxrwxrwx. 1 root root 10  9. Okt 12:07 
/dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102212-part1 -> 
../../sdb1
lrwxrwxrwx. 1 root root 10  9. Okt 12:07 
/dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102212-part2 -> 
../../sdb2
lrwxrwxrwx. 1 root root  9  9. Okt 12:07 
/dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102214 -> ../../sdd
lrwxrwxrwx. 1 root root  9  9. Okt 12:07 
/dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102216 -> ../../sdc
lrwxrwxrwx. 1 root root  9  9. Okt 12:07 
/dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J10 -> ../../sda
lrwxrwxrwx. 1 root root 10  9. Okt 12:07 
/dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J10-part1 -> 
../../sda1
lrwxrwxrwx. 1 root root 10  9. Okt 12:07 
/dev/disk/by-id/ata-SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J10-part2 -> 
../../sda2
lrwxrwxrwx. 1 root root 10  9. Okt 12:07 
/dev/disk/by-id/dm-name-SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102214 -> 
../../dm-6
lrwxrwxrwx. 1 root root 10  9. Okt 12:07 
/dev/disk/by-id/dm-name-SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102216 -> 
../../dm-5
lrwxrwxrwx. 1 root root 10  9. Okt 12:07 
/dev/disk/by-id/dm-uuid-mpath-SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102214 
-> ../../dm-6
lrwxrwxrwx. 1 root root 10  9. Okt 12:07 
/dev/disk/by-id/dm-uuid-mpath-SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102216 
-> ../../dm-5


disks 2:0 + 3:0 are configured as multipath devices (and subsequently 
set up by device mapper), disks 0:0 + 1:0 are not. 
SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102216 and 
SAMSUNG_MZ7LM480HMHQ-5_S2UJNX0J102214 are listed in 
/etc/multipath/wwids (and get re-listed after reboot when i manually 
remove them).


why are two of the four local disks configured as multipath devices? As 
far as i understood documentation this shouldn't happen


thx 4 help
matthias

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

Re: [CentOS] Announcement: 32 bit Wine repo for RHEL and CentOS 7

[Richard Grainger]

Yes, works fine alongside 64 bit wine from EPEL. :)

Sent from my iPhone

> On 9 Oct 2017, at 02:03, Peter  wrote:
> 
> This is great, thank you very much!
> 
> Did you make it parallel-installable to the 64 bit wine from epel?
> 
> 
> Peter
> 
> 
>> On 09/10/17 07:43, Richard Grainger wrote:
>> Hi all
>> 
>> I've created a yum repo for 32 bit wine packages on RHEL and CentOS 7:
>> 
>> https://harbottle.gitlab.io/wine32/7/i386/
>> 
>> The Wine packages work on both 32 bit and 64 bit RHEL/CentOS 7. There is no
>> 32 bit version of the EPEL repo, where the standard RHEL/CentOS Wine
>> packages can be found, so you may find this new repo useful if you need to
>> run Windows software that requires the 32 bit version of Wine.
>> 
>> The packages are all built from the EPEL source RPMs.  I had to tweak the
>> spec file for wine itself slightly, but for the dependencies it's all pure
>> rebuilds.
>> 
>> Instructions:
>> 
>> Code:
>> yum -y install https://harbottle.gitlab.io/wine32/7/i386/wine32-release.rpm
>> yum -y install wine.i686
>> 
>> 
>> Please give it a try and tell me what you think!  It probably needs more
>> testing.
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>> 
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos