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 mac
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@cen
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@c
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
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.servic
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 pa
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 tmpfile
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) wil
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
>
> 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
> (an
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
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 t
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
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:
>
>>
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!
>
> Nu
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
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.
>
> -
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, p
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
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 sel
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
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/
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#VARRUNRUNTIMEVARIABLE
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 crea
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
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 issu
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 kee
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 u
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
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 wer
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 Me
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 O
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 q
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 w
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: Mon
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 cha
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
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:
39 matches
Mail list logo
