-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Our (revised) funnel now works fairly closely to the TNG model, in
which a domain socket is opened to the RPC server and the security
context is passed as a preamble to the first RPC PDU. (Of course,
our security context token probably doesn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yes, I've heard that this is the case. The point I was trying to make
for the sake of argument is that one can treat SMB as transport as one
would TCP/IP.
Ok. I was only trying to find out what you can do without port
135. BTW, Ethereal does not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I've never done anything in configure.in. What about the following?
Index: configure.in
===
RCS file: /kunden/vl/cvs/samba/source/configure.in,v
retrieving revision 1.300.2.25
diff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Could this possibly fix our problems with joining a domain from W2kSP3
without
an explicit realm set?
It should...
Sorry, doesn't really.
Volker
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Key-ID D32186CF,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Make smbpasswd use the group mapping, and fix spelling in ldapsam.
Ouch... Thanks!
Did I say I did compile this?
Volker
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Key-ID D32186CF, Fingerprint available: phone +49 551
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If you could get around the EULA, then you could package preinitialized
drivers and write the information to smbd's tdbs. We have support for
storing driver initialization data already.
Have you heard that you can get CUPS printer drivers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've merged the things I could reasonably be blamed for, plus volker's
passdb changes.
Thanks for that! I'm currently *very* busy with courses etc, so I
don't really have time to work on Samba.
Volker
-BEGIN PGP SIGNATURE-
Version: GnuPG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Clients commonly ignore oplock breaks because of network
problems (borderline hubs etc.). Many people are suffering
from network hardware that performs adequately in light
use situations and fails under heavy load. I myself have
ended up junking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Here I'm currently playing around with W2k joins to samba-head of
yesterday. I have the following phenomena:
Join with 'use spnego = yes' works. For W2ksp3 you have to explicitly
set a realm. But then you obviously put the Workstation into
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It would be nice to update the samba.schema only once, so we should
now also add the account policy values, etc ... to sambaDomainInfo
(all stuff we'll later use for the SAM system) Also add sambaGroup
now, would be nice.(with the stuff we'll
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi again!
This patch puts a RID allocator into the passdb backend. The outside interface
are two calls.
I forgot one thing:
This patch does not yet handle the case where we already have a
sambaDomainInfo entry, but no rid attribute. I do not know
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yes, we need a simple solution, but I'm not sure there is one...
Seeing all these Problems I am now not sure if removing all the
dependencies on algorithmic mapping is a good idea. I'm currently
looking at the code from a different perspective: All
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- Also, I wanted to be sure we always got correct uid-sid and sid-uid
mapping for the guest user. I wanted an NT ACL to be able to include
this 'well known' user, and have it behave as expected. While *most*
cases inside Samba now use just the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I know why 'only algorithmic' mapping is a pain - we can't do migration
from NT, but why is adding algorithmic RIDs a problem here? (Other than
asthetics)
I do not really like the idea of mixing two approaches. Ok, you can
make reasonably sure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Discussion moved to samba-technical.
Instead of just doing a pdb_getsampwnam() on the name from pass struct,
I would prefer that we instead change the callers. Most of the callers
can be changed to do the pdb_getsampwnam() instead of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I do have one question, though. If a samba PDC has multiple interfaces, would
you want the PDC role registered with the PDC's ip on each interface? I
think that would be accomplished if your insert_permanent_name_into_unicast
were moved
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OK, the really nasty bit about this is the implict mapping of existing
unix accounts to rids. I went to a lot of effor to try and get rid of
it - but the best I could do was hide it under a pile of interfaces and
pretend it wasn't there ;-)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
pdb_smbpasswd and pdb_unixsam both use the code in passdb.c
(pdb_fill_sam_pw()) to construct their SAM_ACCOUNT, and to do uid-sid
mapping. In fact, becouse of this, smbpasswd already uses the gid code
to determine the primary group RID on the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
This is a surprisingly little (compiled, but not tested) patch that
mainly should do the following:
Implement a rid allocator in secrets.tdb. This might not be the right
place to do it, but as we are one-domain with passdb, RID allocation
is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As you work into this area, you will see why we decided on the 'start
over'...
My concern is that we will not be able to finish that work in any
reasonable time frame. I would like to see 3.0 released. I completely
agree that a redesign is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If you change the server name of a PDC, Samba generates a new machine SID
because of an incorrect test in pdb_generate_sam_sid.
I stumbled across that one as well. Jerry had some reason for it,
which I don't remember.
Secondly, it would be nice
Hi!
What do you think about the following patch? More consistent would be
to remove the group_sid from SAM_ACCOUNT completely, as we can always
get this from /etc/passwd.
Volker
Index: pdb_get_set.c
===
RCS file:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As you requested:
Sorry to bother you again, but would a tcpdump be possible:
tcpdump -i eth0 -n -s 1600 -w pdc.out host 172.21.63.142.
The logfile is quite weird. First you can connect:
[2002/08/29 15:11:42, 3, pid=12863]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I was wrong. When setting a drop rule it just gets stuck. And after
removing the drop rule, smbd does not recover. The smbd panic occurs
when the domain controller is rebooted. In this case smbd does not
recover, too.
Today I added a route
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
btw...i setup a Samba PDC using LDAP by copying the secrets.tdb file and
the setting the domain SID (using smbpasswd). Worked fine. Did not need
to reent the ldap admin pw again.
Yes, worked for me as well.
Volker
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
btw...i setup a Samba PDC using LDAP by copying the secrets.tdb file and
the setting the domain SID (using smbpasswd). Worked fine. Did not need
to reent the ldap admin pw again.
Yes, worked for me as well.
Volker
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I just added a -S switch to smbpasswd in SAMBA_2_2 to suck the sid
from a DC. My tests show up ok. Can you test this? I'll update
the man page shortly.
For me it worked well, thanks! I'm using it in about an hour in my
Linuxtag talk ;-)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I just added a -S switch to smbpasswd in SAMBA_2_2 to suck the sid
from a DC. My tests show up ok. Can you test this? I'll update
the man page shortly.
For me it worked well, thanks! I'm using it in about an hour in my
Linuxtag talk ;-)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Someone came to me with the following log message. To me it looks like
a corrupt tdb. The system is running Linux 2.2.19 with adaptec RAID
(dpt_io driver), LVM and the tdb's on ext2. The rest of the file
system is reiser. Samba is 2.2.3a. I
29 matches
Mail list logo
