Re: net/xrdp: Issue(s) with Channels/Clipboard.

2019-05-08 Thread Janky Jay, III
Hello Koichiro,

    Is there any update to this? I've since upgraded both systems to
FBSD 12.0-RELEASE-p3 and there have also been (I think) two (2) xrdp
port/pkg updates as well but the problem still remains the same.
Connections to chansrv work 100% of the time on one system and 0% of the
time on the other.

    Also, can you please provide a link to the GH post/report that you
created? I'd like to take a look and follow that as well if I can.
Thanks again!

Regards,
Janky Jay, III

On 2019-02-17 12:23, Janky Jay, III wrote:
> Hello Meta,
>
> On 2/16/19 6:37 PM, Koichiro Iwao wrote:
>> On Fri, Feb 15, 2019 at 11:31:36AM -0700, Janky Jay, III wrote:
>>> This also causes the connection to take 16 seconds to open XFCE4 once
>>> it finally gives up on channels. I see 4 errors so I'm guessing there's
>>> a 4 second timeout between attempts. Something similar to the
>>> issue/recommendation reported at
>>> https://github.com/neutrinolabs/xrdp/issues/1288. I've tried the
>>> recommended disallowing of channels to see if it would connect faster
>>> but it does nothing. Still attempts the connections to "chansrv" and
>>> takes 16 seconds.
>> I don't think that is recommended in the upstream issue. Just he reporter
>> tried as workaround. Who recommended? As commented in the ticket, disabling
>> all channels don't stop connecting to chansrv. That's why *not to
>> connect when all channels disabled* feature is suggedted.
>>  
>     I should have worded that differently. I suppose "recommended" was
> incorrect. It was just a thought to see whether or not
> disable/re-enabling might give me more insight into what was happening
> via the logs (I tried adding the DEBUG log line to sesman.ini as well
> but there was no relevant information).
>
>> I know some people have the same issue and already recoeded to upstream
>> GH issue. Hang tight. If I need to know more detail of reproduction,
>> I might ask you help.
>>
>> I also reproduce the issue but not 100%.
>>
>     Sounds good! I can reproduce 100% of the time on one system right
> now so if there is anything I can do to help, I will certainly do that.
> Thank you!
>
> Regards,
> Janky Jay, III
>
>


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Samba dump (useless) core

2019-05-08 Thread Andrea Venturoli via freebsd-ports

On 5/8/19 2:46 PM, Hans Petter Selasky wrote:

On 2019-05-08 13:44, Jan Beich wrote:

Andrea Venturoli  writes:



Try to install GDB from ports and use that. It often helps.


Right!!! Thanks!!!

I always install installing it when I develop, but forgot to think about 
it in this sysadmin-side problem :)


At least now the trace has some info:

