Bug 183100 - authconfig reports "critical error"s that aren't, and can't be stopped
Summary: authconfig reports "critical error"s that aren't, and can't be stopped
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: authconfig
Version: 4.0
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-02-26 08:25 UTC by Rubio
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-27 08:44:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Rubio 2006-02-26 08:25:43 UTC
Description of problem:

authconfig inappropriately calls procedures to write various configuration
files, which at least in the case of systems with no Samba installed results in
the error:

authconfig: critical error writing /etc//samba/smb.conf: No such file or directory

A quick perusal of the manpage would lead one to believe that specifying
"--disablewinbind --disablewinbindauth" should probably silence this (non-)error
by disabling winbind authentication altogether, the only thing noted as caring
about smb.conf.  However, this doesn't work either and the error is still generated.

Reading the source reveals that, while authconfig maintains lots of flags to
enable and disable various features, the actual code in authconfig.c::main()
ignores them all and blindly calls the authInfoWrite... functions for each in
turn, spamming errors about any which return failure.  This means config files
for features explicitly de-selected are still written (for example, /etc/yp.conf
and /etc/pam_smb.conf are written even when "--disablesmbauth --disablenis" is
given; although essentially empty, they should not be written at all), or at
least attempted to be written (cf. the smb.conf file).  Some of this is masked
by the shvarFile weirdness which prevents some files (/etc/hesiod.conf) from
being created pointlessly, but authInfoWriteNIS and authInfoWriteWinbind don't
use shvarFiles, so if smb is not installed (and thus no /etc/samba/ dir), the
unexpected failure to write /etc/samba/smb.conf is revealed for all the world to
see.

Why main() does what it does is strange, given that authinfo.c provides a
function authInfoWrite() which calls the exact same authInfoWrite... functions
main() does but does so conditionally based on the flags.  Thus "--disablenis"
skips writing /etc/yp.conf and "--disablewinbind --disablewinbindauth" skips
even the attempt to write /etc/samba/smb.conf.  Granted, main() reports errors
as they happen and authInfoWrite() does not, but surely this is correctable --
either by adding flag checking to the former, or by pushing error reporting into
the latter.

Please correct this.

Version-Release number of selected component (if applicable):
authconfig-4.6.10-rhel4.1.x86_64.rpm

How reproducible:
Always


Steps to Reproduce:
1. Make sure samba is not installed and /etc/samba/ does not exist
2. Run "authconfig --disablewinbind --disablewinbindauth"
3. See error message.  Become sad.
  
Actual results:
Spurious error message --

authconfig: critical error writing /etc//samba/smb.conf: No such file or directory


Expected results:
With no samba configured, authconfig shouldn't be doing anything with smb.conf
let alone calling the failure to do so a critical error.
At worst, explicitly specifying "--disablewinbind --disablewinbindauth" should
serve to eliminate the error.  Actually, without samba installed these flags
default to disabled anyway, but the inability to silence the error even after
explicitly specifying these is particularly galling.


Additional info:

Comment 1 Tomas Mraz 2006-02-27 08:44:54 UTC
This problem will be resolved in the next release of Red Hat Enterprise Linux.
Red Hat does not currently plan to provide a resolution for this in a Red Hat
Enterprise Linux update for currently deployed systems.

With the goal of minimizing risk of change for deployed systems, and in response
to customer and partner requirements, Red Hat takes a conservative approach when
evaluating changes for inclusion in maintenance updates for currently deployed
products. The primary objectives of update releases are to enable new hardware
platform support and to resolve critical defects. 


Note You need to log in before you can comment on or make changes to this bug.