Bug 7330 - Samba does write to /var/lib/samba after installation
Samba does write to /var/lib/samba after installation
Status: RESOLVED INVALID
Product: Samba 3.5
Classification: Unclassified
Component: Config Files
unspecified
Other Linux
: P3 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-06 03:34 UTC by Trickler
Modified: 2010-04-07 00:15 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Trickler 2010-04-06 03:34:47 UTC
Samba does write to /var/lib/samba after installation, which is problematic for all systems where var/lib is RO like for live CD systems.
This is bad style and against rules. 

Since Samba also writes to "/var/cache/samba" I suggest to do all writing after installation to that location.
Comment 1 Björn Jacke 2010-04-06 05:39:46 UTC
by which "definition" is /var/lib/ read-only? Commonly all of /var/ is readwrite. If you have a system with /var/lib/ r/o, feel free to set "{lock,state,cache} directory" in smb.conf to any place where you are able to write or recompile samba to make the paths your personal default.
Comment 2 Trickler 2010-04-06 14:35:27 UTC
@Björn Jacke:
a) /var/cache/'package-name': Package specific cache data.
b) /var/lib/package-name': Holds dynamic data libraries/files like the rpm/dpkg database

Data which samba does write to /var/lib/samba is cache data as specified in a)  and not comparable to case b)

Unless you give specific reasons why samba must write cache data two different directories I uphold my standpoint that it _is_ wrong and bad practice...
Comment 3 Volker Lendecke 2010-04-06 14:39:36 UTC
Do you have references to the FHS that state /var/lib is r/o handy?

Volker
Comment 4 Björn Jacke 2010-04-06 16:22:33 UTC
Tricker, you quote FHS way too short. Is that indended?

http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/var.html

<quote>
1.18. /var
...
Why not put it into /usr? Because there might be circumstances when you may want to mount /usr as read-only, e.g. if it is on a CD or on another computer. '/var' contains variable data, i.e. files and directories the system must be able to write to during operation, whereas /usr should only contain static data
...
</quote>

so /var/ is *rw*.

<quote>
/var/cache

    Is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. This data can generally be regenerated or be restored. Unlike /var/spool, files here can be deleted without data loss. This data remains valid between invocations of the application and rebooting of the system. The existence of a separate directory for cached data allows system administrators to set different disk and backup policies from other directories in /var.
</quote>

so /var/cache is *not* suitable for files like the winbind idmapping TDB.

<quote>
/var/lib

    Holds dynamic data libraries/files like the rpm/dpkg database and game scores. Furthermore, this hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users shouldn't ever need to modify files in /var/lib to configure a package's operation. State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application. An application (or a group of inter-related applications) use a subdirectory of /var/lib for their data. There is one subdirectory, /var/lib/misc, which is intended for state files that don't need a subdirectory; the other subdirectories should only be present if the application in question is included in the distribution. /var/lib/'name' is the location that must be used for all distribution packaging support. Different distributions may use different names, of course.
</quote>

So /var/lib/ is explicitly rw, too. Files like idmapping tdb should be located here.
Comment 5 Volker Lendecke 2010-04-07 00:15:46 UTC
Thanks, Björn :-)

Volker