(gdb) bt
#0  0x000803e0d98a in kill () from /lib/libc.so.7
#1  0x000803e0d940 in __fail (msg=) at 
/usr/src/lib/libc/secure/stack_protector.c:110
#2  0x000803e0d8b0 in __stack_chk_fail () at 
/usr/src/lib/libc/secure/stack_protector.c:117
#3  0x000801f274e3 in E_deshash (passwd=, p16=0x80e8b1530 
"?I\246k\316@\323-\366b\017\300\277P\227L0\324~.\b") at 
../libcli/auth/smbencrypt.c:153
#4  0x00081a6a5f17 in setup_given_passwords (io=0x7fffd940, 
g=0x7fffd980) at ../source4/dsdb/samdb/ldb_modules/password_hash.c:2379
#5  0x00081a6a314c in setup_password_fields (io=0x7fffd940) at 
../source4/dsdb/samdb/ldb_modules/password_hash.c:2414
#6  0x00081a6a1cdd in password_hash_mod_do_mod (ac=) at 
../source4/dsdb/samdb/ldb_modules/password_hash.c:4532
#7  get_domain_data_callback (req=, ares=) at 
../source4/dsdb/samdb/ldb_modules/password_hash.c:3920
#8  0x00081d54457e in ltdb_callback (ev=, te=, 
t=..., private_data=) at ../lib/ldb/ldb_tdb/ldb_tdb.c:1654
#9  0x000803b1bbce in tevent_common_invoke_timer_handler () from 
/usr/local/lib/libtevent.so.0
#10 0x000803b1bd06 in tevent_common_loop_timer_delay () from 
/usr/local/lib/libtevent.so.0
#11 0x000803b1923f in ?? () from /usr/local/lib/libtevent.so.0
#12 0x000803b15ead in _tevent_loop_once () from 
/usr/local/lib/libtevent.so.0
#13 0x0008093b509b in ldb_wait (handle=0x823cea820, type=) 
at ../lib/ldb/common/ldb.c:639
#14 0x0008095d3c0f in dsdb_autotransaction_request (sam_ldb=0x80e85e1a0, 
req=0x823dc7de0) at ../source4/dsdb/common/util.c:1120
#15 samdb_set_password_internal (ldb=, mem_ctx=, user_dn=, domain_dn=, new_password=, lmNewHash=, ntNewHash=, 
lmOldHash=, ntOldHash=, reject_reason=, _dominfo=, permit_interdomain_trust=) at ../source4/dsdb/common/util.c:2340
#16 0x0008095d498d in samdb_set_password_sid (ldb=0x80e85e1a0, mem_ctx=, user_sid=, new_version=0xe8ef0607fff, new_password=0x7fffdec0, lmNewHash=0x0, ntNewHash=0x0, lmOldHash=0x0, 
ntOldHash=0x80e8b23a0, reject_reason=0x0, _dominfo=0x0) at ../source4/dsdb/common/util.c:2817

#17 0x000816d7eacd in dcesrv_netr_ServerPasswordSet2 (dce_call=, 
mem_ctx=, r=) at 
../source4/rpc_server/netlogon/dcerpc_netlogon.c:821
#18 netlogon__op_dispatch (dce_call=0x823f62260, mem_ctx=0x823f62260, 
r=0x823cea6e0) at default/librpc/gen_ndr/ndr_netlogon_s.c:399
#19 0x000816d78241 in dcesrv_request (call=) at 
../source4/rpc_server/dcerpc_server.c:1874
#20 dcesrv_process_ncacn_packet (dce_conn=, pkt=, 
blob=...) at ../source4/rpc_server/dcerpc_server.c:2196
#21 dcesrv_read_fragment_done (subreq=) at 
../source4/rpc_server/dcerpc_server.c:2774
#22 0x00080682117a in dcerpc_read_ncacn_packet_done (subreq=) at ../librpc/rpc/dcerpc_util.c:835
#23 0x000806600619 in tstream_readv_pdu_readv_done (subreq=0x823ca6c80) at 
../lib/tsocket/tsocket_helpers.c:319
#24 0x0008065ff7ce in tstream_readv_done (subreq=0x80e846700) at 
../lib/tsocket/tsocket.c:604
#25 0x000803b16fa7 in tevent_common_invoke_immediate_handler () from 
/usr/local/lib/libtevent.so.0
#26 0x000803b17004 in tevent_common_loop_immediate () from 
/usr/local/lib/libtevent.so.0
#27 0x000803b1922c in ?? () from /usr/local/lib/libtevent.so.0
#28 0x000803b15ead in _tevent_loop_once () from 
/usr/local/lib/libtevent.so.0
#29 0x000803b160eb in tevent_common_loop_wait () from 
/usr/local/lib/libtevent.so.0
#30 0x00080ec09aeb in standard_accept_connection (ev=0x80e85e060, lp_ctx=0x80e853060, 
sock=, new_conn=0x8021355f0 , 
private_data=0x80e9db7c0, process_context=0x80e8ce860)
at ../source4/smbd/process_standard.c:384
#31 0x000803b16b6d in tevent_common_invoke_fd_handler () from 
/usr/local/lib/libtevent.so.0
#32 0x000803b1990a in ?? () from /usr/local/lib/libtevent.so.0
#33 0x000803b15ead in _tevent_loop_once () from 
/usr/local/lib/libtevent.so.0
#34 0x000803b160eb in tevent_common_loop_wait () from 
/usr/local/lib/libtevent.so.0
#35 0x00080ec09d51 in standard_new_task (ev=0x80e85e060, lp_ctx=0x80e853060, 
service_name=0x816b4cff6 "rpc", new_task=0x802136200 , 
private_data=0x80e8cea90, service_details=0x80e84ecc0, from_parent_fd=24)
at ../source4/smbd/process_standard.c:494
#36 0x0008021361e2 in task_server_startup (event_ctx=0x80e85e060, lp_ctx=0x80e853060, service_name=0x816b4cff6 "rpc", model_ops=0x80ee0bb90 , task_init=0x816b4cd70 , service_details=0x80e84ecc0, 
from_parent_fd=24) at ../source4/smbd/service_task.c:123

