IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This seems to have been basically taken from the manpages/lists.xls
from the docbook-xsl stylesheets. But it references a variable list-indent
that older versions of docbook-xsl (e.g. 1.69) do not provide.
This makes the manpage build break on older systems. Removing
the definition lets the build succeed, using the system-definition
of the itemizedlist/listitem.
The diff between the docbook's (version 1.75.1) definition of
itemizedlist/listitem and the definition in our man.xls is this:
-- with this patch
-- without this patch
@@ -53,5 +53,7 @@
<!-- * seems to require the extra space. -->
<xsl:call-template name="roff-if-end"/>
<xsl:apply-templates/>
- <xsl:text>.RE </xsl:text>
+ <xsl:if test=" following-sibling::listitem">
+ <xsl:text> .RE </xsl:text>
+ </xsl:if>
</xsl:template>
I.e. the version of man.xsl made insertion if ".RE" conditional.
I hope this does not break anything severely.
The diff for e.g. the resulting winbindd.8 manpage is this:
--- with this patch
+++ witout this patch:
@@ -375,7 +375,6 @@
\m[blue]\fBwinbind: rpc only\fR\m[]
Setting this parameter forces winbindd to use RPC instead of LDAP to retrieve information from Domain Controllers\&.
-.RE
.SH "EXAMPLE SETUP"
.PP
To setup winbindd for user and group lookups plus authentication from a domain controller use something like the following setup\&. This was tested on an early Red Hat Linux box\&.
Cheers
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Wed Jan 12 18:13:54 CET 2011 on sn-devel-104
Since commit 7022554, smbds share a printcap cache (printer_list.tdb),
therefore ordering of events between smbd processes is important when
updating printcap cache information. Consider the following two process
example:
1) smbd1 receives HUP or printcap cache time expiry
2) smbd1 checks whether pcap needs refresh, it does
3) smbd1 marks pcap as refreshed
4) smbd1 forks child1 to obtain cups printer info
5) smbd2 receives HUP or printcap cache time expiry
6) smbd2 checks whether pcap needs refresh, it does not (due to step 3)
7) smbd2 reloads printer shares prior to child1 completion (stale pcap)
8) child1 completion, pcap cache (printer_list.tdb) is updated by smbd1
9) smbd1 reloads printer shares based on new pcap information
In this case both smbd1 and smbd2 are reliant on the pcap update
performed on child1 completion.
The prior commit "reload shares after pcap cache fill" ensures that
smbd1 only reloads printer shares following pcap update, however smbd2
continues to present shares based on stale pcap data.
This commit addresses the above problem by driving pcap cache and
printer share updates from the parent smbd process.
1) smbd0 (parent) receives a HUP or printcap cache time expiry
2) smbd0 forks child0 to obtain cups printer info
3) child0 completion, pcap cache (printer_list.tdb) is updated by smbd0
4) smbd0 reloads printer shares
5) smbd0 notifies child smbds of pcap update via message_send_all()
6) child smbds read fresh pcap data and reload printer shares
This architecture has the additional advantage that only a single
process (the parent smbd) requests printer information from the printcap
backend.
Use time_mono in housekeeping functions As suggested by Björn Jacke.
The idmap_rid module should not be used as a default backend.
Also mention that the old snytax "idmap backend = rid:domain=range ..."
is not supported any more.
Autobuild-User: Michael Adam <obnox@samba.org>
Autobuild-Date: Tue Dec 7 19:07:57 CET 2010 on sn-devel-104
vl recently pointed me to a valid reason to use posix locking = no.
Fix the smb.conf manpage to explain this reason, as this question
comes up on the samba mailing list from time to time as well.
Autobuild-User: Kai Blin <kai@samba.org>
Autobuild-Date: Wed Dec 1 10:37:30 CET 2010 on sn-devel-104
This is an initial implementation of the idmap_autorid module.
It works similar to the idmap_rid module but requires less
configuration. It will automatically pick ranges for each domain,
so you do not have to bother any more about adding an idmap
configuration for all of the domains in the forest.
This is very easy to use and to configure and much more
deterministic and faster than idmap_tdb, the typical choice
of Samba users up to now.
