On 05/26/2010 08:23 PM, Gordon Messmer wrote:
On 05/26/2010 08:44 AM, Benjamin Franz wrote:
[...]
The *theoretical* system security improvement of SELinux is trumped by
the *practical* observation that I have had existing systems broken by
SELinux multiple times on the mere handful of
On Thu, 2010-05-27 at 05:55 -0700, Jerry Franz wrote:
On 05/26/2010 08:23 PM, Gordon Messmer wrote:
On 05/26/2010 08:44 AM, Benjamin Franz wrote:
[...]
The *theoretical* system security improvement of SELinux is trumped by
the *practical* observation that I have had existing systems
On 05/27/2010 05:55 AM, Jerry Franz wrote:
I have *twenty* virtual machines I deploy updates to before it ever
touches my production systems. Not everything is testable on
non-production machines.
...
Now back to fixing the SELinux configuration on a machine I had to put
in 'permissive' mode
On 05/27/2010 08:51 AM, Gordon Messmer wrote:
On 05/27/2010 05:55 AM, Jerry Franz wrote:
I have *twenty* virtual machines I deploy updates to before it ever
touches my production systems. Not everything is testable on
non-production machines.
...
Now back to fixing the
On Tue, 2010-05-25 at 17:24 -0500, Les Mikesell wrote:
On 5/25/2010 5:09 PM, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 06:05:34PM -0400, Whit Blauvelt wrote:
where smb is RH's version and /etc/init.d/smb is Cent's. I can't quite
imagine that a difference between overwriting or
On May 26, 2010, at 1:44 AM, Les Mikesell lesmikes...@gmail.com wrote:
Gordon Messmer wrote:
No. With that file removed, smbd probably wouldn't have been able to
write to the directory. If it was able to, it probably would have
run
into trouble with the next file. If smbd started up in
On Tue, 2010-05-25 at 21:27 -0400, Whit Blauvelt wrote:
But if someone can tell me why selinux thinks it's sane to block
/etc/init.d/smb start while leaving sh /etc/init.d/smb start and even
/some/random/dir/smb start wide open ... I just can't believe some happy
hacker at NSA thought that
JohnS wrote:
On Tue, 2010-05-25 at 21:27 -0400, Whit Blauvelt wrote:
But if someone can tell me why selinux thinks it's sane to block
/etc/init.d/smb start while leaving sh /etc/init.d/smb start and even
/some/random/dir/smb start wide open ... I just can't believe some happy
hacker at NSA
On Tue, 2010-05-25 at 23:36 -0400, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 09:09:33PM -0500, Jay Leafey wrote:
In your case, there should have been AVC errors showing up in the
audit log related to smbd. Using restorecon to fix up the security
context on the files in /etc/samba
you can't make a useful argument out of ignorance.
You are being religious, and wrong. See below.
If you don't want to use SELinux, then disable it.
This is a good idea. Disabling SELinux is the first thing that should
be done, since (as this conversation proves plainly) what we don't
On 05/26/2010 07:40 AM, Craig White wrote:
you can't make a useful argument out of ignorance. If you don't want to
use SELinux, then disable it. Otherwise, learn to understand how it
operates and deal with it.
one certain way to cause issues with SELinux is to copy files created in
other
Benjamin wrote:
On 05/26/2010 07:40 AM, Craig White wrote:
you can't make a useful argument out of ignorance. If you don't want to
use SELinux, then disable it. Otherwise, learn to understand how it
operates and deal with it.
one certain way to cause issues with SELinux is to copy files
The *theoretical* system security improvement of SELinux is trumped by
the *practical* observation that I have had existing systems broken by
SELinux multiple times on the mere handful of systems I have run it on
in enforcing mode, but have yet to see a single one of several dozen
(all
On 05/25/2010 10:44 PM, Les Mikesell wrote:
That still doesn't explain why there is a difference in smbd's context when
its
parent is an explicitly started shell vs. the implict one that starts when the
script file is executed.
SELinux domain transitions are handled by the kernel. If you
On 05/26/2010 07:54 AM, Brunner, Brian T. wrote:
you can't make a useful argument out of ignorance.
You are being religious, and wrong. See below.
You also can't make a useful argument out of name-calling.
People frequently use the label religious derisively when someone
advocates a
On 5/26/2010 5:16 PM, Gordon Messmer wrote:
Isn't the context associated with the program itself,
not its parent?
The context is inherited from the process which calls exec() if there is
no transition defined. If there is a transition, it is associated with
the path.
Is this documented
On 05/26/2010 08:44 AM, Benjamin Franz wrote:
I can make a useful argument from experience. Over the last few years,
as Redhat has progressively deployed SELinux, I have had *several*
incidents (the most recent only a few weeks ago) where updates to
SELinux broke existing, stable, systems.
Just a follow up note: We've got the same problem again on another fresh
install. Totally different hardware - so the hardware hypothesis bites the
dust. Since other people aren't seeing this, the remaining suspect is our
configuration files. We're using an smbpasswd backed, and in both these
Finally, a clue!
Upgraded from the stock smbd version from the 5.4 iso to 3.0.33-3.28.el5,
and now an error message makes it into /var/log/messages:
May 24 15:29:12 xyz smbd[2674]: [2010/05/24 15:29:12, 0]
lib/messages.c:message_init(132)
May 24 15:29:12 xyz smbd[2674]: ERROR: Failed to
Following up, that appears to be /var/cache/samba/messages.tdb it can't
intialize. Which sits there with the same permissions on the not-working
CentOS 5.4 systems as on the working Redhat 5.4 systems. Now what could
create a problem for that when started from /etc/init.d/smb start but not
from sh
At Tue, 25 May 2010 15:11:45 -0400 CentOS mailing list centos@centos.org
wrote:
Just a follow up note: We've got the same problem again on another fresh
install. Totally different hardware - so the hardware hypothesis bites the
dust. Since other people aren't seeing this, the remaining
At Tue, 25 May 2010 17:26:26 -0400 CentOS mailing list centos@centos.org
wrote:
Following up, that appears to be /var/cache/samba/messages.tdb it can't
intialize. Which sits there with the same permissions on the not-working
CentOS 5.4 systems as on the working Redhat 5.4 systems. Now what
On Tue, May 25, 2010 at 05:38:59PM -0400, Robert Heller wrote:
Wondering aloud: where the smbpasswd *data* files copied? If so how,
exactly? And from what version of samba were the smbpasswd *data*
created with? And are the permissions of the smbpasswd *data* what they
should be? Just
On Tue, May 25, 2010 at 05:47:00PM -0400, Robert Heller wrote:
Was this file *copied* from the Redhat 5.4 system(s) or created fresh
under CentOS?
If you mean /etc/init.d/smb, it's CentOS's version. The entire difference
between the two, just for the record, is:
# diff smb /etc/init.d/smb
On Tue, May 25, 2010 at 06:05:34PM -0400, Whit Blauvelt wrote:
where smb is RH's version and /etc/init.d/smb is Cent's. I can't quite
imagine that a difference between overwriting or appending path.txt is at
the root of what I'm seeing though.
Correction: that wasn't a virgin version of
On Tue, May 25, 2010 at 06:09:40PM -0400, Whit Blauvelt wrote:
Correction: that wasn't a virgin version of Cent's. More in a moment.
This gets more bizarre. To a virgin version of Cent's /etc/init.d/smb - it's
a perfect match:
# diff ./smb /etc/init.d/smb
#
That's right, no diff!
Yet if I
Whit Blauvelt wrote, On 05/25/2010 06:05 PM:
On Tue, May 25, 2010 at 05:47:00PM -0400, Robert Heller wrote:
Was this file *copied* from the Redhat 5.4 system(s) or created fresh
under CentOS?
If you mean /etc/init.d/smb, it's CentOS's version. The entire difference
between the two, just
On Wed, May 26, 2010 at 12:17 AM, Whit Blauvelt w...@transpect.com wrote:
On Tue, May 25, 2010 at 06:09:40PM -0400, Whit Blauvelt wrote:
Correction: that wasn't a virgin version of Cent's. More in a moment.
This gets more bizarre. To a virgin version of Cent's /etc/init.d/smb -
it's
a
On 5/25/2010 5:09 PM, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 06:05:34PM -0400, Whit Blauvelt wrote:
where smb is RH's version and /etc/init.d/smb is Cent's. I can't quite
imagine that a difference between overwriting or appending path.txt is at
the root of what I'm seeing though.
] On Behalf Of Whit Blauvelt
Sent: Tuesday, May 25, 2010 6:18 PM
To: CentOS mailing list
Subject: Re: [CentOS] Odd failure of smbd to start from
init.d - CentOS 5.4
On Tue, May 25, 2010 at 06:09:40PM -0400, Whit Blauvelt wrote:
Correction: that wasn't a virgin version of Cent's. More
Hi Brian,
I've been all over the environment comparisons before, I think. The question
currently is:
What can be the difference between
/home/smb restart - which works, and
/etc/init.d/smb restart - which fails
when a diff between the two smb files shows no difference?
This is with both of
On 05/25/2010 04:11 PM, Whit Blauvelt wrote:
Hi Brian,
I've been all over the environment comparisons before, I think. The question
currently is:
What can be the difference between
/home/smb restart - which works, and
/etc/init.d/smb restart - which fails
when a diff between the two smb
Les,
At risk of clogging mail boxes, see below, and note this line in the middle:
open(/var/cache/samba/messages.tdb, O_RDWR|O_CREAT, 0600) = -1 EACCES
(Permission denied)
Now, if I copy that modified smb file elsewhere and run it, for one
difference output stops without returning to prompt
On Tue, May 25, 2010 at 06:23:02PM -0400, Todd Denniston wrote:
I have not been following this thread closely, but perhaps Robert was
pointing at SELINUX and the
need to keep the SE permissions intact as you copy/edit the file.
i.e. you may need to:
A) restorecon /etc/init.d/smb and any
On Tue, May 25, 2010 at 04:33:53PM -0700, Jerry Franz wrote:
Are you running with SELinux on?
Now there's a good question, it turns out. I'd assumed CentOS followed the
pattern of most distros in having it not be in strictest mode
out-of-the-box, but in /etc/selinux/config:
SELINUX=enforcing
At Tue, 25 May 2010 18:05:34 -0400 CentOS mailing list centos@centos.org
wrote:
On Tue, May 25, 2010 at 05:47:00PM -0400, Robert Heller wrote:
Was this file *copied* from the Redhat 5.4 system(s) or created fresh
under CentOS?
If you mean /etc/init.d/smb, it's CentOS's version. The
On Tue, May 25, 2010 at 07:55:12PM -0400, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 04:33:53PM -0700, Jerry Franz wrote:
Are you running with SELinux on?
You were right Jerry!
echo 0 /selinux/enforce
and then /etc/init.d/smb restart works! Thank you much Jerry!
Now why doesn't that
Whit Blauvelt wrote:
On Tue, May 25, 2010 at 07:55:12PM -0400, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 04:33:53PM -0700, Jerry Franz wrote:
Are you running with SELinux on?
You were right Jerry!
echo 0 /selinux/enforce
and then /etc/init.d/smb restart works! Thank you much
On May 25, 2010, at 8:25 PM, Whit Blauvelt w...@transpect.com wrote:
On Tue, May 25, 2010 at 07:55:12PM -0400, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 04:33:53PM -0700, Jerry Franz wrote:
Are you running with SELinux on?
You were right Jerry!
echo 0 /selinux/enforce
and then
On Tue, May 25, 2010 at 07:46:56PM -0500, Les Mikesell wrote:
I would have looked at selinux first for any odd failure, but I thought it
related to the process itself and couldn't see any way that the process would
be
different when started as sh /etc/init.d/smb restart than simply
On Tue, May 25, 2010 at 08:52:58PM -0400, Ross Walker wrote:
Selinux alerts are in /var/log/audit/audit.log
Thank you for that. Cryptic, but there it is.
The problem is if smbd doesn't create the messages.tdb file then it
won't have the selinux rights.
I don't follow you. What else could
-Original Message-
From: centos-boun...@centos.org
[mailto:centos-boun...@centos.org] On Behalf Of Whit Blauvelt
Sent: Tuesday, May 25, 2010 21:27
To: CentOS mailing list
Subject: Re: [CentOS] Odd failure of smbd to start from
init.d - CentOS 5.4 - it's that fine SELinux
Whit Blauvelt wrote:
SNIP
Then why was it also happy with sh /etc/init.d/smb start but not
/etc/init.d/smb start. I'm happy to become more educated on this. But if
invoking a major daemon startup that selinux wants to block is as easy as
that, selinux is window dressing, not security.
What am
On May 25, 2010, at 9:44 PM, Whit Blauvelt w...@transpect.com wrote:
On Tue, May 25, 2010 at 08:52:58PM -0400, Ross Walker wrote:
Selinux alerts are in /var/log/audit/audit.log
Thank you for that. Cryptic, but there it is.
The problem is if smbd doesn't create the messages.tdb file then it
On Tue, May 25, 2010 at 10:03:38PM -0400, Jason Pyeron wrote:
If you look at it as the two different commands, then they may have different
permissions, owners, contexts, etc...
/bin/sh vs /etc/init.d/smb
I am just logically guessing here but ...
Let me follow your logic here. So the
Whit Blauvelt wrote, On 05/25/2010 11:09 PM:
On Tue, May 25, 2010 at 10:03:38PM -0400, Jason Pyeron wrote:
If you look at it as the two different commands, then they may have different
permissions, owners, contexts, etc...
/bin/sh vs /etc/init.d/smb
I am just logically guessing here but
On Tue, May 25, 2010 at 09:09:33PM -0500, Jay Leafey wrote:
In your case, there should have been AVC errors showing up in the
audit log related to smbd. Using restorecon to fix up the security
context on the files in /etc/samba might have resolved the issue
quickly... but I guess the trick
On 05/25/2010 04:39 PM, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 06:23:02PM -0400, Todd Denniston wrote:
i.e. you may need to:
A) restorecon /etc/init.d/smb and any other samba files that you have
copied/edited.
It doesn't work with the smb file which is virgin, as installed by CentOS.
On 05/25/2010 06:44 PM, Whit Blauvelt wrote:
And that still doesn't say why it starts having a problem with
/var/cache/samba/messages.tbd. Does it?
That's simply the first file which was denied by policy. If that one
had been removed, the next one would have caused problems.
That file can
On 05/25/2010 08:36 PM, Whit Blauvelt wrote:
Thoughtful advice. Thanks. Is there some method to duplicate basic
configuration files across selinux servers without running restorecon for
each set of files that's copied over - that is, to copy them with their
selinux labels intact?
Usually if
On 05/25/2010 08:09 PM, Whit Blauvelt wrote:
So with selinux, in general any script that selinux would stop from running
due to the script's own extra selinux file tags can be run if Evil Intruder
simply invokes the same script with its shell first - sh or perl or python
or whatever? That
Gordon Messmer wrote:
No. With that file removed, smbd probably wouldn't have been able to
write to the directory. If it was able to, it probably would have run
into trouble with the next file. If smbd started up in the context
which was configured for it, everything would work
From: Whit Blauvelt w...@transpect.com
service smb restart - does NOT get smbd running (although
shows OK)
sh /etc/init.d/smb restart - DOES get smbd running
/etc/init.d/smb restart - does NOT get smbd running (although shows
OK)
bash /etc/init.d/smb restart - DOES get smbd running
What's
On Thu, May 20, 2010 at 9:30 PM, Whit Blauvelt w...@transpect.com wrote:
On Thu, May 20, 2010 at 06:17:10PM -0700, Benjamin Franz wrote:
Have you looked in /var/log/messages for errors from smbd? I don't
remember seeing that anywhere in your T/S list.
Yup. I've grepped all the logs. Nothing
On May 20, 2010, at 9:21 AM, Whit Blauvelt w...@transpect.com wrote:
Hi,
We've got a fresh CentOS 5.4 box, and the only glitch so far is that
/etc/init.d/smb doesn't start smbd. It claims it does - shows [ok]
- but
only nmbd ends up running. Even setting a higher debugging level in
the
On Fri, May 21, 2010 at 10:04:36AM -0400, Ross Walker wrote:
By any chance did someone add smbd to xinetd?
If so then xinetd has the port open and the smbd process will not bind.
Nope. Not sure that would explain why a slight difference in how it's
invoked, through the same init.d script,
On 5/21/2010 9:44 AM, Whit Blauvelt wrote:
On Fri, May 21, 2010 at 10:04:36AM -0400, Ross Walker wrote:
By any chance did someone add smbd to xinetd?
If so then xinetd has the port open and the smbd process will not bind.
Nope. Not sure that would explain why a slight difference in how it's
On May 21, 2010, at 10:44 AM, Whit Blauvelt w...@transpect.com wrote:
On Fri, May 21, 2010 at 10:04:36AM -0400, Ross Walker wrote:
By any chance did someone add smbd to xinetd?
If so then xinetd has the port open and the smbd process will not
bind.
Nope. Not sure that would explain why
On May 21, 2010, at 11:24 AM, Les Mikesell lesmikes...@gmail.com
wrote:
On 5/21/2010 9:44 AM, Whit Blauvelt wrote:
On Fri, May 21, 2010 at 10:04:36AM -0400, Ross Walker wrote:
By any chance did someone add smbd to xinetd?
If so then xinetd has the port open and the smbd process will not
On Fri, May 21, 2010 at 10:24:00AM -0500, Les Mikesell wrote:
The only difference here 'should' be that explicitly running 'sh' will
invoke your own shell aliases and search PATH to execute sh, where if
you omit it you'll get the #!/bin/sh interpreter specified in the script
itself. Is
On 5/21/2010 10:56 AM, Whit Blauvelt wrote:
On Fri, May 21, 2010 at 10:24:00AM -0500, Les Mikesell wrote:
The only difference here 'should' be that explicitly running 'sh' will
invoke your own shell aliases and search PATH to execute sh, where if
you omit it you'll get the #!/bin/sh
On 5/21/2010 10:56 AM, Whit Blauvelt wrote:
On Fri, May 21, 2010 at 10:24:00AM -0500, Les Mikesell wrote:
The only difference here 'should' be that explicitly running 'sh' will
invoke your own shell aliases and search PATH to execute sh, where if
you omit it you'll get the #!/bin/sh
On Fri, May 21, 2010 at 11:54:26AM -0400, Ross Walker wrote:
# sh -x script start
The problem with debugging it like that is that when started with sh,
there's no bug.
Whit
___
CentOS mailing list
CentOS@centos.org
On Fri, May 21, 2010 at 12:52:51PM -0400, m.r...@5-cent.us wrote:
A suggestion: in the script, add
env /tmp/smb.env
or whatever you want to call it. Then you can compare and contrast with
your environment.
Good idea. I'll try it when the system's back up. Someone's hunting up a
On Fri, 2010-05-21 at 13:00 -0400, Whit Blauvelt wrote:
On Fri, May 21, 2010 at 11:54:26AM -0400, Ross Walker wrote:
# sh -x script start
The problem with debugging it like that is that when started with sh,
there's no bug.
how about adding a set -x as the first line after the
On Fri, May 21, 2010 at 03:39:53AM -0700, John Doe wrote:
What's the return value?
service smb start
echo $?
# service smb start
Starting SMB services: [ OK ]
Starting NMB services:
# echo $?
0
# ps aux | grep mbd
root 2520 0.0 0.0 107732
On Thu, May 20, 2010 at 08:52:31PM -0500, Les Mikesell wrote:
What shell does the script specify at the top and what is found following
$PATH?
Here's from the console:
# echo $PATH
On Fri, May 21, 2010 at 07:49:16AM -0400, Kwan Lowe wrote:
My gut tells me it's not hardware but willing to take it :)
Have you tried adding a set -x to the top of the the smb startup
scripts? I didn't see any such output in your replies so far.
Here you go:
# ./smb start
+ '[' -f
On Fri, May 21, 2010 at 02:36:30PM -0400, Whit Blauvelt wrote:
Here's the path seen within the init.d/smb script (from an inserted echo
$PATH file):
/sbin:/usr/sbin:/bin:/usr/bin
And if I set that path in a console session, smbd still works when called
directly:
# export
On May 21, 2010, at 2:47 PM, Whit Blauvelt w...@transpect.com wrote:
+ /bin/bash -c 'ulimit -S -c 0 /dev/null 21 ; smbd -D'
What happens when you manually try to execute the above commands?
-Ross
___
CentOS mailing list
CentOS@centos.org
On Fri, May 21, 2010 at 03:12:02PM -0400, Ross Walker wrote:
What happens when you manually try to execute the above commands?
# /bin/bash -c 'ulimit -S -c 0 /dev/null 21 ; smbd -D'
Not sure what that might in theory do, but it works:
# ps aux | grep mbd | grep -v grep
root 7870 0.0
On Fri, 2010-05-21 at 15:01 -0400, Whit Blauvelt wrote:
On Fri, May 21, 2010 at 02:36:30PM -0400, Whit Blauvelt wrote:
Here's the path seen within the init.d/smb script (from an inserted echo
$PATH file):
/sbin:/usr/sbin:/bin:/usr/bin
And if I set that path in a console session,
On Thu, May 20, 2010 at 10:29 PM, Jason Pyeron jpye...@pdinc.us wrote:
From: Tom H
Sent: Thursday, May 20, 2010 22:22
# rpm -V samba
S.5T c /etc/rc.d/init.d/smb
S.5T c /etc/samba/smbusers
...T c /etc/sysconfig/samba
I'm not sure but I really think you have the wrong
On May 21, 2010, at 3:48 PM, Whit Blauvelt w...@transpect.com wrote:
On Fri, May 21, 2010 at 03:12:02PM -0400, Ross Walker wrote:
What happens when you manually try to execute the above commands?
# /bin/bash -c 'ulimit -S -c 0 /dev/null 21 ; smbd -D'
Not sure what that might in theory do,
On 5/21/2010 4:37 PM, Ross Walker wrote:
On May 21, 2010, at 3:48 PM, Whit Blauveltw...@transpect.com wrote:
On Fri, May 21, 2010 at 03:12:02PM -0400, Ross Walker wrote:
What happens when you manually try to execute the above commands?
# /bin/bash -c 'ulimit -S -c 0/dev/null 21 ; smbd -D'
Hi,
We've got a fresh CentOS 5.4 box, and the only glitch so far is that
/etc/init.d/smb doesn't start smbd. It claims it does - shows [ok] - but
only nmbd ends up running. Even setting a higher debugging level in the smbd
flags, nothing logs or shows on the console as to why smbd is immediatly
On 5/20/2010 9:21 AM, Whit Blauvelt wrote:
Hi,
We've got a fresh CentOS 5.4 box, and the only glitch so far is that
/etc/init.d/smb doesn't start smbd. It claims it does - shows [ok] - but
only nmbd ends up running. Even setting a higher debugging level in the smbd
flags, nothing logs or
On 5/20/2010 8:21 AM, Whit Blauvelt wrote:
Hi,
We've got a fresh CentOS 5.4 box, and the only glitch so far is that
/etc/init.d/smb doesn't start smbd. It claims it does - shows [ok] - but
only nmbd ends up running. Even setting a higher debugging level in the smbd
flags, nothing logs or
On Thu, May 20, 2010 at 10:21:51AM -0400, Ryan Manikowski wrote:
Have you run 'testparm' to verify the samba configuration does not
contain any errors that are preventing the smbd daemon from loading?
I had not. Doesn't seem to tell us anything:
# testparm
Load smb config files from
Whit Blauvelt writes:
On Thu, May 20, 2010 at 10:21:51AM -0400, Ryan Manikowski wrote:
Have you run 'testparm' to verify the samba configuration does not
contain any errors that are preventing the smbd daemon from loading?
I had not. Doesn't seem to tell us anything:
Increase the
Does 'service smb restart' work after the rest of the system is up
enough to log in? If so, maybe some of the underlying network services
aren't ready when it starts at bootup.
/etc/init.d/smb restart does not restart it. Shows an error on smb shutdown
(of course, since it's not running),
Increase the debug level for smbd by adding -d N (N = 0 ... 10) to
SMBDOPTIONS in /etc/sysconfig/samba, restart smbd.
That was the first thing I tried. Nothing got logged or reported to console
- at all. The nmbd logs showed up as requested, but for smbd, nada.
Thanks for the suggestion,
On 5/20/2010 10:45 AM, Whit Blauvelt wrote:
On Thu, May 20, 2010 at 10:21:51AM -0400, Ryan Manikowski wrote:
Have you run 'testparm' to verify the samba configuration does not
contain any errors that are preventing the smbd daemon from loading?
I had not. Doesn't seem to tell us
On Thu, May 20, 2010 at 10:58:07AM -0400, Ryan Manikowski wrote:
As your config appears to be clean and free of errors that would prevent
smbd from starting have you...
...tried starting smbd from the command line NOT using the init scripts?
Make sure nmbd is started first: nmbd -D
Try
On 5/20/2010 9:53 AM, Whit Blauvelt wrote:
Does 'service smb restart' work after the rest of the system is up
enough to log in? If so, maybe some of the underlying network services
aren't ready when it starts at bootup.
/etc/init.d/smb restart does not restart it. Shows an error on smb
On Thu, May 20, 2010 at 11:41:22AM -0400, Whit Blauvelt wrote:
. /etc/init.d/functions
daemon smbd -D
It also seems perfectly happy with just smbd -D to start it, after system
startup.
But the two lines above do not work when from /etc/rc.local. Haven't tried
the simpler invocation there
On Thu, May 20, 2010 at 10:58:07AM -0400, Ryan Manikowski wrote:
Make sure nmbd is started first: nmbd -D
You know, that's not the order the init.d/smb file has it in:
start() {
KIND=SMB
echo -n $Starting $KIND services:
daemon smbd $SMBDOPTIONS
RETVAL=$?
On Thu, May 20, 2010 at 01:39:28PM -0400, Whit Blauvelt wrote:
You know, that's not the order the init.d/smb file has it in:
... except that file matches the order of the stock Redhat file, which is
working fine for us on several other systems.
This is just strange.
Whit
On 5/20/2010 12:39 PM, Whit Blauvelt wrote:
On Thu, May 20, 2010 at 10:58:07AM -0400, Ryan Manikowski wrote:
Make sure nmbd is started first: nmbd -D
You know, that's not the order the init.d/smb file has it in:
start() {
KIND=SMB
echo -n $Starting $KIND services:
On Thu, May 20, 2010 at 12:47:50PM -0500, Les Mikesell wrote:
That looks like the stock init file - but it might be a good idea to run
'rpm -V samba' to see if everything is standard. Running the init
script with 'sh -x' might give you a hint about what it is doing - or
you'll have to
More data:
service smb restart - does NOT get smbd running (although shows OK)
sh /etc/init.d/smb restart - DOES get smbd running
The service man page claims the only environment variables it passes are
LANG and TERM. But that can't be the key, since
/etc/init.d/smb restart - does NOT get
On Thu, 2010-05-20 at 17:41 -0400, Whit Blauvelt wrote:
More data:
service smb restart - does NOT get smbd running (although shows OK)
sh /etc/init.d/smb restart - DOES get smbd running
The service man page claims the only environment variables it passes are
LANG and TERM. But that
Maybe try rpm -V samba to verify all the samba files. You get any
output then you have problems.
I take it this output:
# rpm -V samba
S.5T c /etc/rc.d/init.d/smb
S.5T c /etc/samba/smbusers
...T c /etc/sysconfig/samba
merely shows that these are files that don't precisely
On Thu, May 20, 2010 at 5:41 PM, Whit Blauvelt w...@transpect.com wrote:
More data:
service smb restart - does NOT get smbd running (although shows OK)
sh /etc/init.d/smb restart - DOES get smbd running
The service man page claims the only environment variables it passes are
LANG and TERM.
On Thu, 2010-05-20 at 18:39 -0400, Whit Blauvelt wrote:
Maybe try rpm -V samba to verify all the samba files. You get any
output then you have problems.
I take it this output:
# rpm -V samba
S.5T c /etc/rc.d/init.d/smb
S.5T c /etc/samba/smbusers
...T c
On Thu, May 20, 2010 at 03:50:20PM -0700, Craig White wrote:
not until you run the command as suggested much earlier...
/usr/sbin/smbd -iF
which will launch it iteractively and output everything to standard out
- the console itself and then let us know what it says.
Hi Craig,
On Thu, 2010-05-20 at 19:35 -0400, Whit Blauvelt wrote:
On Thu, May 20, 2010 at 03:50:20PM -0700, Craig White wrote:
not until you run the command as suggested much earlier...
/usr/sbin/smbd -iF
which will launch it iteractively and output everything to standard out
- the console
On Thu, 2010-05-20 at 16:40 -0700, Craig White wrote:
On Thu, 2010-05-20 at 19:35 -0400, Whit Blauvelt wrote:
On Thu, May 20, 2010 at 03:50:20PM -0700, Craig White wrote:
not until you run the command as suggested much earlier...
/usr/sbin/smbd -iF
which will launch it
On Thu, May 20, 2010 at 06:49:33PM -0400, Kwan Lowe wrote:
The service scripts can check for lock files. Do you have any stale
locks in /var/run/subsys?
Thanks Kwan.
If I remove /var/run/smbd.pid (and /var/run/nmbd.pid for that matter), the
init.d/smb file still fails to get smbd running
On 05/20/2010 04:46 PM, Whit Blauvelt wrote:
Also, since sh /etc/init.d/smb (re)start works but /etc/init.d/smb
(re)start doesn't, I can't see how the difference between those two
invocations would change the handling of the lock files. It's still the same
script being run. Just some change
1 - 100 of 113 matches
Mail list logo