#37 0x000802134c36 in server_service_init (name=0x80e84c950 "rpc", event_context=, lp_ctx=, model_ops=, from_parent_fd=) at 

Re: Samba dump (useless) core

2019-05-08 Thread Hans Petter Selasky

On 2019-05-08 13:44, Jan Beich wrote:

Andrea Venturoli  writes:



Try to install GDB from ports and use that. It often helps.

--HPS

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Samba dump (useless) core

2019-05-08 Thread Jan Beich
Andrea Venturoli  writes:

> While this sheds some light (seems the whole thing has to do with
> trust password change), it shows a stack overflow, not an assert.

"stack overflow detected" messages are part of -fstack-protector*.
Recently, ports/ default changed to -strong in order to follow base/.

https://svnweb.freebsd.org/changeset/ports/499897

> a) how do I get out of this? Remove the other member from the domain
> and rejoin? Try and fix the DB (how)? Other? (I understand this would
> be a question better answere on Samba list, but we are already here).

Try adding either to the port's Makefile:

  SSP_CFLAGS?=  -fstack-protector # XXX -strong crashes in some cases

or

  SSP_UNSAFE=   yes # XXX crashes in some cases

> b) if there's a stack overflow, isn't that a bug? How can I check it
> and report it (to FreeBSD or Samba, once the details can let me
> decide) if I cannot get a proper core?
> I guess I'd have to look into a way to generate debug info with
> Poudriere... what's the proper way to do this?

How debugging is implemented is up to port maintainer but the framework
provides WITH_DEBUG facility that *usually* allows to get debug symbols. 
If neither DEBUG port option nor WITH_DEBUG make variable provide symbols
then file a bug.

https://www.freebsd.org/doc/en/books/porters-handbook/install.html#install-strip

In addition to debug symbols try building with -fsanitize=address in
order to save time finding a place where the overflow occurs.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Samba dump (useless) core

2019-05-08 Thread Andrea Venturoli

On 5/8/19 12:25 PM, Konstantin Belousov wrote:


Signal 6 is SIGABRT, which means most likely that some assert was triggered.
You should look into your logs.


samba.log shows nothing at level 1 (default); at level 3 gives gobs of 
information and I don't look what to look for.


In all.log, however, I have something like this:


May  8 12:48:11  winbindd[83147]: [2019/05/08 12:48:11.493769,  0] 
../source3/libsmb/trusts_util.c:334(trust_pw_change)
May  8 12:48:11  kernel: May  8 12:48:09  last message repeated 4 times
May  8 12:48:11  kernel: May  8 12:48:11  winbindd[83147]: [2019/05/08 
12:48:11.493769,  0] ../source3/libsmb/trusts_util.c:334(trust_pw_change)
May  8 12:48:11  winbindd[83147]:   2019/05/08 12:48:11 : 
trust_pw_change(XX): A password change was already started against 
'dc1.ad.x.it' at Mon Apr 29 12:22:51 2019 CEST. Trying to recover...
May  8 12:48:11  kernel: May  8 12:48:11  winbindd[83147]:   2019/05/08 
12:48:11 : trust_pw_change(XX): A password change was already started against 
'dc1.ad.x.it' at Mon Apr 29 12:22:51 2019 CEST. Trying to recover...
May  8 12:48:11  winbindd[83147]: [2019/05/08 12:48:11.493910,  0] 
../source3/libsmb/trusts_util.c:343(trust_pw_change)
May  8 12:48:11  kernel: May  8 12:48:11  winbindd[83147]: [2019/05/08 
12:48:11.493910,  0] ../source3/libsmb/trusts_util.c:343(trust_pw_change)
May  8 12:48:11  winbindd[83147]:   2019/05/08 12:48:11 : 
trust_pw_change(XX): Last failure local[NT_STATUS_NOT_COMMITTED] 
remote[NT_STATUS_CONNECTION_DISCONNECTED] against 'dc1.ad.x.it' at 
Wed May  8 12:47:11 2019 CEST.
May  8 12:48:11  kernel: May  8 12:48:11  winbindd[83147]:   2019/05/08 
12:48:11 : trust_pw_change(XX): Last failure local[NT_STATUS_NOT_COMMITTED] 
remote[NT_STATUS_CONNECTION_DISCONNECTED] against 'dc1.ad.x.it' at 
Wed
 May  8 12:47:11 2019 CEST.
