IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
would always file_free(fsp) twice, once in close_file and once afterwoulds.
The bug was reported in SAMBA_2_2, but a code inspection shows it to be in HEAD
as well. (Unfortunetly I don't have the facilites to actualy check this, but
the change is quite simple, makes sence and compiles).
Andrew Bartlett
hi jeremy,
can you commit the following patch against HEAD. I can't do it right now
Thanks Tim for me. He changed the SAM_DISPINFO_1 array without checking if
he didn't break the server code. And he did.
So on my way I cleaned info_1, 2, .. 5
it may break winbind. I leave to tim the pleasure to fix it ;-)
jf.
I added some talloc changes and checks for alloc fails.
Jeremy.
server manager first. Just use the -U parameter to smbpasswd when joining
the domain:
smbpasswd -r PDC -j DOMAIN -U administrator%password
Should also work with domain users with the 'add workstation to domain'
user right.
people are reporting regarding multiple responses to queries on <1D> names.
There should only ever be one LMB but some users are seeing multiple replies
to queries for the LMB name. This is probably due to nodes on the LAN that
have NetBIOS over NetBEUI and/or IPX enabled. Previously, the debug message
did not include the IP address associated with the name. It *did* include
the source address of the packet, but in the examples I've seen all of these
were the same, eg:
[2000/06/22 11:58:25, 0] nmbd/nmbd_namequery.c:query_name_response(93)
query_name_response: Multiple (2) responses received for a query on subnet
129.130.10.136 for name NT.CIS.KSU.EDU<1d>. This response was from IP
129.130.10.24
[2000/06/22 11:58:25, 0] nmbd/nmbd_namequery.c:query_name_response(93)
query_name_response: Multiple (3) responses received for a query on subnet
129.130.10.136 for name NT.CIS.KSU.EDU<1d>. This response was from IP
129.130.10.24
[2000/06/22 11:58:25, 0] nmbd/nmbd_namequery.c:query_name_response(93)
query_name_response: Multiple (4) responses received for a query on subnet
129.130.10.136 for name NT.CIS.KSU.EDU<1d>. This response was from IP
129.130.10.24
[2000/06/22 11:58:25, 0] nmbd/nmbd_namequery.c:query_name_response(93)
query_name_response: Multiple (5) responses received for a query on subnet
129.130.10.136 for name NT.CIS.KSU.EDU<1d>. This response was from IP
129.130.10.24
Note that all of the above are reported as having come from 129.130.10.24.
This should never happen. If 129.130.10.24 is a WINS server it should
send a Negative Name Query Response for a <1D> name query (wierd but true).
So, are all of the above coming from different systems, all of which
think are the LMB? Are they all coming from one system that is, for some
strange reason, replying five times to the same query?
Anyway, I needed more info so I've changed the debug messages.
Chris -)-----
This is so I can find out what platforms it fails on. I will pull it again tomorrow if there are too many problems, like > 2 platforms that it fails to build on, but will pop it back in again as I resolve platforms.
malloc() to talloc(). Previously, creating an ACL containing zero ACEs
would return a non-NULL pointer to zero bytes of memory. The talloc() code
would return a NULL pointer making the ACL a NULL ACL instead of an empty
one. The difference is a NULL ACL allows all access and an empty ACL
denies all access.
We solve this by calling talloc(ctx, sizeof(SEC_ACE) * num_aces + 1).
Heh.
