Re: Winbindd!
On Wed, Jun 19, 2002 at 09:15:31AM +0300, Osman Tufanogullari (Garanti Teknoloji) wrote: > Many Thanks Tim for your quick response... > > After sending the mail below, I ran Winbindd with -d3 -i options and i saw that >winbindd was looking for the PDCs' IP adresses of the trusted domains... The first >file winbindd was looking into was lmhosts... > > So, I wrote the domain controllers' IP adresses of the trusted domains into the >lmhosts file in the format > > IPadrssofPDC Domain-Name > > This fixed the problem... Hmm - this may indicate a WINS related problem on your network. I'm glad you got it working though. (-: > But there is another problem now... Our company has ten thousands of user and >thousands of groups.. user count is about 15000... > Sometimes winbindd crashes...I run winbindd deamon, but sometimes later when i use >ps -ef, i cannot see ./winbindd in the list. It kills itself somehow but i dont >know... But sometimes it is in the list running for hours... Bummer - can you get a stack backtrace of winbindd crashing? > One more question. Today i also work on it but when you look into a share's >properties on NT or 2000 desktop, there is a Security tab on this panel... > > If you have a share on a linux server ( intented to use as a file & print server ), >from a windows NT or 2000 desktop, > > Can we define security parameters (adding and deleting user with read/write rights) >using that panel? I think share level security is supported in the 2.2 series of Samba. Give it a try and find out! Tim.
max smbd processes
hello, i'm using Samba Version 2.2.4 on Solaris 5.8 in my smb.conf i have max smbd processes = 200 when i use tesparm for checking i've the following answer : ERROR: the 'max smbd processes' parameter is set and the 'status' parameter is set to 'no'. What is wrong in my configuration ? thanks a lot for reply Alain Defrance Ingénieur systèmes et réseaux Service Informatique Université d'Evry Val d'Essonne [EMAIL PROTECTED] 01.69.47.80.69 06.74.09.19.54 www.univ-evry.fr
RE: Winbindd!
Many Thanks Tim for your quick response... After sending the mail below, I ran Winbindd with -d3 -i options and i saw that winbindd was looking for the PDCs' IP adresses of the trusted domains... The first file winbindd was looking into was lmhosts... So, I wrote the domain controllers' IP adresses of the trusted domains into the lmhosts file in the format IPadrssofPDC Domain-Name This fixed the problem... But there is another problem now... Our company has ten thousands of user and thousands of groups.. user count is about 15000... Sometimes winbindd crashes...I run winbindd deamon, but sometimes later when i use ps -ef, i cannot see ./winbindd in the list. It kills itself somehow but i dont know... But sometimes it is in the list running for hours... One more question. Today i also work on it but when you look into a share's properties on NT or 2000 desktop, there is a Security tab on this panel... If you have a share on a linux server ( intented to use as a file & print server ), from a windows NT or 2000 desktop, Can we define security parameters (adding and deleting user with read/write rights) using that panel? Thanks in advance... -Original Message- From: Tim Potter [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 19, 2002 2:35 AM To: Osman Tufanogullari (Garanti Teknoloji) Cc: [EMAIL PROTECTED] Subject: Re: Winbindd! On Tue, Jun 18, 2002 at 01:55:44PM +0300, Osman Tufanogullari (Garanti Teknoloji) wrote: > But after starting winbindd deamon, > > wbinfo -m ( trusted domain names ) --> OK > wbinfo -t ( check secret ) --> OK > wbinfo -n username ( sid from username ) --> OK > wbinfo -s sid ( username from sid) --> OK > > options work properly. > > But > > wbinfo -u and wbinfo -g end with error > "Error looking up domain users", > "Error looking up domain groups". Are you running with the RestrictAnonymous registry setting? Alternately are you running a Windows 2000 environment only? You may need to set a username and password for winbindd so it can connect to the domain controllers without using an anonymous session. Tim.
Summary of group API discussion V1
Hi Andrew, hi Kai,
here's a little summary of our lastest discusion.
should we need TALLOC_CTX *mem_ctx; somewhere else?
-
typedef _SAM_GROUP {
char *name;
char *comment;
DOM_SID sid;
/* here we can store some use full info about the group
- group type local,domain,builtin, ...
*/
int32 flags;
PRIVILEGE_SET priv_set;
/* specify the groupdb backend */
struct gdb_methods *method;
} SAM_GROUP
typedef _SAM_GROUP_MAP {
char *name;
DOM_SID sid;
gid_t gid;
/* here we can store some use full info about the group
- group type local,domain,builtin, ...
*/
int32 flags;
/* Did we need the PRIVILEGE_SET here? */
/* specify the groupdb backend */
struct gdb_methos *method;
} SAM_GROUP_MAP
typedef _SAM_GROUP_MEMBER {
DOM_SID sid;
/*Is the member a group or user?*/
BOOL group;
/* if we store the member in the group backend
or this group the primary Group of the member ?
*/
BOOL stored;
} SAM_GROUP_MAP
typedef _SAM_GROUP_ENTRY {
char *name;
char *comment;
DOM_SID sid;
gid_t gid;
/* here we can store some use full info about the group
- group type local,domain,builtin, ...
*/
int32 flags;
PRIVILEGE_SET priv_set;
int32 members_count;
SAM_GROUP_MEMBER **members;
TALLOC_CTX *mem_ctx;
/* specify the groupdb backend */
struct gdb_methods *method;
} SAM_GROUP_MAP
GROUP API:
Were should we use only the SID and not SAM_GROUP ?
NTSTATUS gdb_add_samgroup(SAM_GROUP *samgroup) //should call gdb_add_mapping
NTSTATUS gdb_update_samgroup(SAM_GROUP *samgroup)
NTSTATUS gdb_delete_samgroup(SAM_GROUP *samgroup)//should call
gdb_delete_mapping
NTSTATUS gdb_enum_groups(int32 *groups_count, SAM_GROUP **groups, int32 flag)
NTSTATUS gdb_get_group_by_sid(SAM_GROUP **samgroup, DOM_SID *sid)
NTSTATUS gdb_get_group_by_name(SAM_GROUP **samgroup,char *domain ,char *name)
NTSTATUS gdb_add_member_to_group(SAM_GROUP *samgroup, SAM_GROUP_MEMBER *member)
NTSTATUS gdb_delete_member_from_group(SAM_GROUP *samgroup, SAM_GROUP_MEMBER
*member)
NTSTATUS gdb_enum_members(DOM_SID *group_sid, int32 *members_count,
SAM_GROUP_MEMBER **members)
(Not discussed yet! :-)
GROUP MAPPING API:
NTSTATUS gdb_add_mapping(SAM_GROUP_MAP *gmap)
NTSTATUS gdb_update_mapping(SAM_GROUP_MAP *gmap)
NTSTATUS gdb_delete_mapping(SAM_GROUP_MAP *gmap)
NTSTATUS gdb_enum_mappings(int32 *mappings_count, SAM_GROUP_MAP
**mappings,int32 flag)
NTSTATUS gdb_get_mapping_by_sid(SAM_GROUP_MAP **mapping, DOM_SID *sid)
NTSTATUS gdb_get_mapping_by_gid(SAM_GROUP_MAP **mapping, gid_t gid)
NTSTATUS gdb_get_mapping_by_name(SAM_GROUP_MAP **mapping,char *domain ,char
*name) //Did we need char *domain here?
GROUP BACKEND API:
...later:-)
metze
-
Stefan "metze" Metzmacher <[EMAIL PROTECTED]>
VPN Gateway, network browsing
Hi, Hi, we are use VPN gateway to merge two Lan network to one. Now any host in one Lan can access the host in another Lan by telnet, ftp, http, ping etc. we want to let the host(win2k) in one Lan can browsing the hosts in another Lan in network neighbour. So we want to use samba as the wins for the two Lan. The problems is: I can access the remote host in linux machine by mount -t smbfs -o username=tridge,password=foobar //fjall/test /data/test and the remote host can be browsing in the local network neighbor in win2K, but we can still not access it. the error messages is: The semaphone timeout period has expired. Could you give me some suggestions? =Remote configuration of smb=== [global] workgroup = WORKGROUP wins support = yes server string = Internal Docs, Downloads, and Web Pages os level = 1 short preserve case = yes preserve case = yes domain logons = no local master = yes lock directory = /var/lock/samba locking = yes strict locking = yes share modes = yes security = user socket options = TCP_NODELAY log file = /var/log/samba ;max log size = 5000 veto files = /Network Trash Folder/ encrypt passwords = yes dead time = 5 debug level = 0 dns proxy = no domain master = yes guest account = guest local master = yes preferred master = yes alternate permissions = no case sensitive = no default case = upper delete readonly = yes follow symlinks = yes locking = yes mangle case = no map hidden = yes map system = yes oplocks = yes preserve case = yes short preserve case = yes strict locking = yes delete veto files = yes wide links = yes hosts allow = 192.168.100. 192.168.110. localhost 192.168.5. remote announce = 192.168.110.1 192.168.5.96 remote browse sync = 192.168.110.1 192.168.5.96 =Local configuration of smb=== [global] workgroup = WORKGROUP netbios name = fileserver server string = SDC Engineering FileServer hosts allow = 192.168.5. 192.168.100. 127. log file = /var/log/samba/%m.log max log size = 3000 security = user encrypt passwords = yes smb passwd file = /etc/samba/smbpasswd unix password sync = Yes passwd program = /usr/bin/passwd %u passwd chat = *New*password* %n\n *Retype*new*password* %n\n*passwd:*all*authentication*tokens*updated*successfully* username map = /etc/samba/smbusers socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 remote announce = 192.168.100.8 local master = yes os level = 64 domain master = yes preferred master = yes domain logons = yes logon script = %U.bat wins support = yes dns proxy = no
Re: NTLM authentication with smblib against AD
Yuquan Jiang wrote: > > I have been using smblib 1.0 to implement NTLM authentication to PDCs. > Now I find it fail to authenticate with a win2k server running active > directory. > Is there any patch to this SMB library that can talk to AD to > authenticate users *Please* don't use smblib, smbval, libsmb++ etc for various hacked-up authenticaions schemes The samba team has deveoped a quite sensible interface for this - use pam_winbind or (but this interface changes more often) the winbind socket interface. You will find that various client libs only support older dialects of the protocol, and therefore fail when the remote server only accepts NT authenticaion (not the LM used in older versions). Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
NTLM authentication with smblib against AD
I have been using smblib 1.0 to implement NTLM authentication to PDCs. Now I find it fail to authenticate with a win2k server running active directory. Is there any patch to this SMB library that can talk to AD to authenticate users with NTLM ? Thanks a lot. Yuquan
Re: UTF-8 support and other quirks in the LDAP backend (in 2.2.4).
"Shahms E. King" wrote: > > > One problem we uncovered is that the backend needs to convert all strings > > stored in LDAP to/from UTF-8. This mainly affects users real names which > > look quite borked if they contain non 7bit ASCII chars. Some LDAP servers > > will let you use any charset but OpenLDAP likes to enforce UTF-8 (also the > > LDAPv3 standard mandates it). > > Well, that's what I get for living in the US, i18n bugs don't tend to > bite me in the butt. Yes, we have a patch in the works to do this for the ADS LDAP code, and once that is in I'll look at how to merge it for pdb_ldap. > > Binding to the LDAP server with v3 of the protocol would be nice, since v2 > > is deprecated in OpenLDAP v2.1 (OK, so v2.1 isn't ready for prime time > > yet, but it's still nice to get it done). > > We do bind in v3 if it's supported, otherwise we fall back to v2 (or at > least, we used to, but I'm pretty sure it hasn't changed.) > > > Sane defaults need to be added for optional attributes, for example > > pwdMustChange ought to be never if it's not present in the users > > record. > > This sounds suspiciously like the (more serious) rid issues that > happened a while ago, but I don't think it should be something that is > too difficult to fix; then again, I haven't looked at pdb_ldap.c in a > while. This is fixed in HEAD, and has been for a fair while. Attributes not present revert to defaults, and are not resaved. > > My question is if anyone is actively working on the LDAP backend and if > > the above problems will be fixed soon. Else I will start working on it > > myself and submit some patches. > > I don't know about the other contributors, but I personally am no longer > actively working on it. I do, however, maintain an active interest in > it, and if I'm mistaken about binding with version 3, that is something > I will address. I am, however, woefully lacking knowledge about > character set conversions at the moment, so if you would care to take > care of those issues I (and the rest of the non-English speaking, LDAP > and Samba using world) would be grateful. I maintain pdb_ldap in HEAD, as I use it at my site. (It was a the subject of a mildly hostile takeover earlier this year, along with the rest of the passdb subsystem ;-) Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: UTF-8 support and other quirks in the LDAP backend (in 2.2.4).
On Wed, Jun 19, 2002 at 12:02:00AM +0200, Simo Sorce wrote: > > > Yes, I think internal format (and format for tdbs) of utf8 seems > > > like the best idea (IMHO). > > There is a problem with utf8 for many fixed-size records in various tdbs. > > Also, most of data is in UCS-2 already. I don't think that's true. Most data should be in unix character set. > Not only that, utf-8 is not easy to manipulate as characters are not > fixed lenght an upper case and lower case ones are not guaranted to be > long the same amount of bytes. Why would you need to manipulate the string on a character by character basis? The only case I can think of is the name mangling system. Every other part of Samba only cares about the total length of the string. > So UCS-2 is more suitable for most of the manipulations, utf8 is more > suitable to deal with unix system (file names, ecc..). > > But, as windows yet speak ucs-2 with us, it is better to use that > internally, so that conversions are kept to a minimum, and manipulation > of data is much easier and faster. > > Relegating utf8, in the long term to an internal vfs conversion for file > name storage purposes (yes I advocate an ucs2 vfs interface for the next > ntfs like semantic rewrite). Yuck. (-: Tim.
Re: Winbindd!
On Tue, Jun 18, 2002 at 01:55:44PM +0300, Osman Tufanogullari (Garanti Teknoloji) wrote: > But after starting winbindd deamon, > > wbinfo -m ( trusted domain names ) --> OK > wbinfo -t ( check secret ) --> OK > wbinfo -n username ( sid from username ) --> OK > wbinfo -s sid ( username from sid) --> OK > > options work properly. > > But > > wbinfo -u and wbinfo -g end with error > "Error looking up domain users", > "Error looking up domain groups". Are you running with the RestrictAnonymous registry setting? Alternately are you running a Windows 2000 environment only? You may need to set a username and password for winbindd so it can connect to the domain controllers without using an anonymous session. Tim.
Re: conncet_to_domain_password_server does not handle multi-homedDCs it seems ...
On Tue, 18 Jun 2002, Gerald Carter wrote: > On Wed, 19 Jun 2002, Richard Sharpe wrote: > > > This happens if WINS fails and DNS is used to translate the address. I am > > not sure what happens if WINS returns multiple addresses ... > > Ahhh..so we are not handling the **h_addr_list field in the hostent > struct? That is right. I created a name_resolve_2 that can return a list of addresses, but for the moment, most of the code uses name_resolve, which only returns the first address :-( Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: SMB signing.
On Tue, Jun 18, 2002 at 05:17:29PM -0500, Christopher R. Hertel wrote: > Jeremy, I am very interested in this as well. I don't have much of a > lab at present (my primary machine is having motherboard trouble), but > if I can help please let me know. I want to document how this > (actually) works. Right now it doesn't look as though it does (at least between different versions of Windows :-). Jeremy.
Re: SMB signing.
Jeremy, I am very interested in this as well. I don't have much of a lab at present (my primary machine is having motherboard trouble), but if I can help please let me know. I want to document how this (actually) works. Chris -)- Jeremy Allison wrote: > > Hi all, > > Is anyone using Windows SMB signing in a production > environment ? > This is the signing proceedure created by setting the Registry keys > EnableSecuritySignature:1, RequireSecuritySignature: 1 in the > lanmanserver and lanmanworkstation parameters. > > I'm playing with implementing this in Samba for 3.0, but am finding > that it doesn't seem to work when mixing Windows NT or Windows 2000 > clients with Windows XP servers. The clients get ACCESS_DENIED > messages from the servers and the signing verification seems to fail. > > Of course it doesn't match the published spec, but that's just to be > expected I guess :-) :-). > > I'd appreciate any data points from people actually running with this > turned on. > > Thanks, > > Jeremy Allison, > Samba Team. -- Christopher R. Hertel -)- University of Minnesota [EMAIL PROTECTED] Networking and Telecommunications Services
SMB signing.
Hi all, Is anyone using Windows SMB signing in a production environment ? This is the signing proceedure created by setting the Registry keys EnableSecuritySignature:1, RequireSecuritySignature: 1 in the lanmanserver and lanmanworkstation parameters. I'm playing with implementing this in Samba for 3.0, but am finding that it doesn't seem to work when mixing Windows NT or Windows 2000 clients with Windows XP servers. The clients get ACCESS_DENIED messages from the servers and the signing verification seems to fail. Of course it doesn't match the published spec, but that's just to be expected I guess :-) :-). I'd appreciate any data points from people actually running with this turned on. Thanks, Jeremy Allison, Samba Team.
Re: UTF-8 support and other quirks in the LDAP backend (in 2.2.4).
On Tue, 2002-06-18 at 20:30, Alexander Bokovoy wrote: > On Tue, Jun 18, 2002 at 11:31:16AM -0700, Jeremy Allison wrote: > > On Tue, Jun 18, 2002 at 01:24:12PM -0500, Steve Langasek wrote: > > > > > > I do hope that tdb ends up going with UTF-8. UCS2 is not particularly > > > pleasant to work with under Unix; it's not endian-neutral, it doesn't > > > provide ASCII as a compatibility subset, and it has to be converted to > > > something else before it can be used by the majority of Unix tools. > > > Granted, to a certain extent this is already true with tdb because it's > > > a binary format, but making the import/export tools more complex gives > > > you less margin for error. Unless Samba chooses UCS-2 as an internal > > > format for string processing (which I also don't think is the best idea > > > in the world ;), using UCS-2 as a backend charset seems like an > > > all-around bad idea, IMHO. > > > > Yes, I think internal format (and format for tdbs) of utf8 seems > > like the best idea (IMHO). > There is a problem with utf8 for many fixed-size records in various tdbs. > Also, most of data is in UCS-2 already. Not only that, utf-8 is not easy to manipulate as characters are not fixed lenght an upper case and lower case ones are not guaranted to be long the same amount of bytes. So UCS-2 is more suitable for most of the manipulations, utf8 is more suitable to deal with unix system (file names, ecc..). But, as windows yet speak ucs-2 with us, it is better to use that internally, so that conversions are kept to a minimum, and manipulation of data is much easier and faster. Relegating utf8, in the long term to an internal vfs conversion for file name storage purposes (yes I advocate an ucs2 vfs interface for the next ntfs like semantic rewrite). Simo. > -- > / Alexander Bokovoy > --- > Most people have a mind that's open by appointment only. > -- Simo Sorce -- Una scelta di liberta': Software Libero. A choice of freedom: Free Software. http://www.softwarelibero.it
Re: conncet_to_domain_password_server does not handle multi-homedDCs it seems ...
On Wed, 19 Jun 2002, Richard Sharpe wrote: > This happens if WINS fails and DNS is used to translate the address. I am > not sure what happens if WINS returns multiple addresses ... Ahhh..so we are not handling the **h_addr_list field in the hostent struct? cheers, jerry - Hewlett-Packard http://www.hp.com SAMBA Team http://www.samba.org --http://www.plainjoe.org "Sam's Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 --"I never saved anything for the swim back." Ethan Hawk in Gattaca--
Re: conncet_to_domain_password_server does not handle multi-homedDCs it seems ...
On Tue, 18 Jun 2002, Gerald Carter wrote: > On Wed, 19 Jun 2002, Richard Sharpe wrote: > > > Hi ... > > > > It does not seem that connect_to_domain_password_server handles > > multi-homed DCs. It always tries the one address returned, and it that > > address happens to be unreachable ... problems ensue ... > > Is this a problem in our code our in the reply from the WINS server. > I vaguely remember this topic coming up before This happens if WINS fails and DNS is used to translate the address. I am not sure what happens if WINS returns multiple addresses ... Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: conncet_to_domain_password_server does not handle multi-homedDCs it seems ...
On Wed, 19 Jun 2002, Richard Sharpe wrote: > Hi ... > > It does not seem that connect_to_domain_password_server handles > multi-homed DCs. It always tries the one address returned, and it that > address happens to be unreachable ... problems ensue ... Is this a problem in our code our in the reply from the WINS server. I vaguely remember this topic coming up before cheers, jerry
conncet_to_domain_password_server does not handle multi-homed DCsit seems ...
Hi ... It does not seem that connect_to_domain_password_server handles multi-homed DCs. It always tries the one address returned, and it that address happens to be unreachable ... problems ensue ... Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Defunct Process
Hello to all, Has anyone ever seen child process of the smbd daemon become a defunct process, and why? Thanks Aaron MinciottiMetaSolv Software 4446, St-Laurent blvd. Suite 300, Montreal (Qc) H2W 1Z5 CANADA Tel.: (514) 904-6416 Fax: (514) 904-6440
Re: UTF-8 support and other quirks in the LDAP backend (in 2.2.4).
On Tue, Jun 18, 2002 at 11:31:16AM -0700, Jeremy Allison wrote: > On Tue, Jun 18, 2002 at 01:24:12PM -0500, Steve Langasek wrote: > > > > I do hope that tdb ends up going with UTF-8. UCS2 is not particularly > > pleasant to work with under Unix; it's not endian-neutral, it doesn't > > provide ASCII as a compatibility subset, and it has to be converted to > > something else before it can be used by the majority of Unix tools. > > Granted, to a certain extent this is already true with tdb because it's > > a binary format, but making the import/export tools more complex gives > > you less margin for error. Unless Samba chooses UCS-2 as an internal > > format for string processing (which I also don't think is the best idea > > in the world ;), using UCS-2 as a backend charset seems like an > > all-around bad idea, IMHO. > > Yes, I think internal format (and format for tdbs) of utf8 seems > like the best idea (IMHO). There is a problem with utf8 for many fixed-size records in various tdbs. Also, most of data is in UCS-2 already. -- / Alexander Bokovoy --- Most people have a mind that's open by appointment only.
Re: UTF-8 support and other quirks in the LDAP backend (in 2.2.4).
On Tue, Jun 18, 2002 at 01:24:12PM -0500, Steve Langasek wrote: > > I do hope that tdb ends up going with UTF-8. UCS2 is not particularly > pleasant to work with under Unix; it's not endian-neutral, it doesn't > provide ASCII as a compatibility subset, and it has to be converted to > something else before it can be used by the majority of Unix tools. > Granted, to a certain extent this is already true with tdb because it's > a binary format, but making the import/export tools more complex gives > you less margin for error. Unless Samba chooses UCS-2 as an internal > format for string processing (which I also don't think is the best idea > in the world ;), using UCS-2 as a backend charset seems like an > all-around bad idea, IMHO. Yes, I think internal format (and format for tdbs) of utf8 seems like the best idea (IMHO). Jeremy.
Re: UTF-8 support and other quirks in the LDAP backend (in 2.2.4).
On Tue, Jun 18, 2002 at 07:05:25PM +0200, Stefan (metze) Metzmacher wrote: > >One problem we uncovered is that the backend needs to convert all strings > >stored in LDAP to/from UTF-8. This mainly affects users real names which > >look quite borked if they contain non 7bit ASCII chars. Some LDAP servers > >will let you use any charset but OpenLDAP likes to enforce UTF-8 (also the > >LDAPv3 standard mandates it). > >Binding to the LDAP server with v3 of the protocol would be nice, since v2 > >is deprecated in OpenLDAP v2.1 (OK, so v2.1 isn't ready for prime time > >yet, but it's still nice to get it done). > >Sane defaults need to be added for optional attributes, for example > >pwdMustChange ought to be never if it's not present in the users > >record. > >My question is if anyone is actively working on the LDAP backend and if > >the above problems will be fixed soon. Else I will start working on it > >myself and submit some patches. > I didn't know that someone is actually working on this, > but it was discussed to make the whole passdb subsystem using multibyte > charsets. > I remeber UTF-8 for LDAP and UCS2 for tdb.. I do hope that tdb ends up going with UTF-8. UCS2 is not particularly pleasant to work with under Unix; it's not endian-neutral, it doesn't provide ASCII as a compatibility subset, and it has to be converted to something else before it can be used by the majority of Unix tools. Granted, to a certain extent this is already true with tdb because it's a binary format, but making the import/export tools more complex gives you less margin for error. Unless Samba chooses UCS-2 as an internal format for string processing (which I also don't think is the best idea in the world ;), using UCS-2 as a backend charset seems like an all-around bad idea, IMHO. Steve Langasek postmodern programmer msg01458/pgp0.pgp Description: PGP signature
Re: UTF-8 support and other quirks in the LDAP backend (in 2.2.4).
> One problem we uncovered is that the backend needs to convert all strings > stored in LDAP to/from UTF-8. This mainly affects users real names which > look quite borked if they contain non 7bit ASCII chars. Some LDAP servers > will let you use any charset but OpenLDAP likes to enforce UTF-8 (also the > LDAPv3 standard mandates it). Well, that's what I get for living in the US, i18n bugs don't tend to bite me in the butt. > Binding to the LDAP server with v3 of the protocol would be nice, since v2 > is deprecated in OpenLDAP v2.1 (OK, so v2.1 isn't ready for prime time > yet, but it's still nice to get it done). We do bind in v3 if it's supported, otherwise we fall back to v2 (or at least, we used to, but I'm pretty sure it hasn't changed.) > Sane defaults need to be added for optional attributes, for example > pwdMustChange ought to be never if it's not present in the users > record. This sounds suspiciously like the (more serious) rid issues that happened a while ago, but I don't think it should be something that is too difficult to fix; then again, I haven't looked at pdb_ldap.c in a while. > My question is if anyone is actively working on the LDAP backend and if > the above problems will be fixed soon. Else I will start working on it > myself and submit some patches. I don't know about the other contributors, but I personally am no longer actively working on it. I do, however, maintain an active interest in it, and if I'm mistaken about binding with version 3, that is something I will address. I am, however, woefully lacking knowledge about character set conversions at the moment, so if you would care to take care of those issues I (and the rest of the non-English speaking, LDAP and Samba using world) would be grateful. --Shahms
Re: UTF-8 support and other quirks in the LDAP backend (in 2.2.4).
At 18:44 18.06.2002 +0200, Fredrik Ohrn wrote: >Hello! > >We are currently migrating from using a smbpasswd file to LDAP. > >One problem we uncovered is that the backend needs to convert all strings >stored in LDAP to/from UTF-8. This mainly affects users real names which >look quite borked if they contain non 7bit ASCII chars. Some LDAP servers >will let you use any charset but OpenLDAP likes to enforce UTF-8 (also the >LDAPv3 standard mandates it). > >Binding to the LDAP server with v3 of the protocol would be nice, since v2 >is deprecated in OpenLDAP v2.1 (OK, so v2.1 isn't ready for prime time >yet, but it's still nice to get it done). > >Sane defaults need to be added for optional attributes, for example >pwdMustChange ought to be never if it's not present in the users >record. > > >My question is if anyone is actively working on the LDAP backend and if >the above problems will be fixed soon. Else I will start working on it >myself and submit some patches. I didn't know that someone is actually working on this, but it was discussed to make the whole passdb subsystem using multibyte charsets. I remeber UTF-8 for LDAP and UCS2 for tdb.. See in the samba-technical archives the last few days the SUBJECT was: passdb TODO list I think patches are very welcome:-) >Regards, >Fredrik > >-- >"It is easy to be blinded to the essential uselessness of computers by >the sense of accomplishment you get from getting them to work at all." >- Douglas Adams > >Fredrik Öhrn Chalmers University of Technology >[EMAIL PROTECTED] Sweden metze - Stefan "metze" Metzmacher <[EMAIL PROTECTED]>
Re: proposal: libsmbclient functionality addition
On Tue, 18 Jun 2002, Tom Jansen wrote: > Hi, > > > Here, I want to make it possible for people do do: > > > > smbc_handle1 = smbc_init(client_name1); > > > > ... a bunch of ops using smbc_handle1; > > > > smbc_handle2 = smbc_init(client_name1); > > > > ... a bunch of ops using smbc_handle2 > > > > That is, a single program can pretend to be multiple clients. > > I can make some time to help you implement this stuff if you would like that. > I've got a few extra questions about that too: > > o Will all smbc_* functions get the handle when called ? Yes, they have to be given the file handle. The major issue here is that this will break all existing programs. I have spent some time trying to think of a way to avoid this breakage, but fear that I cannot do it easily. > o Will the filetables still be global or will they be handle specific ? (Global > is better IMHO. That way, only connection-initializing functions like smbc_open > need the handle. And this eases porting to the "future"-libsmbclient) This is a good point. The filetable should perhaps be global. > Furthermore, my upcoming patch (for the suggestions that started this thread) is > coming along nicely. I'm busy cleaning it up to match the samba-code-style. great ... > Some new features: > o The cache system is different now. By default the internal cache system is > used but that is changeable. (I will explain this beter when the patch arrives) > o The servers are organized in a server_table now and have filedescriptors so we > don't have to give internal information to an externa cache system. (I think > this approach eases the change to the "handle-system" you mentioned above.) > o Checking of the server connection before it will be pulled out of cache. > o Transparant reconnects upon failures. > > Please, if you (Richard, the samba-technical people) have any suggestions, speak. OK. I will wait for the patch ... Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
UTF-8 support and other quirks in the LDAP backend (in 2.2.4).
Hello! We are currently migrating from using a smbpasswd file to LDAP. One problem we uncovered is that the backend needs to convert all strings stored in LDAP to/from UTF-8. This mainly affects users real names which look quite borked if they contain non 7bit ASCII chars. Some LDAP servers will let you use any charset but OpenLDAP likes to enforce UTF-8 (also the LDAPv3 standard mandates it). Binding to the LDAP server with v3 of the protocol would be nice, since v2 is deprecated in OpenLDAP v2.1 (OK, so v2.1 isn't ready for prime time yet, but it's still nice to get it done). Sane defaults need to be added for optional attributes, for example pwdMustChange ought to be never if it's not present in the users record. My question is if anyone is actively working on the LDAP backend and if the above problems will be fixed soon. Else I will start working on it myself and submit some patches. Regards, Fredrik -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams Fredrik Öhrn Chalmers University of Technology [EMAIL PROTECTED] Sweden
Re: proposal: libsmbclient functionality addition
Hi, > Here, I want to make it possible for people do do: > > smbc_handle1 = smbc_init(client_name1); > > ... a bunch of ops using smbc_handle1; > > smbc_handle2 = smbc_init(client_name1); > > ... a bunch of ops using smbc_handle2 > > That is, a single program can pretend to be multiple clients. I can make some time to help you implement this stuff if you would like that. I've got a few extra questions about that too: o Will all smbc_* functions get the handle when called ? o Will the filetables still be global or will they be handle specific ? (Global is better IMHO. That way, only connection-initializing functions like smbc_open need the handle. And this eases porting to the "future"-libsmbclient) Furthermore, my upcoming patch (for the suggestions that started this thread) is coming along nicely. I'm busy cleaning it up to match the samba-code-style. Some new features: o The cache system is different now. By default the internal cache system is used but that is changeable. (I will explain this beter when the patch arrives) o The servers are organized in a server_table now and have filedescriptors so we don't have to give internal information to an externa cache system. (I think this approach eases the change to the "handle-system" you mentioned above.) o Checking of the server connection before it will be pulled out of cache. o Transparant reconnects upon failures. Please, if you (Richard, the samba-technical people) have any suggestions, speak. Yours, -- Tom Jansen -- [EMAIL PROTECTED] Ninja ISD -- www.ninja.nl
Re: proposal: libsmbclient functionality addition
On Tue, 18 Jun 2002, Tom Jansen wrote: > > The next big set of changes I need to make are allowing one program to > > instantiate multiple clients. This is something that is needed ... > > That would result in? reentrant code ? or just the cache lookup/maintenance > outside of libsmbclient.c? I've done some work on the last one but it's not done > yet. Here, I want to make it possible for people do do: smbc_handle1 = smbc_init(client_name1); ... a bunch of ops using smbc_handle1; smbc_handle2 = smbc_init(client_name1); ... a bunch of ops using smbc_handle2 That is, a single program can pretend to be multiple clients. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Winbindd questions and concerns
All, Currently we are deploying a standard desktop release of Linux Redhat 7.3 built around the samba/winbindd components to allow NT authentication into our workstations. One of our major concerns is SUID->UID mappings. I notice that the algorithm that is build into the software to date creates random UIDs within a lock file. That scenario can get pretty messy in a distributed environment when dealing with NFS since most of the infrastructure on our desktops here at ML utilize NFS. I was curious if any sort of development has been created to resolve this using a centralized lock file? Or perhaps something similar to NIS where can maintain similar UIDs across all our workstations. I know LDAP can be used as a much better setup but we are about 1-2 years away from running that in production since we are dealing with well over 48k NT accounts, which is a HUGE migration for us. I did notice some development work has been done with the Samba-TNG branch which seems to using something called SURS.. does anyone have any more information on this? Thanks, Christopher Johnston Merrill Lynch / DCSA (201) 671-2368 http://linux.worldnet.ml.com
need help
Dear Sir/mdn, I have some problems which may need your guidiance to slove this samba setup. (version 1.9.18p10-3) on my linux redhat apollo 5.2 . I had no problem using ping from win98 client or telnet sesssion but with neigbourhood browsing . I cannot map the network server showing error . the specified computer did not received your request,try again later ! hmwhats is the problems. I had books like dummies samba setup ( though its version is 2.03 but i m running verison i had mentioned 1.9.18..) and it didnt help to solve. I even got problems with smbclient -L server showing errors...session request failure ( 131,129) but i can read my window clientwith a list of directories and share shown though it shown lmhost file cannot be found , error.. I am confused by the book , some says use lmhost file, others says do not ..pls use wins ..better. ! ? can i run the share even if i dun use DNSfor to me ...it a bit confusing now ...DNS ..LMHost ..Wins.Domain s. aha...sounds confusing! Please advise me Million thanKs! Pls email me back at [EMAIL PROTECTED] :-((
Winbindd!
Title: Winbindd! Hi All, This is the first message I write to the mailing list and please forgive me if the content of the message is not related with your subjects... My question is about winbindd deamon ; I installed samba 2.2.4 rpm... Everything works fine. Print and home shares are ok. smb.conf directs the samba to use Security = Domain authentication and passwords are controlled by PDC. I am sure of those. But after starting winbindd deamon, wbinfo -m ( trusted domain names ) --> OK wbinfo -t ( check secret ) --> OK wbinfo -n username ( sid from username ) --> OK wbinfo -s sid ( username from sid) --> OK options work properly. But wbinfo -u and wbinfo -g end with error "Error looking up domain users", "Error looking up domain groups". getents shows only local users ( I think this is because of the error I get when run wbinfo -u and -g ) Do you have any solution to the problem? Many thanks in advance. Itri Osman.
Re: [Fwd: Finger problem on Solaris with 2.2.4 (PR#24659)]
On Mon, 17 Jun 2002, Jeremy Allison wrote: > On Mon, Jun 17, 2002 at 12:24:34PM +0100, David Lee wrote: > > > > So my trial implementation was: > > 1. "smbd" to create/delete "/dev/smb/n" as a "named pipe"; > > > > 2. "smbd" then to include this in its "select()"; > > > > 3. anything appearing on "/dev/smb/n" to be sent to the client PC as a > >WinPopup, using code very similar (and potentially common) to > >"smbclient -M". > > > > As a proof of concept it solved the "who" problem, and added this extra > > wall/write functionality. > > Unfortunately this is harder to do right than it appears. Even tridge > created a bug when this was done for the select/kernel oplock code > (it's finally fixed for 2.2.5). I can believe that... Being a Solaris site, I had noticed during the last year of 2.2.x evolution that this area was relevant to those pernicious oplock and avalanching problems whilst marvelling at the abilities of the Samba Team to understand subtleties of the problems. So my trials were only ever intended to be "proof of concept", and I realised that this area in particular (events, select()) would need the eagle-eyes and experience of the Samba Team. > To do this easily requires a proper "event" mechanism. I know how > to do this, but currently lack the time to code it up. Indeed. In my tentative dabbling around that select(), I, too, thought "this ideally needs a rationalised event handler". > IMHO we need the even[t] mechanism in smbd before we can start > adding stuff like this. Agreed. But it would be nice to see the event mechanism in place! Then the rest of us could begin to code up our ideas. This principle seems roughly analogous to, and sympathetic with, other Samba developments, such as the [cascading] VFS structure, and Andrew B's authentication work. I know that Andrew B. (and others?) have doubts about implementing various aspects of this (create/delete "/dev/smb/n"; reading "/dev/smb/n") inside "smbd". I respect their concerns and their experience, and their responsibilities as Samba-maintainers. Could such an event mechanism be somehow linked to a plugin-like mechanism (as with, for example: VFS and authentication)? This would clearly partition the responsibilities (core smbd v. plugin) while maintaining relative ease of implementation, and maximising flexibility. Best wishes. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: proposal: libsmbclient functionality addition
Hi Richard, samba-technical, > > The most important part is detecting these disconnects and acting nice > > upon occurance. I think there are two ways: > > o A callback mechanism to give disconnect messages to the user > > (libsmbclient.c and user-written code). > > o A simple check in smbc_server(): send keepalive packet and check > > cli->fd for errors (in all the clientcode I've seen, the fd is set to -1 > > on error). > > Sending a keep-alive requires that you call down into libsmbclient every > now and then from the application ... You should be able to detect that > the connection has gone, as you indicate, on the next time you call down > to libsmbclient. So, you might not need the keep-alive. The keep-alive is useful for detecting that the remote end closed the connection. If this has occured cli->fd == -1 afterwards. The keep-alive is the most harmless packet IMHO so it is great for a test. > However, from the point of view of GTK+ apps, it would be worth while > having that. Something like smbc_check_server(char *srv, char* share, char *usr, char *pwd) might be nice. It might contribute to a manual implementation. > > I prefer the last for increased simplicity. Maybe the samba gurus disagree > > but that's why I'm posting this here. > > > > Is there any interest in such code? I'm quite happy to code it up and > > Please go ahead. I will! expect patches soon. > The next big set of changes I need to make are allowing one program to > instantiate multiple clients. This is something that is needed ... That would result in? reentrant code ? or just the cache lookup/maintenance outside of libsmbclient.c? I've done some work on the last one but it's not done yet. > Regards Tom -- Tom Jansen -- [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign Ninja ISD -- www.ninja.nl \ / No HTML or RTF in mail or news X No proprietary word-processing Respect Open Standards / \ files in mail or news
Re: Cascaded VFS patch
On Tue, Jun 18, 2002 at 06:29:10PM +1000, Andrew Bartlett wrote: > Simo Sorce wrote: > > > > On Tue, 2002-06-18 at 09:05, Andrew Bartlett wrote: > > > Simo Sorce wrote: > > > > + /* Handles on dlopen() call */ > > > > + smb_vfs_dl_handle *dl_handle; > > > > + void **vfs_private; > > > > > > Why a void** ? > > > > Because you really do not know what the module wants to put there, can > > be anything. > I would have a void* thats all. void** is used to provide each module each own vfs_private pointer so that each module receives its id on registration and then uses conn->vfs_private[id] for storing private data. Otherwise only one module would have its private data. > > no because you can have a different path for any different share, each > > with it's own set of modules. > > I'll defer on this one - its not a major issue. Yes, idea was to have loadpath configurable per share with possible global path which can be overriden if needed. > > > Why? I think we should return errors on failure... > > > > if the dl_handle is null we have an error. > > I don't like signaling errors/status by changing a paratmer - I think it > is better to actually look at the return value. Thats the point I was > trying to make. That function is static and its logic is different from what it was in 2.2.x. Please look closer. > > I think it is important. > > we already are backward compatible for lot of things, why not modules > > that will likely be built outside the samba team and need a bit more > > stable interface OR backwards compatibility? > I just don't want to be maintaining backward compatibilty forever. We already have a pain of constantly changing VFS interfaces -- ask third party developers who use VFS interface (especially antivirus ones) what they think about it... Remember, people are required to support various builds of samba with their product and if we were able to minimize unneeded breaks... -- / Alexander Bokovoy --- Worrying is like rocking in a rocking chair -- It gives you something to do, but it doesn't get you anywhere.
Re: Cascaded VFS patch
Simo Sorce wrote:
>
> On Tue, 2002-06-18 at 09:05, Andrew Bartlett wrote:
> > Simo Sorce wrote:
> > > + /* Handles on dlopen() call */
> > > + smb_vfs_dl_handle *dl_handle;
> > > + void **vfs_private;
> >
> > Why a void** ?
>
> Because you really do not know what the module wants to put there, can
> be anything.
I would have a void* thats all.
> > > +typedef enum _vfs_op_layer {
> > > + SMB_VFS_LAYER_NOOP = -1,/* - For using in VFS module to indicate
>end of array */
> > > + /* of operations description */
> > > + SMB_VFS_LAYER_OPAQUE = 0, /* - Final level, does not call anything
>beyond itself */
> > > + SMB_VFS_LAYER_TRANSPARENT, /* - Normal operation, calls underlying
>layer after */
> > > + /* possibly changing passed data */
> > > + SMB_VFS_LAYER_LOGGER, /* - Logs data, calls underlying layer,
>logging does not */
> > > + /* use Samba VFS */
> > > + SMB_VFS_LAYER_SPLITTER, /* - Splits operation, calls underlying
>layer _and_ own facility, */
> > > + /* then combines result */
> > > + SMB_VFS_LAYER_SCANNER /* - Checks data and possibly initiates
>additional */
> > > + /* file activity like logging to files
>_inside_ samba VFS */
> > > +} vfs_op_layer;
> >
> > I'm still not conviced on this stuff.
>
> I am and this is required for a relly functional cascading mode.
> Trivial schemes will not address the needs of modules makers.
>
> >
> > SAFE_FREE()
> >
>
> ok, ok
>
> > > {"vfs object", P_STRING, P_LOCAL, &sDefault.szVfsObjectFile,
>handle_vfs_object, NULL, FLAG_SHARE},
> > > {"vfs options", P_STRING, P_LOCAL, &sDefault.szVfsOptions, NULL, NULL,
>FLAG_SHARE},
> > > + {"vfs path", P_STRING, P_LOCAL, &sDefault.szVfsPath, NULL, NULL,
>FLAG_SHARE},
> >
> > Why do we need a new smb.conf option? Why can't we just have full paths
> > on objects?
>
> simple, generally parameters are 1024 bytes limited, leaving out the
> path, make it both more readable and less space consuming and make u
> easy to move modules to another path, or make it parametrical.
>
> >
> > If this option does what I think it does, then it really should be
> > global.
>
> no because you can have a different path for any different share, each
> with it's own set of modules.
I'll defer on this one - its not a major issue.
> > > + for(dl_handle = conn->dl_handle; dl_handle->handle; dl_handle++)
>{
> > > + /* Close dlopen() handle */
> > > + done_fptr = (void (*)(connection_struct
>*))sys_dlsym(dl_handle->handle, dl_handle->done_method);
> > > +
> > > + if (done_fptr == NULL) {
> > > + DEBUG(3, ("No %s() symbol found in module with
>handle %p, ignoring\n", dl_handle->done_method, dl_handle->handle));
> > > + } else {
> > > + done_fptr(conn);
> > > + }
> > > + sys_dlclose(dl_handle->handle);
> > > + string_free(&dl_handle->done_method);
> >
> > Why a string_free()?
>
> nice catch, need to look more closely to this point.
>
> > > -static BOOL vfs_init_default(connection_struct *conn)
> > > +static void vfs_init_default(connection_struct *conn)
> > > {
> > > DEBUG(3, ("Initialising default vfs hooks\n"));
> > >
> > > memcpy(&conn->vfs_ops, &default_vfs_ops, sizeof(struct vfs_ops));
> > > - return True;
> > > + conn->dl_handle = NULL;
> > > }
> >
> > Why? I think we should return errors on failure...
>
> if the dl_handle is null we have an error.
I don't like signaling errors/status by changing a paratmer - I think it
is better to actually look at the return value. Thats the point I was
trying to make.
> > > /
> > >initialise custom vfs hooks
> > > /
> > >
> > > -static BOOL vfs_init_custom(connection_struct *conn)
> > > +static BOOL vfs_init_custom(connection_struct *conn, int vfs_number, const char
>*vfs_object)
> > > {
> > > int vfs_version = -1;
> > > - struct vfs_ops *ops, *(*init_fptr)(int *, struct vfs_ops *);
> > > + vfs_op_tuple *ops, *(*init_fptr)(int *, const struct vfs_ops *, int);
> > > + fstring method_init_name;
> > > + fstring vfs_object_name;
> >
> > fstrings are BAD. We might use a lot of them, but *all* new code needs
> > to use
> > asprintf() etc.
>
> it really depends on where they are, but I agree in this case, we have
> to change these bits, before a commit.
>
> > I'm really not conviced that we want to maintain 'backward
> > comp
Re: Cascaded VFS patch
Jean Francois Micouleau wrote:
>
> On 17 Jun 2002, Simo Sorce wrote:
>
> > I've just reviewed Alexander Cascaded VFS patch and found it ok,
> > now I'm attaching a new diff against current CVS to make it easy to test
> > before I commit it into the tree.
> > Unfortunately I have not much time to test it so I have a little request
> > for list attendees.
>
> Just a note about the VFS I wanted to discuss with alexander at sambaXP
> but didn't have the time.
>
> I don't like the idea that the vfs module see the vfs struct and muck with
> it at module's load time.
>
> I would prefer something along all the vfs internal tables hidden to the
> vfs modules and only some vfs functions exported to the vfs modules.
I'm certainly a fan of hiding structs - there is a lot less damage these
things can do when they don't have access to 'the wrong things'.
> What I'm thinking is the samba vfs core exports 2 functions:
> vfs_register_module() and vfs_register_function(). On module loading (in
> the dl_open() function or whatever), the module calls this functions like
> that:
>
> module_dlopen()
> {
> vfs_register_module("my_vfs_module");
>
> vfs_register_function("my_vfs_module", "open", my_module_open);
> vfs_register_function("my_vfs_module", "close", my_module_close);
> vfs_register_function("my_vfs_module", "read", my_module_read);
> vfs_register_function("my_vfs_module", "write", my_module_write);
> }
>
> I thought of that while listening to the VFS presentation at sambaXP, I
> don't see why the vfs structs should be visible and more importantly it
> would allow modules to run even if samba vfs struct changes. Vfs modules
> maintainers wouldn't have to follow samba developement (and changes) as
> close as it's required now.
This sounds interesting, and would apply equally well for pdb and auth
modules.
It also works much better for the builtin-and-or-external case.
My only issue is with the complete loss of compile-time type checking.
How should that be addressed?
Andrew Bartlett,
--
Andrew Bartlett [EMAIL PROTECTED]
Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED]
Student Network Administrator, Hawker College [EMAIL PROTECTED]
http://samba.org http://build.samba.org http://hawkerc.net
Re: Cascaded VFS patch
Very good point, we will address this problem before committing.
On Tue, 2002-06-18 at 09:50, Jean Francois Micouleau wrote:
>
> On 17 Jun 2002, Simo Sorce wrote:
>
> > I've just reviewed Alexander Cascaded VFS patch and found it ok,
> > now I'm attaching a new diff against current CVS to make it easy to test
> > before I commit it into the tree.
> > Unfortunately I have not much time to test it so I have a little request
> > for list attendees.
>
> Just a note about the VFS I wanted to discuss with alexander at sambaXP
> but didn't have the time.
>
> I don't like the idea that the vfs module see the vfs struct and muck with
> it at module's load time.
>
> I would prefer something along all the vfs internal tables hidden to the
> vfs modules and only some vfs functions exported to the vfs modules.
>
> What I'm thinking is the samba vfs core exports 2 functions:
> vfs_register_module() and vfs_register_function(). On module loading (in
> the dl_open() function or whatever), the module calls this functions like
> that:
>
> module_dlopen()
> {
> vfs_register_module("my_vfs_module");
>
> vfs_register_function("my_vfs_module", "open", my_module_open);
> vfs_register_function("my_vfs_module", "close", my_module_close);
> vfs_register_function("my_vfs_module", "read", my_module_read);
> vfs_register_function("my_vfs_module", "write", my_module_write);
> }
>
> I thought of that while listening to the VFS presentation at sambaXP, I
> don't see why the vfs structs should be visible and more importantly it
> would allow modules to run even if samba vfs struct changes. Vfs modules
> maintainers wouldn't have to follow samba developement (and changes) as
> close as it's required now.
>
> J.F.
>
--
Simo Sorce
--
Una scelta di liberta': Software Libero.
A choice of freedom: Free Software.
http://www.softwarelibero.it
Re: Cascaded VFS patch
On Tue, 2002-06-18 at 09:05, Andrew Bartlett wrote:
> Simo Sorce wrote:
> > + /* Handles on dlopen() call */
> > + smb_vfs_dl_handle *dl_handle;
> > + void **vfs_private;
>
> Why a void** ?
Because you really do not know what the module wants to put there, can
be anything.
> > +typedef enum _vfs_op_layer {
> > + SMB_VFS_LAYER_NOOP = -1,/* - For using in VFS module to indicate
>end of array */
> > + /* of operations description */
> > + SMB_VFS_LAYER_OPAQUE = 0, /* - Final level, does not call anything
>beyond itself */
> > + SMB_VFS_LAYER_TRANSPARENT, /* - Normal operation, calls underlying
>layer after */
> > + /* possibly changing passed data */
> > + SMB_VFS_LAYER_LOGGER, /* - Logs data, calls underlying layer,
>logging does not */
> > + /* use Samba VFS */
> > + SMB_VFS_LAYER_SPLITTER, /* - Splits operation, calls underlying
>layer _and_ own facility, */
> > + /* then combines result */
> > + SMB_VFS_LAYER_SCANNER /* - Checks data and possibly initiates
>additional */
> > + /* file activity like logging to files
>_inside_ samba VFS */
> > +} vfs_op_layer;
>
> I'm still not conviced on this stuff.
I am and this is required for a relly functional cascading mode.
Trivial schemes will not address the needs of modules makers.
>
> SAFE_FREE()
>
ok, ok
> > {"vfs object", P_STRING, P_LOCAL, &sDefault.szVfsObjectFile,
>handle_vfs_object, NULL, FLAG_SHARE},
> > {"vfs options", P_STRING, P_LOCAL, &sDefault.szVfsOptions, NULL, NULL,
>FLAG_SHARE},
> > + {"vfs path", P_STRING, P_LOCAL, &sDefault.szVfsPath, NULL, NULL,
>FLAG_SHARE},
>
> Why do we need a new smb.conf option? Why can't we just have full paths
> on objects?
simple, generally parameters are 1024 bytes limited, leaving out the
path, make it both more readable and less space consuming and make u
easy to move modules to another path, or make it parametrical.
>
> If this option does what I think it does, then it really should be
> global.
no because you can have a different path for any different share, each
with it's own set of modules.
> > + for(dl_handle = conn->dl_handle; dl_handle->handle; dl_handle++) {
> > + /* Close dlopen() handle */
> > + done_fptr = (void (*)(connection_struct
>*))sys_dlsym(dl_handle->handle, dl_handle->done_method);
> > +
> > + if (done_fptr == NULL) {
> > + DEBUG(3, ("No %s() symbol found in module with
>handle %p, ignoring\n", dl_handle->done_method, dl_handle->handle));
> > + } else {
> > + done_fptr(conn);
> > + }
> > + sys_dlclose(dl_handle->handle);
> > + string_free(&dl_handle->done_method);
>
> Why a string_free()?
nice catch, need to look more closely to this point.
> > -static BOOL vfs_init_default(connection_struct *conn)
> > +static void vfs_init_default(connection_struct *conn)
> > {
> > DEBUG(3, ("Initialising default vfs hooks\n"));
> >
> > memcpy(&conn->vfs_ops, &default_vfs_ops, sizeof(struct vfs_ops));
> > - return True;
> > + conn->dl_handle = NULL;
> > }
>
> Why? I think we should return errors on failure...
if the dl_handle is null we have an error.
> > /
> >initialise custom vfs hooks
> > /
> >
> > -static BOOL vfs_init_custom(connection_struct *conn)
> > +static BOOL vfs_init_custom(connection_struct *conn, int vfs_number, const char
>*vfs_object)
> > {
> > int vfs_version = -1;
> > - struct vfs_ops *ops, *(*init_fptr)(int *, struct vfs_ops *);
> > + vfs_op_tuple *ops, *(*init_fptr)(int *, const struct vfs_ops *, int);
> > + fstring method_init_name;
> > + fstring vfs_object_name;
>
> fstrings are BAD. We might use a lot of them, but *all* new code needs
> to use
> asprintf() etc.
it really depends on where they are, but I agree in this case, we have
to change these bits, before a commit.
> I'm really not conviced that we want to maintain 'backward
> compatibility'. It sets a precedent, and I'm not comfortable with it.
I think it is important.
we already are backward compatible for lot of things, why not modules
that will likely be built outside the samba team and need a bit more
stable interface OR backwards compatibility?
> Watch that indenting - 8 space tabs please.
oh andrew ...
> > + if (string_set(&vfsobj, lp_vfsobj(SNUM(conn {
> > + /* Parse passed m
Re: Cascaded VFS patch
On 17 Jun 2002, Simo Sorce wrote:
> I've just reviewed Alexander Cascaded VFS patch and found it ok,
> now I'm attaching a new diff against current CVS to make it easy to test
> before I commit it into the tree.
> Unfortunately I have not much time to test it so I have a little request
> for list attendees.
Just a note about the VFS I wanted to discuss with alexander at sambaXP
but didn't have the time.
I don't like the idea that the vfs module see the vfs struct and muck with
it at module's load time.
I would prefer something along all the vfs internal tables hidden to the
vfs modules and only some vfs functions exported to the vfs modules.
What I'm thinking is the samba vfs core exports 2 functions:
vfs_register_module() and vfs_register_function(). On module loading (in
the dl_open() function or whatever), the module calls this functions like
that:
module_dlopen()
{
vfs_register_module("my_vfs_module");
vfs_register_function("my_vfs_module", "open", my_module_open);
vfs_register_function("my_vfs_module", "close", my_module_close);
vfs_register_function("my_vfs_module", "read", my_module_read);
vfs_register_function("my_vfs_module", "write", my_module_write);
}
I thought of that while listening to the VFS presentation at sambaXP, I
don't see why the vfs structs should be visible and more importantly it
would allow modules to run even if samba vfs struct changes. Vfs modules
maintainers wouldn't have to follow samba developement (and changes) as
close as it's required now.
J.F.