May  8 12:48:11  winbindd[83147]: [2019/05/08 12:48:11.493986,  0] 
../source3/libsmb/trusts_util.c:380(trust_pw_change)
May  8 12:48:11  kernel: May  8 12:48:11  winbindd[83147]: [2019/05/08 
12:48:11.493986,  0] ../source3/libsmb/trusts_util.c:380(trust_pw_change)
May  8 12:48:11  winbindd[83147]:   2019/05/08 12:48:11 : 
trust_pw_change(XX): Verifying passwords remotely 
netlogon_creds_cli:CLI[FS/FS$]/SRV[DC1/XX].
May  8 12:48:11  kernel: May  8 12:48:11  winbindd[83147]:   2019/05/08 
12:48:11 : trust_pw_change(XX): Verifying passwords remotely 
netlogon_creds_cli:CLI[FS/FS$]/SRV[DC1/XX].
May  8 12:48:11  samba[54713]: stack overflow detected; terminated
May  8 12:48:11  winbindd[83147]: [2019/05/08 12:48:11.496724,  0] 
../source3/libsmb/trusts_util.c:452(trust_pw_change)
May  8 12:48:11  kernel: May  8 12:48:11  samba[54713]: stack overflow 
detected; terminated
May  8 12:48:11  kernel: May  8 12:48:11  winbindd[83147]: [2019/05/08 
12:48:11.496724,  0] ../source3/libsmb/trusts_util.c:452(trust_pw_change)
May  8 12:48:11  winbindd[83147]:   2019/05/08 12:48:11 : 
trust_pw_change(XX): Verified old password remotely using 
netlogon_creds_cli:CLI[FS/FS$]/SRV[DC1/XX]
May  8 12:48:11  kernel: May  8 12:48:11  winbindd[83147]:   2019/05/08 
12:48:11 : trust_pw_change(XX): Verified old password remotely using 
netlogon_creds_cli:CLI[FS/FS$]/SRV[DC1/XX]
May  8 12:48:11  winbindd[83147]: [2019/05/08 12:48:11.496828,  0] 
../source3/libsmb/trusts_util.c:491(trust_pw_change)
May  8 12:48:11  kernel: May  8 12:48:11  winbindd[83147]: [2019/05/08 
12:48:11.496828,  0] ../source3/libsmb/trusts_util.c:491(trust_pw_change)
May  8 12:48:11  winbindd[83147]:   2019/05/08 12:48:11 : 
trust_pw_change(XX): Changed password locally
May  8 12:48:11  kernel: May  8 12:48:11  winbindd[83147]:   2019/05/08 
12:48:11 : trust_pw_change(XX): Changed password locally
May  8 12:48:11  winbindd[83147]: [2019/05/08 12:48:11.636003,  0] 
../source3/libsmb/trusts_util.c:507(trust_pw_change)
May  8 12:48:11  kernel: pid 54713 (samba), uid 0: exited on signal 6 (core 
dumped)
May  8 12:48:11  kernel: May  8 12:48:11  winbindd[83147]: [2019/05/08 
12:48:11.636003,  0] ../source3/libsmb/trusts_util.c:507(trust_pw_change)
May  8 12:48:11  winbindd[83147]:   2019/05/08 12:48:11 : 
trust_pw_change(XX) remote password change with 
netlogon_creds_cli:CLI[FS/FS$]/SRV[DC1/XX] failed - 
NT_STATUS_CONNECTION_DISCONNECTED (disconnected)
May  8 12:48:11  kernel: May  8 12:48:11  winbindd[83147]:   2019/05/08 
12:48:11 : trust_pw_change(XX) remote password change with 
netlogon_creds_cli:CLI[FS/FS$]/SRV[DC1/XX] failed - 
NT_STATUS_CONNECTION_DISCONNECTED (disconnected
)
May  8 12:48:11  samba[80265]: [2019/05/08 12:48:11.639630,  0] 
../source4/smbd/process_standard.c:158(standard_child_pipe_handler)
May  8 12:48:11  kernel: May  8 12:48:11  samba[80265]: [2019/05/08 
12:48:11.639630,  0] 

