Printing problems with 2.2.5 - can't see printed document names
Hi, I have Win2k-PL and WinNT-PL users. Samba (print server) is on linux box. Security is set to server (another samba set as PDC). Client login into domain (samba PDC - the same server from which print server gets passwords). Users are ordinary users - no admins, etc. Win2k - SP2, WinNT SP6a. Printer drivers are local. It is very strange, because to get repeatable results I have to restart samba processes (reread with SIGHUP doesn't always work), and to restart windows clients (login/logout is not enough). So: 1. a)samba started with spoolss enabled. Users can print both from WinNT and from Win2K, but they are unable to see jobs submitted to printer. In Win2k in printer properties window they see (translated from polish) Access refused, connection impossible. In WinNT in printer properties: If no document is printed - OK - no errors. If a document is printed I get (translated) Unsuccessful open, retrying. After document is printed - OK - no errors b)now I change disable spoolss to yes. Restart of samba (I don't restart clients, no logout/login) In Win2k - OK - no errors If I print test page I see in jobs: RemoteDownlevelDocument. If I print a document I get the same message. In WinNT - OK - no errors If I print test page I see in jobs Strona testowa - OK (it means Test Page). If I print document - OK - I get correct document name. The names are consistent between clients: If I print from Win2k - the I see this document in NT as RemoteDownlevelDocument. If I print from WinNT - I see correct document name in Win2K. c)now I enable spoolss. Restart of samba (I don't restart clients, no logout/login) No change - as in point 1b). d)Now I logout/login clients I don't restart clients No change - as in point 1b) e)Now I restart clients Now it looks like in point 1a). 2. Fresh start of samba with disabled spoolss, restart of clients. Now it looks like in point 1b). Does anyone has any idea how to get it working correctly? Regards, Olaf Fraczyk, [EMAIL PROTECTED]
Re: [patch] Cascaded VFS v.4
Hi, Apropos VFS patch shouldn't be -D_LARGEFILE64_SOURCE instead of -D_LARGEFILE63_SOURCE ? And another question: I used VFS to build a antivirus scanner and on close method I need (const struct files_struct*)-fsp_name which position depends by this _LARGEFILE64_SOURCE. If one of smbd and my scanner is build with this flag and other is not, on close method smbd with my scanner will crash. Could be rearranged files in this struct such as fields dependent by compilation flags be the last? Regards, Tudore
Re: [patch] Cascaded VFS v.4
On Tue, Jul 09, 2002 at 12:59:28PM +0300, TUDOR Coserea wrote: Hi, Hi, Tudor! Apropos VFS patch shouldn't be -D_LARGEFILE64_SOURCE instead of -D_LARGEFILE63_SOURCE ? There is no such define in new patch. It was, indeed, in old examples/VFS/block/Makefile but now it is replaced by correct code which is autogenerated with all needed CFLAGS from main configure (source/configure) And another question: I used VFS to build a antivirus scanner and on close method I need (const struct files_struct*)-fsp_name which position depends by this _LARGEFILE64_SOURCE. If one of smbd and my scanner is build with this flag and other is not, on close method smbd with my scanner will crash. Could be rearranged files in this struct such as fields dependent by compilation flags be the last? Could you please show how would this struct look correctly? There are files_struct entries (next,prev), various SMB_XXX (dev, inode, pos, size) which all are variable-sized... -- / Alexander Bokovoy --- Communications satellite used by the military for star wars.
Re: [patch] Cascaded VFS v.4
Hi Alexander,
Alexander Bokovoy [EMAIL PROTECTED] writes:
And another question:
I used VFS to build a antivirus scanner and on close method I
need (const struct files_struct*)-fsp_name which position
depends by this _LARGEFILE64_SOURCE. If one of smbd and my
scanner is build with this flag and other is not, on close
method smbd with my scanner will crash. Could be rearranged
files in this struct such as fields dependent by compilation
flags be the last?
Could you please show how would this struct look correctly? There are
files_struct entries (next,prev), various SMB_XXX (dev, inode, pos, size)
which all are variable-sized...
Like this:
typedef struct files_struct
{
struct files_struct *next, *prev;
int fnum;
struct connection_struct *conn;
int fd;
int print_jobid;
mode_t mode;
uint16 vuid;
write_bmpx_struct *wbmpx_ptr;
write_cache *wcp;
struct timeval open_time;
int share_mode;
uint32 desired_access;
time_t pending_modtime;
int oplock_type;
int sent_oplock_break;
unsigned long file_id;
BOOL can_lock;
BOOL can_read;
BOOL can_write;
BOOL print_file;
BOOL modified;
BOOL is_directory;
BOOL directory_delete_on_close;
BOOL delete_on_close;
char *fsp_name;
SMB_DEV_T dev;
SMB_INO_T inode;
SMB_OFF_T pos;
SMB_OFF_T size;
} files_struct;
now all fsp-mode ... fsp-fsp_name fields will not longer depend by compilation
_LARGEFILE64_SOURCE/_LARGEFILE_SOURCE/_FILE_OFFSET_BITS/_GNU_SOURCE defines.
--
/ Alexander Bokovoy
---
Communications satellite used by the military for star wars.
Re: Very bad performance when copying large files from windows to samba-share
I've put up the files on Anonymous-FTP on ftp://heineken.dyndns.ws The files are Snipplets from the beginning of the transaction, covering the timeout, and ending during normal copying. verybadperformance1.txt is a brief text-output from etherreal (1.4MB) Frame 0-10018 verybadperformance2.txt is a detailed text-output from etherreal (5.9MB) Frame 0-3012 verybadperformance3.txt is a detailed text-output from etherreal (22.9MB) Frame 0-1248 The last transaction before the timeout is a write Request to the last byte of the target-file, at about 700MB. This is a typical move of windows-applications to check if enough space is available for the target. During the timeout my linux-box writes a tempfile to disk at size of the source-file. This is due to the write request from the client. If this lasts too long, the whole connection times out. Samba has a swith to prevent these temp-file-creation it's called strict allocate and I set it to OFF just to be shure. I'm really out of ideas, I don't know how to check sambas behaviour when it gets the write-request ! On Tue, 9 Jul 2002 13:29:19 +0200 Ulf Bertilsson [EMAIL PROTECTED] wrote: Please do lookup and hint me to url, registry or related info. I still have a dream that I mange to fix this :) Funny tho, one way it's all fine, just seems like explorer sends anoying dos packets. -- Ulf -Original Message- From: Dan Barrett [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 9:31 PM To: Esh, Andrew; Lars Heineken Cc: Ulf Bertilsson Subject: RE: Very bad performance when copying large files from windows to samba-share I've seen a problem similar to Ulf's. Reading data from a samba share to a Win2k machine over a GigE network was slow. Turned out that the app was issuing 64k reads, which with the SMB proto overhead would end up as two SMB requests, 1 large and 1 very small ~65 byte transfer. So every other SMB request was for only 65 bytes. This caused two problems. 1. Too much SMB proto overhead since 50% of the SMB requests were only transferring 65 bytes. We took a hint from Microsoft and changed the app's readsize to 64420? bytes. Same as you seen when copying files with Windows Explorer. 2. Delayed TCP Acking of the 65 byte packets since the TCP window wasn't full. This delayed sambaserver from sending the 64k. If anything similar is happening to Ulf I can lookup what we did to get around this. Daniel Barrett Storigen Systems -Original Message- From: Esh, Andrew [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 2:59 PM To: 'Lars Heineken'; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Very bad performance when copying large files from windows to samba-share This doesn't appear to me to be the same problem Ulf posted. When looking at those captures, I saw no leading pauses in the data flow. There was the usual directory information gathering, and then the first write request at offset zero, right after that. The performance appeared to be affected by the one or two second pauses near the end of nearly every 64KB transfer chunk. -Original Message- From: Lars Heineken [ mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 1:19 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Very bad performance when copying large files from windows to samba-share This the summary: Most interresting is the gap between the beginning of the transaction and the actual writing (writing begins at about 45sec) Any traffic above this point is just minor. After the 45sec the real transfer begins. As I found no way to search for checksum errors, I didn't found any.. The graph looks like this: -- -- -- ---| | ...45s Or that in Bandwith: ## -- ## -- ---| | ...45s I can attach screenshots if interested. No. TimeSourceDestination Protocol Info 1 0.00lars-heineken.lan 192.168.10.255CUPS ipp://192.168.10.1:631/printers/HPLaserjet6L (idle) 2 10.996660 www.heineken.lan 192.168.10.255CUPS ipp://heineken.lan:631/printers/HPLaserJet6L (idle) 3 11.999360 lars-heineken.lan arne-heineken.lan TCP hostname boomerang [PSH, ACK] Seq=1926846500 Ack=1568123 Win=6432 Len=28 4 12.009310 lars-heineken.lan arne-heineken.lan TCP hostname boomerang [PSH, ACK] Seq=1926846528 Ack=1568123 Win=6432 Len=36 5 12.009479 arne-heineken.lan lars-heineken.lan TCP boomerang hostname [ACK] Seq=1568123 Ack=1926846564 Win=7704 Len=0 6 13.987759 arne-heineken.lan lars-heineken.lan SMB Tree Connect AndX Request, Path: \\LARS-HEINEKEN\IPC$ 7 13.989816 lars-heineken.lan arne-heineken.lan SMB Tree Connect AndX
Re: [patch] Cascaded VFS v.4
On Tue, Jul 09, 2002 at 02:58:51PM +0300, TUDOR Coserea wrote:
Hi Alexander,
Alexander Bokovoy [EMAIL PROTECTED] writes:
And another question:
I used VFS to build a antivirus scanner and on close method I
need (const struct files_struct*)-fsp_name which position
depends by this _LARGEFILE64_SOURCE. If one of smbd and my
scanner is build with this flag and other is not, on close
method smbd with my scanner will crash. Could be rearranged
files in this struct such as fields dependent by compilation
flags be the last?
Could you please show how would this struct look correctly? There are
files_struct entries (next,prev), various SMB_XXX (dev, inode, pos, size)
which all are variable-sized...
Like this:
typedef struct files_struct
{
struct files_struct *next, *prev;
int fnum;
struct connection_struct *conn;
int fd;
int print_jobid;
mode_t mode;
uint16 vuid;
write_bmpx_struct *wbmpx_ptr;
write_cache *wcp;
struct timeval open_time;
int share_mode;
uint32 desired_access;
time_t pending_modtime;
int oplock_type;
int sent_oplock_break;
unsigned long file_id;
BOOL can_lock;
BOOL can_read;
BOOL can_write;
BOOL print_file;
BOOL modified;
BOOL is_directory;
BOOL directory_delete_on_close;
BOOL delete_on_close;
char *fsp_name;
SMB_DEV_T dev;
SMB_INO_T inode;
SMB_OFF_T pos;
SMB_OFF_T size;
} files_struct;
now all fsp-mode ... fsp-fsp_name fields will not longer depend by compilation
_LARGEFILE64_SOURCE/_LARGEFILE_SOURCE/_FILE_OFFSET_BITS/_GNU_SOURCE defines.
Fine for me. Now let's wait few hours when developers from other side of
the planet will wake up :)
--
/ Alexander Bokovoy
---
Nothing is illegal if one hundred businessmen decide to do it.
-- Andrew Young
Re: Draft of branch maintainence and release plans....
On Tue, Jul 09, 2002 at 11:05:39AM +1000, Andrew Bartlett wrote: Just for the record, no one was placing the burden on you andrew (or even suggesting that it rested upon you). If you don't want to do it or would rather work on something else, then that's fine. I think you read too much into the original proposal. No, but from here it does rather look like I'm the only (team) person working on PDC-specific code currently, particularly in HEAD. (Hence why I have am so glad to be working with kai, jelmer and metze on the new SAM stuff - and with idra's keen eye on details I would prefer to gloss over... ;-) You might want to take a look at the ethereal NETLOGON code. Ronnie has been doing lots of work, apparently with netmon.exe and a random packet generator. (-: Just out of curiousity, IIRC Kai did the current trust relationship stuff and tpot did the sam sync stuff. Or am I remembering incorrectly here. I could be. Memory is a little fuzzy. Tpot did the sam sync stuff - but has indicated he is too busy to continue, I worked with mimir on the trusted domains code - most of it was actually done when I did AuthRewrite, and mimir sorted out some important protocol details with the join etc. To be fair most of the code was already in TNG. It just needed debugging and merging and some quiet time in an airport lounge. Tim.
samba 2.2.5 and cups : cant find test code
Hi, I am using RedHat 7.3, and when I try to compile 2.2.5 with --enable-cups it fails with the following message : - # tar jxvf samba-2.2.5.tar.bz2 ... # cd samba-2.2.5/source/ # ./configure --enable-cups ... checking for ssize_t... yes checking for wchar_t... yes checking for cups-config... /usr/bin/cups-config checking for dlopen... no checking for dlopen in -ldl... no checking for immediate structures... yes ... checking for int32 typedef included by rpc/rpc.h... no checking for uint32 typedef included by rpc/rpc.h... no checking for conflicting AUTH_ERROR define in rpc/rpc.h... no checking for test routines... configure: error: cant find test code. Aborting config # - Here is a list of some installed packages : glibc-common-2.2.5-36 glibc-devel-2.2.5-36 glibc-2.2.5-36 glibc-kernheaders-2.4-7.16 make-3.79.1-8 cups-1.1.14-15 cups-devel-1.1.14-15 cups-libs-1.1.14-15 gcc-2.96-110 Any ideas on how to fix this ? -- Jerome
Re: Auditing with VFS
Daniel Niasoff schrieb: When auditing with VFS the pathname recorded is only the relative path for the share not the the full path all the way from root. int audit_close(struct files_struct *fsp, int fd) [..] fstrcpy(fname, fsp-conn-connectpath); fstrcat(fname, /); fstrcat(fname, fsp-fsp_name); [..] Should work. HTH best regards, Rainer Link -- Rainer Link | Student of Computer Networking [EMAIL PROTECTED] | University of Applied Sciences, Furtwangen, Germany rainer.w3.to | http://www.computer-networking.de/
Re: Auditing with VFS
On Tue, Jul 09, 2002 at 05:07:30PM +0100, Daniel Niasoff wrote: When auditing with VFS the pathname recorded is only the relative path for the share not the the full path all the way from root. Are there any plans to change this as I want to use auditing as a method of backing up (i:e: record all files that have been written to and back them up automatically) and as the path is only relative to the share and I have no way of knowing which share is currently being accessed this would be rather difficult. Yes you do know the share path - it's stored in the connection struct passed into the VFS calls or pointed to from the files_struct passed into the VFS calls. Hope this helps, Jeremy.
RE: Draft of branch maintainence and release plans....
Title: RE: Draft of branch maintainence and release plans That's the same code I'm talking about. I have it running. -Original Message- From: Tim Potter [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 10:10 AM To: Esh, Andrew Cc: Gerald Carter; [EMAIL PROTECTED] Subject: Re: Draft of branch maintainence and release plans On Tue, Jul 09, 2002 at 09:47:53AM -0500, Esh, Andrew wrote: I could work on the ext_attr patch, unless what you want out of it is drastically different that what I already have running. I am using the VFS module xfs_ea, which uses libattr from Bestbits and SGI. I can generify xfs_ea so it isn't XFS specific, and release it as a simple libattr interface. Sound good? There was a patch that did most of this already, as well as storing some nifty things like the dos mode bits and NT ACLs. It was fairly intrustive but did a lot of stuff. Tim.
RE: [Draft #2] Samba 3.0 roadmap...idmap storage central idmaprepository
Hi metze, on top of the first doc I see you state that all strings should be utf8. I hearteadly disagree, I woul d rather like to see all internal strings on new code to be UCS-2. Utf8 has many disadvantages: 1. require any RPC requests that comes from clients to be converted forth and back (UCS-2-UTF8-UCS-2) 2. Is difficult to manipulate UTF8 strings as they are variable lenght multibyte chars and sometimes uppercase chars have different lenght than lowercase chars. Simo. On Tue, 2002-07-09 at 15:00, Stefan (metze) Metzmacher wrote: HI Andrew, Andrew Bartlett,Kai Krueger,Jelmer(ctrlsoft)Vernooij and me are designing a new SAM interface and new a SID mapping System (SMS). We discussed it on irc.openprojects.net #samba-technical. Take a look at http://www.kruegernetz.de/SAM-interface.htm and http://www.kruegernetz.de/SAM-interface_handles.txt metze At 11:15 08.07.2002 -0500, Esh, Andrew wrote: About a year ago I suggested this and was told that something was being done about it. My impression was that there were some ideas about how to implement it, and work was in progress. It was suggested that I wait. I'd like to pick up the thread on this, and put some effort behind it. If there are suggested solutions out there, let me know about them. If it is acceptable, I will coordinate this feature. I'd implement my own solution for it, if I can be sure someone else doesn't have better plans. * Winbind idmap storage central idmap repository (for clusters, nfs, etc...) (owner?) metze - Stefan metze Metzmacher [EMAIL PROTECTED] -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
ERROR: in 'security=domain' mode the 'encrypt passwords' parameter must also be set to 'true'
Hello, Playing with my smb.conf on a new server (2.2.5), I noticed that the 'security=domain' and 'encrypt passwords=yes' parameters are somewhat redundant. When commenting out the 'encrypt passwords' line, testparm gave me the error in the subj. I know some config options (such as 'domain master') have recently added a default of 'auto'; is there any reason not to do the same for 'encrypt passwords' in Samba 3.0? I would propose an 'encrypt passwords = auto' that behaves like the pseudocode below: if (exists $(smb passwd file) || has_valid_pdb_backend() || $security == domain) encrypt passwords = yes else encrypt passwords = no fi Are there disadvantages to such an approach? Cheers, Steve Langasek postmodern programmer msg01916/pgp0.pgp Description: PGP signature
Re: [Draft #2] Samba 3.0 roadmap...idmap storage central idmaprepository
On Tue, 2002-07-09 at 21:32, Michael Sweet wrote: Simo Sorce wrote: Hi metze, on top of the first doc I see you state that all strings should be utf8. I hearteadly disagree, I woul d rather like to see all internal strings on new code to be UCS-2. Utf8 has many disadvantages: 1. require any RPC requests that comes from clients to be converted forth and back (UCS-2-UTF8-UCS-2) Some conversion will always be required, not only for byte order issues (remember that UCS-2 strings can contain byte-order overrides) but for normalization forms that may be required. That will be already in place anyway for non-little endian machines so no overhead there. Also, some SMB clients are using UTF-16 now (superset of UCS-2 to support code points in other Unicode planes) instead of UCS-2. which clients? Finally, most UNIX filesystems only support the UTF-8 representation of Unicode, so at some point UCS-2/UTF-16 will have to be converted to UTF-8 anyways... yep, that will be in the new VFS with NTFS semantics interface, not all over the code. 2. Is difficult to manipulate UTF8 strings as they are variable lenght multibyte chars and sometimes uppercase chars have different lenght than lowercase chars. ... ah not mentioning char and string searches inside a string. UCS-2 can have different byte orders, and with UTF-16 you also need to keep track of the current plane as well, which makes life even more fun. not in CIFS world currently, we are forced to be little endian in practice. never seen any smb client that use UTF-16. However manipulation of UCS2 strings (null-word terminated) is way more easy and fast than manipulation of UTF strings, so I really think that it is the way to go. In addition, no matter what Unicode representation is used, you still have to deal with different representations of the same character (is it a single character a with an umlat, or a plus a combining umlat character?, etc.) If for that problem it does not matter which rep to use, than better go with the one that ease programming (and easily avoid lots of errors, specially in inside-string character or string search and uppercasing/lowercasing). Simo. -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
Re: [Draft #2] Samba 3.0 roadmap...idmap storage central idmaprepository
Simo Sorce wrote: ... Also, some SMB clients are using UTF-16 now (superset of UCS-2 to support code points in other Unicode planes) instead of UCS-2. which clients? IIRC, MacOS X and Windows XP clients use UTF-16, although unless you are a Chinese user you will never notice. ... In addition, no matter what Unicode representation is used, you still have to deal with different representations of the same character (is it a single character a with an umlat, or a plus a combining umlat character?, etc.) If for that problem it does not matter which rep to use, than better go with the one that ease programming (and easily avoid lots of errors, specially in inside-string character or string search and uppercasing/lowercasing). The issue is more that clients are free to provide whichever representation they want, and you may need to convert this to any of 4 normalization forms required by your local OS in order to do the proper comparisons. To make life even more interesting, case comparisons are a locale-dependent solution. That is, A with an umlat may not compare equal to a with an umlat in some locales (or shouldn't, anyways). -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
Re: advice for quick hack on _old_ code?
Thanks for your response Kevin . It came just as I was leaving for a
much needed vacation. I hope you are still willing to take a look at
this.
I have done a packet capture. That's how I was able to get as far as I
have. The following is an example of one group-names request and one NT
response that my sources treat as an error.
sent smb request.
tcp .. ff 53 4d 42 25 00
00 00 00 18 03 80 00 00 00 00 00 00 00 00 00 00
41 43 00 08 87 00 00 08 fb 00 10 00 00 d8 00 00
00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 54
00 d8 00 54 00 02 00 26 00 00 08 e9 00 00 5c 00
50 00 49 00 50 00 45 00 5c 00 00 00 00 00 05 00
00 03 10 00 00 00 d8 00 00 00 06 00 00 00 c0 00
00 00 00 00 12 00 00 00 00 00 5a 40 71 c7 7d 85
d6 11 81 62 d2 88 9b 52 df 61 27 00 00 00 e8 03
00 00 00 00 00 00 27 00 00 00 01 02 00 00 ee 03
00 00 ed 03 00 00 fc 03 00 00 f4 03 00 00 f5 03
00 00 f6 03 00 00 f7 03 00 00 f8 03 00 00 f9 03
00 00 fa 03 00 00 fb 03 00 00 fd 03 00 00 fe 03
00 00 ff 03 00 00 00 04 00 00 01 04 00 00 02 04
00 00 03 04 00 00 04 04 00 00 05 04 00 00 24 04
00 00 23 04 00 00 11 04 00 00 12 04 00 00 13 04
00 00 14 04 00 00 15 04 00 00 16 04 00 00 17 04
00 00 18 04 00 00 1b 04 00 00 1c 04 00 00 1d 04
00 00 1e 04 00 00 1f 04 00 00 20 04 00 00 21 04
00 00 22 04 00 00
The help from ethereal and from looking at the code this is my
interpretation of the sent packet.
sent packet as recorded by ethereal
{
uchar msg_type == 0xff;
uchar server_comp[3] == {SMB}; //0x534d42
uchar command== 0x25; //smb trans
uchar error_class== 0x00; //success
uchar reserved == 0x00;
ushort error_code == 0x; //none
uchar flags == 0x18;
ushort flags2 == 0x8003;
uchar reserved[12] == 0x4143; //AC ?
ushort TID== 0x0008; //2048 (0800)
ushort PID== 0x8700; //135 (0087)
ushort UID== 0x0008; //2048 (0800)
ushort MID== 0xfb00; //251 (00fb)
uchar word_count == 0x10; //16
ushort total_parm_cnt == 0x;
ushort total_data_cnt == 0xd800; //216 (00d8)
ushort max_parm_count == 0x;
ushort max_data_count == 0x0004; //1024 (0400)
uchar max_setup_cnt == 0x00;
uchar reverved1 == 0x00;
ushare Flags == 0x;
uint timeout== 0x;
ushort reverved2 == 0x;
ushort parm_count == 0x;
ushort parm_offset== 0x5400; //84 (0054)
ushort data_count == 0xd800; //216 (00d8)
ushort data_offset== 0x5400; //84 (0054)
uchar setup_count== 0x02;
uchar reserved3 == 0x00;
ushort setup1 == 0x2600; //38 (0026)
ushort setup2 == 0x0008; //2048 (0800)
ushort byte_count == 0xe900; //233 (00e9)
uchar trans_name[14] == 0x5c0050004900500045005c00 // {\.P.I.P.E.\...}
ushort unnamed== 0x; // padding? ethereal ignores this
data
{
generic transaction header
{
??? == 05 00 00 03 10 00 00 00
uDataByte == d8 00 00 00 //216
(00d8) uDataByte == (0x3C + dwGroups * 4)
uSequence == 06 00 00 00 //6
(0006) ???
??? == c0 00 00 00 //192
(00c0) ??? == (uDataByte - 0x18)
??? == 00 00
byCommand == 12 //18
#define GET_GROUP_NAMES 0x12
};
??? == 00 00 00 00 00
uchar UID[16] == 5a 40 71 c7 7d 85 d6 11 81 62 d2 88 9b 52 df 61 // I don't
understand this.
dwGroups== 27 00 00 00 //39
(0027) number of group id's
command == e8 03 00 00 00 00 00 00
//GetGroupNames command.
dwGroups== 27 00 00 00 // why do this
again?
gids[dwGroups] ==
{
01 02 00 00
ee 03 00 00
ed 03 00 00
fc 03 00 00
f4 03 00 00
f5 03 00 00
f6 03 00 00
f7 03 00 00
f8 03 00 00
f9 03 00 00
fa 03 00 00
fb 03 00 00
fd 03 00 00
fe 03 00 00
ff 03 00 00
00 04 00 00
01 04 00 00
02 04 00 00
03 04 00 00
04 04 00 00
05 04 00 00
24 04 00 00
23 04 00 00
11 04 00 00
12 04 00 00
13 04 00 00
14 04 00 00
15 04 00 00
16 04 00 00
17 04 00 00
18 04 00 00
1b 04 00 00
1c 04 00 00
1d 04 00 00
1e 04 00 00
1f 04 00 00
20 04 00 00
21 04 00 00
22 04 00 00
};
};
};
And this is the packet that is returned that the library I'm working
with can't handle.
ff 53 4d 42 25 05 ÿSMB%.
00 00 80 98 03
Re: ERROR: in 'security=domain' mode the 'encrypt passwords' parameter must also be set to 'true'
On Tue, Jul 09, 2002 at 03:57:02PM -0400, David Collier-Brown wrote: Steve Langasek wrote: Playing with my smb.conf on a new server (2.2.5), I noticed that the 'security=domain' and 'encrypt passwords=yes' parameters are somewhat redundant. I owe the team a set of self-check code for options that can contradict each other... I just finished some book stuff last week, so maybe Real Soon Now (;-)) Ah, cool. :) One other thing I noticed while digging around was the current description of 'preferred master': This boolean parameter controls if nmbd(8)is a pre ferred master browser for its workgroup. If this is set to true, on startup, nmbd will force an election, and it will have a slight advantage in winning the election. It is recommended that this parameter is used in conjunction with domain mas ter = yes, so that nmbd can guarantee becoming a domain master. Use this option with caution, because if there are several hosts (whether Samba servers, Windows 95 or NT) that are preferred master browsers on the same subnet, they will each periodically and continu ously attempt to become the local master browser. This will result in unnecessary broadcast traffic and reduced browsing capabilities. See also os level . Default: preferred master = auto A glance at the source confirms my suspicion that 'preferred master = auto' depends on the value of 'domain master', but this doesn't make any sense to me: 'preferred master' affects LMB elections, whereas 'domain master' is used to make the server the DMB (PDC) for the workgroup (domain). Aren't local master browsers and domain master browsers orthogonal? This has always been my understanding -- and indeed, I've been running a network with a non-LMB PDC for quite some time, with no adverse effects that I was aware of! Is it time for me to change this? Steve Langasek postmodern programmer msg01923/pgp0.pgp Description: PGP signature
Re: [Draft #2] Samba 3.0 roadmap...idmap storage central idmap repository
On Tue, Jul 09, 2002 at 03:32:50PM -0400, Michael Sweet wrote: In addition, no matter what Unicode representation is used, you still have to deal with different representations of the same character (is it a single character a with an umlat, or a plus a combining umlat character?, etc.) Only Apple does this to my knowledge. Microsoft does not use compose characters in their UCS2 on the wire. I'm voting with MS on this one :-). But Simo, I disagree about the internal rep. I think it needs to be utf8 for Samba internal strings. We already have to deal with mbcs issues - this doesn't make it any worse. Jeremy.
Re: [Draft #2] Samba 3.0 roadmap...idmap storage central idmaprepository
On Tue, 2002-07-09 at 22:14, Michael Sweet wrote: To make life even more interesting, case comparisons are a locale-dependent solution. That is, A with an umlat may not compare equal to a with an umlat in some locales (or shouldn't, anyways). This is not a problem of mine. Conversion routines should take care of correctly mapping characters, after that we have only byte/word comparisons. With UCS2 of course, instead with utf8 it may get complicated, that's why I want to avoid encodings that doesn't have fixed length characters inside samba code when not necessary (eg. utf8 in vfs to write filenames in the filesystem) Simo. -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
Re: [Draft #2] Samba 3.0 roadmap...idmap storage central idmaprepository
On Tue, 2002-07-09 at 22:59, Jeremy Allison wrote: But Simo, I disagree about the internal rep. I think it needs to be utf8 for Samba internal strings. We already have to deal with mbcs issues - this doesn't make it any worse. Have you thought how difficult is to effectively use utf8 strings? search/replace/uppercase/lowercase? it is very difficult to manipulate correctly utf8 strings without introducing errors. I already experimented working with ucs2 null terminated strings and it is way more easy and less prone to errors. a character is always 2 bytes long and a byte codification doesn't change meaning based on which place do it takes inside a string. And substituting/manipulating characters in a string do not change the string length with ucs2! Can you instead tell me what are benefits of using utf8? -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
Re: [Draft #2] Samba 3.0 roadmap...idmap storage central idmaprepository
- Original Message - From: Simo Sorce [EMAIL PROTECTED] To: Stefan (metze) Metzmacher [EMAIL PROTECTED] Cc: Samba Technical [EMAIL PROTECTED] Hi metze, on top of the first doc I see you state that all strings should be utf8. I hearteadly disagree, I woul d rather like to see all internal strings on new code to be UCS-2. Utf8 has many disadvantages: 1. require any RPC requests that comes from clients to be converted forth and back (UCS-2-UTF8-UCS-2) 2. Is difficult to manipulate UTF8 strings as they are variable lenght multibyte chars and sometimes uppercase chars have different lenght than lowercase chars. With UCS-2 the usage of DEBUG() and other string functions might be a lot more difficult than with UTF8 as it would require to use smb_ucs2_t instead of char*. The two documents metze refers to, are realy only work in progress drafts of the new sam interface that is planed, although we are close to the point where we can start implementing :-). I included the statements at the top to remind us that these points still need to be discussed and later on if a descision was made, need to be included in the interface. The decision about character encoding is very important and should be agreed upon by all samba members so that it can be used in all future interfaces. The second point (where should access checks be done) again was only a reminder. In discussions on #samba-technical there was more or less a consens, that it is safer to have the access check in the sam functions rather than in the callers. This way access checks can not be forgotten and there will be consistancy across all functions that will use the interface. To acompany this change, the second document (SAM-interce_handles.txt) was written, which is a successor (or alternative) to the first interface spec. Kai
RE: [Draft #2] Samba 3.0 roadmap...idmap storage central idmaprepository
On Tue, 9 Jul 2002, Stefan (metze) Metzmacher wrote: HI Andrew, Andrew Bartlett,Kai Krueger,Jelmer(ctrlsoft)Vernooij and me are designing a new SAM interface and new a SID mapping System (SMS). We discussed it on irc.openprojects.net #samba-technical. Take a look at http://www.kruegernetz.de/SAM-interface.htm and http://www.kruegernetz.de/SAM-interface_handles.txt Would be useful to have a short description for the routines :-) For example, what does: NTSTATUS sam_get_sec_obj(DOM_SID *sid, SEC_DESC **sd) do? Well, actually, it is obvious that it gets a SEC_DESC given a SID, but why would you ask the SAM for such a thing? Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [Draft #2] Samba 3.0 roadmap...idmap storage centralidmaprepository
Simo Sorce wrote: On Wed, 2002-07-10 at 01:08, Kai Krueger wrote: - Original Message - From: Simo Sorce [EMAIL PROTECTED] To: Stefan (metze) Metzmacher [EMAIL PROTECTED] Cc: Samba Technical [EMAIL PROTECTED] Hi metze, on top of the first doc I see you state that all strings should be utf8. I hearteadly disagree, I woul d rather like to see all internal strings on new code to be UCS-2. Utf8 has many disadvantages: 1. require any RPC requests that comes from clients to be converted forth and back (UCS-2-UTF8-UCS-2) 2. Is difficult to manipulate UTF8 strings as they are variable lenght multibyte chars and sometimes uppercase chars have different lenght than lowercase chars. With UCS-2 the usage of DEBUG() and other string functions might be a lot more difficult than with UTF8 as it would require to use smb_ucs2_t instead of char*. It is not really a problem, we only have to build up a DEBUG function that converts to ascii before printing (and we should do the same with utf8 too afaik), debug statement performance is not so important imho. I'm a little worried on that one - we have a lot of debug statements. The decision about character encoding is very important and should be agreed upon by all samba members so that it can be used in all future interfaces. I agree, I hope also tridge may contribute to the discussion, as I had many talks with him about this issue in the past and we agreed that using ucs2 internally was the best compromise. The second point (where should access checks be done) again was only a reminder. In discussions on #samba-technical there was more or less a consens, that it is safer to have the access check in the sam functions rather than in the callers. I tend to agree, but are we sure we always have a valid NT_USER_TOKEN when we need to access the sam? I'm thinking of accounts administration, migration, backup, and so on. NT has the 'system' user - which is basicly the ACL trump card. I was intending that pdbedit and the auth subsystem would use that context. This way access checks can not be forgotten and there will be consistancy across all functions that will use the interface. To acompany this change, the second document (SAM-interce_handles.txt) was written, which is a successor (or alternative) to the first interface spec. This document seem good, but I would really prefer to smb_ucs2_t types in it :) We will see... Andrew, -- 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