Re: Samba dump (useless) core

2019-05-08 Thread Konstantin Belousov
On Wed, May 08, 2019 at 12:03:34PM +0200, Andrea Venturoli wrote:
> Hello.
> 
> I've got a few servers where I run Samba 4.8 in a jail as an AD DC.
> 
> Lately, on a couple of them, it started dumping core: on one server, 
> apparently everything works fine after that; on another one I have 
> intermittent DNS issues, but I'm not sure they are related to this core.
> 
> I tried examining the core, but this is what I get:
> 
> > # gdb /usr/local/sbin/samba samba.core
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain 
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "amd64-marcel-freebsd"...
> > Core was generated by `samba: conn[rpc] c[ipv4:192.168.xxx.4:31803] 
> > s[ipv4:192.168.134.3:49153] server_'.
> > Program terminated with signal 6, Aborted.
> > #0  0x000803e0d98a in ?? ()
> > (gdb) info thr
> > * 1 process 101460  0x000803e0d98a in ?? ()
> > (gdb) bt
> > #0  0x000803e0d98a in ?? ()
> > #1  0x000803e0d940 in ?? ()
> > #2  0xffdf in ?? ()
> > #3  0x in ?? ()
> > #4  0x in ?? ()
> > (gdb) 
> 
> The only relevant line, unfortunately is "Core was generated by...", but 
> it doesn't help much.
> 
> Samba is compiled (via Pudriere) with DEBUG, so I thought the above 
> would be more useful.
> 
> Any hint?
Signal 6 is SIGABRT, which means most likely that some assert was triggered.
You should look into your logs.  Also it is possible that DEBUG turns on
asserts.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Samba dump (useless) core

2019-05-08 Thread Andrea Venturoli

Hello.

I've got a few servers where I run Samba 4.8 in a jail as an AD DC.

Lately, on a couple of them, it started dumping core: on one server, 
apparently everything works fine after that; on another one I have 
intermittent DNS issues, but I'm not sure they are related to this core.


I tried examining the core, but this is what I get:


# gdb /usr/local/sbin/samba samba.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `samba: conn[rpc] c[ipv4:192.168.xxx.4:31803] 
s[ipv4:192.168.134.3:49153] server_'.
Program terminated with signal 6, Aborted.
#0  0x000803e0d98a in ?? ()
(gdb) info thr
* 1 process 101460  0x000803e0d98a in ?? ()
(gdb) bt
#0  0x000803e0d98a in ?? ()
#1  0x000803e0d940 in ?? ()
#2  0xffdf in ?? ()
#3  0x in ?? ()
#4  0x in ?? ()
(gdb) 


The only relevant line, unfortunately is "Core was generated by...", but 
it doesn't help much.


Samba is compiled (via Pudriere) with DEBUG, so I thought the above 
would be more useful.


Any hint?

 bye & Thanks
av.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


FreeBSD ports you maintain which are out of date

2019-05-08 Thread portscout
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
devel/lua-luarocks  | 3.0.1   | 3.1.2
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"