Does xrdp compile for Pulseaudio support are both RDPSND channel and pulseaudio used?

I am using Guacamole & its RDP connection capability to connect to linux servers where I've installed XRDP.
Per the Guacamole lead developer:
_Guacamole does not use PulseAudio for grabbing the audio of an RDP connection. It supports PulseAudio for VNC connections because VNC otherwise lacks its own standard support for audio, but with RDP the "RDPSND" channel will be used.
If you wish to use RDP, then the next step would be to determine why your RDP server is not providing audio via RDPSND. Though XRDP may well use PulseAudio behind the scenes, the RDP client (in this case: Guacamole) need not be aware of this; the RDP-facing side of this audio should be standard RDPSND._
I used scarygliders script to build xrdp/x11rdp with audio support (as best I understood the instructions) and on my test servers I have a /etc/xrdp/pulse directory with a /etc/xrdp/pulse/default.pa file.
So I'm puzzled if you have the above /etc/xrdp/sesman.in pointing to the script in /etc/xrdp/pulse/default.pa
Is XRDP still using RDPSND at all?   Does it send audio to both Pulseaudio & RDPSND channel simulaneously?
I tried searching for an answer to this but haven't found any clarity.   my .ini file has channels true & rdpsnd true ?    But I'm wondering if audio is sent via both rdpsnd channel & pulseaudio or only 1 of the two.
thanks
brian

Hi Brian,
Pulse Audio is just the local Linux audio server.
We use pulseaudio in order to get the audio output from Linux server, then
it is all sent over RDP in the rdpsnd virtual channel. (This is a sub
protocol for sending audio output from server to client over RDP)
So, yes xrdp uses the standard rdpsnd channel.
The thing is we only support raw PCM or opus audio encoding for now which
guacamole might not support (even though raw PCM format should be supported
by any RDP client)
Hth,
Idan
בתאריך יום ד׳, 6 ביולי 2016 ב-14:16 מאת bmullan<EMAIL_ADDRESS>
I am using Guacamole & its RDP connection capability to connect to linux
servers where I've installed XRDP.
Per the Guacamole lead developer:
_Guacamole does not use PulseAudio for grabbing the audio of an RDP
connection. It supports PulseAudio for VNC connections because VNC
otherwise lacks its own standard support for audio, but with RDP the
"RDPSND" channel will be used.
If you wish to use RDP, then the next step would be to determine why your
RDP server is not providing audio via RDPSND. Though XRDP may well use
PulseAudio behind the scenes, the RDP client (in this case: Guacamole) need
not be aware of this; the RDP-facing side of this audio should be standard
RDPSND._
I used scarygliders script to build xrdp/x11rdp with audio support (as
best I understood the instructions) and on my test servers I have a
/etc/xrdp/pulse directory with a /etc/xrdp/pulse/default.pa file.
So I'm puzzled if you have the above /etc/xrdp/sesman.in pointing to the
script in /etc/xrdp/pulse/default.pa
Is XRDP still using RDPSND at all? Does it send audio to both Pulseaudio &
RDPSND channel simulaneously?
I tried searching for an answer to this but haven't found any clarity. my
.ini file has channels true & rdpsnd true ? But I'm wondering if audio is
sent via both rdpsnd channel & pulseaudio or only 1 of the two.
thanks
brian
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/neutrinolabs/xrdp/issues/395, or mute the thread
https://github.com/notifications/unsubscribe/ADTH1IytA1wPNNGrRMk-IDoFPkzBtsiRks5qS459gaJpZM4JF-0g
.

Idan,
In regards to xrdp's use of pulseaudio, should xrdp handle the pulseaudio the same whether pulseaudio is setup in its normal "per user" mode or in pulseaudio's "system mode".
And yes, I know the upstream Pulseaudio discourages use of "system mode" for a variety of reasons however in my "use-case" all of the pulseaudio & xrdp is within a single Ubuntu 16.04 server in which I have multiple LXD/LXC containers.   Each container is running Ubuntu also with Ubuntu-Mate Desktop Environment installed.
Each container is accessed via Guacamole's RDP to xrdp/x11rdp running in that container to get the Ubuntu-Mate desktop presented to the user.
If I implement Pulseaudio in the "host/server" in it's "per-user" mode sound/audio works from the container's OK (except there is 1 problem to work around which causes audio/sound to stop.).
My attempt to workaround this problem was to try configuring Pulseaudio in the Host/Server in its "system wide" mode so that Pulseaudio is loaded and available via Pulseaudio TCP from the containers even if no one is logged into the Ubuntu-Mate DE itself (re user-mode pulseaudio).
However, I set up the Host/Server for Pulseaudio "system wide" mode and in the Host/Server and in the Containers - PACTL LIST MODULES shows all modules loaded and available.
Running "aplay /usr/share/sounds/alsa/Front_Center.wav" in the host or the Containers shows audio playing properly if monitoring via the Sound program's Input display... the bars move indicating sound/audio.
However, me as the "remote" user via Guacamole hear NO sound/audio.
Guacamole should be relaying the sound/audio to me using the RDPSND channel which XRDP should be filling from Pulseaudio.
As I mentioned earlier...
if Pulseaudio is setup in normal "per user" mode I DO hear audio/sound remotely.
if Pulseaudio is setup in "system wide" mode I DO NOT hear audio/sound remotely.
So it seems to me that XRDP must not be handling Pulseaudio properly & filling the RDPSND channel with the audio.
I am suspecting this "may be" because in Pulseaudio "system wide" mode Pulseaudio uses "/etc/pulse/system.pa"  for configuration and NOT its normal "/etc/pulse/default.pa".
My guess is that this somehow is related to XRDP's own use of "/etc/xrdp/pulse/default.pa".
Anyway I thought I'd ask.
Thanks
Brian

Ok I spent more time with this today and it does seem as though xrdp doesn't continue to capture pulseaudio sound and pass it via the RDPSND channell if pulseaudio is run in "system wide" mode.
I tested this by starting pulseaudio in normal "per user" mode and audio from xrdp does come back to me (the remote user) via guacamole's RDP connection to that server.
audio  is generated on the server using:  aplay /usr/share/sounds/alsa/Front_Center.wav
also...  pavucontrol shows audio on the xrdp sink
Kill pulseaudio (sudo killall pulseaudio) and restart it in system wide mode
sudo su
pulseaudio --system
again generate audio on server using:  aplay /usr/share/sounds/alsa/Front_Center.wav
and again... pavucontrol shows audio on the xrdp sink ... BUT ... no audio/sound is now heard by me remotely via Guacamole's RDP connection !
Since Guacamole doesn't know/care about Pulseaudio in its RDP connections only the RDPSND channel audio I'm thinking xrdp must somehow not be filling the RDPSND channel with that audio any longer even though its SINK shows audio present?
Any ideas what I could try or a log I could try to look at?
A simple way to view what I'm doing would be something similar to a headless RDP terminal server I guess.
thanks
brian

Hi Brian,
I didn't try PA "system wide" mode ever, but there are 2 things to be aware
of:

PA must load our sink (aka module-xrdp-sink.so).
in a normal per-user session we set (xrdp-sesman) the PULSE_SCRIPT env var
in the USER session to point to /etc/xrdp/pulse/default.pa file, which
instructs PA to load our pulse config file instead of the deafult per-user
config /etc/pulse/default.pa when X11rdp session  starts.

when pulseaudio loads our sink, it is relying on the DISPLAY env var in
order to send the audio data to the right xrdp-chansrv socket matching the
current session (aka channel server, which wraps the audio data into the
RDPSND channel and send it back to client).
(you can look at:
https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311
)
The thing is, when you run pulse audio in a system-wide mode (as root), the
DISPLAY env var might be wrong / not set.

I don't think we thought about system-wide scenario, as it make not sense
to use it when you handle multiple different user sessions running on the
same box.
HTH.
בתאריך יום ד׳, 13 ביולי 2016 ב-23:00 מאת bmullan<EMAIL_ADDRESS>
Ok I spent more time with this today and it does seem as though xrdp
doesn't continue to capture pulseaudio sound and pass it via the RDPSND
channell if pulseaudio is run in "system wide" mode.
I tested this by starting pulseaudio in normal "per user" mode and audio
from xrdp does come back to me (the remote user) via guacamole's RDP
connection to that server.
audio is generated on the server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
also... pavucontrol shows audio on the xrdp sink
Kill pulseaudio (sudo killall pulseaudio) and restart it in system wide
mode
sudo su
pulseaudio --system
again generate audio on server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
and again... pavucontrol shows audio on the xrdp sink ... BUT ... no
audio/sound is now heard by me remotely via Guacamole's RDP connection !
Since Guacamole doesn't know/care about Pulseaudio in its RDP connections
only the RDPSND channel audio I'm thinking xrdp must somehow not be filling
the RDPSND channel with that audio any longer even though its SINK shows
audio present?
Any ideas what I could try or a log I could try to look at?
A simple way to view what I'm doing would be something similar to a
headless RDP terminal server I guess.
thanks
brian
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232469459,
or mute the thread
https://github.com/notifications/unsubscribe/ADTH1CGm5RPS0ltrzrJKMESyY3QyrojPks5qVUP4gaJpZM4JF-0g
.

Idan

I understand... and don't take me wrong.   I just thought with
Container's becoming such a "big thing" I'd try to communicate what I was
seeing with LXC
even though its not Docker-style containers...

I didn't try PA "system wide" mode ever, but there are 2 things to be aware
of:

PA must load our sink (aka module-xrdp-sink.so).  in a normal per-user
session we set (xrdp-sesman) the PULSE_SCRIPT env var
in the USER session to point to /etc/xrdp/pulse/default.pa file, which
instructs PA to load our pulse config file instead of the deafult per-user
config /etc/pulse/default.pa when X11rdp session starts.

I tried to overcome that by putting the following into the /etc/pulse/
system.pa file:

load-module module-native-protocol-tcp
auth-ip-acl=<IP_ADDRESS>;IP-of-Containers auth-anonymous=1
load-module module-xrdp-sink

and remember... as I said in my bug report... XRDP's SINK does show up
properly in "pavucontrol" output and DOES show data being passed its just
that
its not being passed to RDPSND from Pulseaudio SINK that says it sees the
data in....?

when pulseaudio loads our sink, it is relying on the DISPLAY env var in
order to send the audio data to the right xrdp-chansrv socket matching the
current session (aka channel server, which wraps the audio data into the
RDPSND channel and send it back to client). (you can look at:
https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311
)
The thing is, when you run pulse audio in a system-wide mode (as root), the
DISPLAY env var might be wrong / not set.

I can check this again?

I don't think we thought about system-wide scenario, as it make not sense
to use it when you handle multiple different user sessions running on the
same box.

again... I think that the whole lot of attention being giving to
"Containers" may mean that Pulseaudio and/or those that use it to help make
Pulseaudio "system mode" work for more headless-type operation....
especially with "cloud".

thanks so much ...
Brian Mullan
Raleigh North Carolina USA.
HTH.
On Wed, Jul 13, 2016 at 7:27 PM, Idan Freiberg<EMAIL_ADDRESS>wrote:

Hi Brian,
I didn't try PA "system wide" mode ever, but there are 2 things to be aware
of:

PA must load our sink (aka module-xrdp-sink.so).
in a normal per-user session we set (xrdp-sesman) the PULSE_SCRIPT env var
in the USER session to point to /etc/xrdp/pulse/default.pa file, which
instructs PA to load our pulse config file instead of the deafult per-user
config /etc/pulse/default.pa when X11rdp session starts.

when pulseaudio loads our sink, it is relying on the DISPLAY env var in
order to send the audio data to the right xrdp-chansrv socket matching the
current session (aka channel server, which wraps the audio data into the
RDPSND channel and send it back to client).
(you can look at:

https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311
)
The thing is, when you run pulse audio in a system-wide mode (as root), the
DISPLAY env var might be wrong / not set.
I don't think we thought about system-wide scenario, as it make not sense
to use it when you handle multiple different user sessions running on the
same box.
HTH.
בתאריך יום ד׳, 13 ביולי 2016 ב-23:00 מאת bmullan<EMAIL_ADDRESS>
:

Ok I spent more time with this today and it does seem as though xrdp
doesn't continue to capture pulseaudio sound and pass it via the RDPSND
channell if pulseaudio is run in "system wide" mode.
I tested this by starting pulseaudio in normal "per user" mode and audio
from xrdp does come back to me (the remote user) via guacamole's RDP
connection to that server.
audio is generated on the server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
also... pavucontrol shows audio on the xrdp sink
Kill pulseaudio (sudo killall pulseaudio) and restart it in system wide
mode
sudo su
pulseaudio --system
again generate audio on server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
and again... pavucontrol shows audio on the xrdp sink ... BUT ... no
audio/sound is now heard by me remotely via Guacamole's RDP connection !
Since Guacamole doesn't know/care about Pulseaudio in its RDP connections
only the RDPSND channel audio I'm thinking xrdp must somehow not be
filling
the RDPSND channel with that audio any longer even though its SINK shows
audio present?
Any ideas what I could try or a log I could try to look at?
A simple way to view what I'm doing would be something similar to a
headless RDP terminal server I guess.
thanks
brian
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232469459
,
or mute the thread
<
https://github.com/notifications/unsubscribe/ADTH1CGm5RPS0ltrzrJKMESyY3QyrojPks5qVUP4gaJpZM4JF-0g

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232516054,
or mute the thread
https://github.com/notifications/unsubscribe/ABmtpyqhCzkd1l6cRmqGFd5AxP6VI1Wvks5qVXRxgaJpZM4JF-0g
.

I see what you're saying regarding containers and its popularity.
I didn't use any of them yet.
Can you help me to understand why you want xrdp running inside a container ?
בתאריך יום ה׳, 14 ביולי 2016 ב-3:16 מאת bmullan<EMAIL_ADDRESS>
Idan

I understand... and don't take me wrong. I just thought with
Container's becoming such a "big thing" I'd try to communicate what I was
seeing with LXC
even though its not Docker-style containers...

I didn't try PA "system wide" mode ever, but there are 2 things to be
aware
of:

PA must load our sink (aka module-xrdp-sink.so). in a normal per-user
session we set (xrdp-sesman) the PULSE_SCRIPT env var
in the USER session to point to /etc/xrdp/pulse/default.pa file, which
instructs PA to load our pulse config file instead of the deafult per-user
config /etc/pulse/default.pa when X11rdp session starts.

I tried to overcome that by putting the following into the /etc/pulse/
system.pa file:

load-module module-native-protocol-tcp
auth-ip-acl=<IP_ADDRESS>;IP-of-Containers auth-anonymous=1
load-module module-xrdp-sink

and remember... as I said in my bug report... XRDP's SINK does show up
properly in "pavucontrol" output and DOES show data being passed its just
that
its not being passed to RDPSND from Pulseaudio SINK that says it sees the
data in....?

when pulseaudio loads our sink, it is relying on the DISPLAY env var in
order to send the audio data to the right xrdp-chansrv socket matching the
current session (aka channel server, which wraps the audio data into the
RDPSND channel and send it back to client). (you can look at:

https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311
)
The thing is, when you run pulse audio in a system-wide mode (as root), the
DISPLAY env var might be wrong / not set.

I can check this again?

I don't think we thought about system-wide scenario, as it make not sense
to use it when you handle multiple different user sessions running on the
same box.

again... I think that the whole lot of attention being giving to
"Containers" may mean that Pulseaudio and/or those that use it to help make
Pulseaudio "system mode" work for more headless-type operation....
especially with "cloud".

thanks so much ...
Brian Mullan
Raleigh North Carolina USA.
HTH.
On Wed, Jul 13, 2016 at 7:27 PM, Idan Freiberg<EMAIL_ADDRESS>wrote:

Hi Brian,
I didn't try PA "system wide" mode ever, but there are 2 things to be
aware
of:

PA must load our sink (aka module-xrdp-sink.so).
in a normal per-user session we set (xrdp-sesman) the PULSE_SCRIPT env
var
in the USER session to point to /etc/xrdp/pulse/default.pa file, which
instructs PA to load our pulse config file instead of the deafult
per-user
config /etc/pulse/default.pa when X11rdp session starts.

when pulseaudio loads our sink, it is relying on the DISPLAY env var
in
order to send the audio data to the right xrdp-chansrv socket matching
the
current session (aka channel server, which wraps the audio data into the
RDPSND channel and send it back to client).
(you can look at:

https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311

)
The thing is, when you run pulse audio in a system-wide mode (as root),
the
DISPLAY env var might be wrong / not set.
I don't think we thought about system-wide scenario, as it make not sense
to use it when you handle multiple different user sessions running on the
same box.
HTH.
בתאריך יום ד׳, 13 ביולי 2016 ב-23:00 מאת bmullan <
<EMAIL_ADDRESS>
:

Ok I spent more time with this today and it does seem as though xrdp
doesn't continue to capture pulseaudio sound and pass it via the RDPSND
channell if pulseaudio is run in "system wide" mode.
I tested this by starting pulseaudio in normal "per user" mode and
audio
from xrdp does come back to me (the remote user) via guacamole's RDP
connection to that server.
audio is generated on the server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
also... pavucontrol shows audio on the xrdp sink
Kill pulseaudio (sudo killall pulseaudio) and restart it in system wide
mode
sudo su
pulseaudio --system
again generate audio on server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
and again... pavucontrol shows audio on the xrdp sink ... BUT ... no
audio/sound is now heard by me remotely via Guacamole's RDP connection
!
Since Guacamole doesn't know/care about Pulseaudio in its RDP
connections
only the RDPSND channel audio I'm thinking xrdp must somehow not be
filling
the RDPSND channel with that audio any longer even though its SINK
shows
audio present?
Any ideas what I could try or a log I could try to look at?
A simple way to view what I'm doing would be something similar to a
headless RDP terminal server I guess.
thanks
brian
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232469459
,
or mute the thread
<

https://github.com/notifications/unsubscribe/ADTH1CGm5RPS0ltrzrJKMESyY3QyrojPks5qVUP4gaJpZM4JF-0g

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232516054
,
or mute the thread
<
https://github.com/notifications/unsubscribe/ABmtpyqhCzkd1l6cRmqGFd5AxP6VI1Wvks5qVXRxgaJpZM4JF-0g
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232523343,
or mute the thread
https://github.com/notifications/unsubscribe/ADTH1EFQ1uBRYbASZGL60Jgh8GjrJPBtks5qVX_UgaJpZM4JF-0g
.

Idan
Its getting late here.   Let me email you my use-case tomorrow.   I do not
think I'm alone in concept.  Thx
I can also share my 6 bash scripts to install everything on an ubuntu 16.04
server if you want to try it all
On Jul 13, 2016 8:42 PM, "Idan Freiberg"<EMAIL_ADDRESS>wrote:

I see what you're saying regarding containers and its popularity.
I didn't use any of them yet.
Can you help me to understand why you want xrdp running inside a container
?
בתאריך יום ה׳, 14 ביולי 2016 ב-3:16 מאת bmullan<EMAIL_ADDRESS>
:

Idan

I understand... and don't take me wrong. I just thought with
Container's becoming such a "big thing" I'd try to communicate what I was
seeing with LXC
even though its not Docker-style containers...

I didn't try PA "system wide" mode ever, but there are 2 things to be
aware
of:

PA must load our sink (aka module-xrdp-sink.so). in a normal per-user
session we set (xrdp-sesman) the PULSE_SCRIPT env var
in the USER session to point to /etc/xrdp/pulse/default.pa file, which
instructs PA to load our pulse config file instead of the deafult
per-user
config /etc/pulse/default.pa when X11rdp session starts.

I tried to overcome that by putting the following into the /etc/pulse/
system.pa file:

load-module module-native-protocol-tcp
auth-ip-acl=<IP_ADDRESS>;IP-of-Containers auth-anonymous=1
load-module module-xrdp-sink

and remember... as I said in my bug report... XRDP's SINK does show up
properly in "pavucontrol" output and DOES show data being passed its just
that
its not being passed to RDPSND from Pulseaudio SINK that says it sees the
data in....?

when pulseaudio loads our sink, it is relying on the DISPLAY env var
in
order to send the audio data to the right xrdp-chansrv socket matching
the
current session (aka channel server, which wraps the audio data into the
RDPSND channel and send it back to client). (you can look at:

https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311

)
The thing is, when you run pulse audio in a system-wide mode (as root),
the
DISPLAY env var might be wrong / not set.

I can check this again?

I don't think we thought about system-wide scenario, as it make not sense
to use it when you handle multiple different user sessions running on the
same box.

again... I think that the whole lot of attention being giving to
"Containers" may mean that Pulseaudio and/or those that use it to help
make
Pulseaudio "system mode" work for more headless-type operation....
especially with "cloud".

thanks so much ...
Brian Mullan
Raleigh North Carolina USA.
HTH.
On Wed, Jul 13, 2016 at 7:27 PM, Idan Freiberg<EMAIL_ADDRESS>wrote:

Hi Brian,
I didn't try PA "system wide" mode ever, but there are 2 things to be
aware
of:

PA must load our sink (aka module-xrdp-sink.so).
in a normal per-user session we set (xrdp-sesman) the PULSE_SCRIPT env
var
in the USER session to point to /etc/xrdp/pulse/default.pa file, which
instructs PA to load our pulse config file instead of the deafult
per-user
config /etc/pulse/default.pa when X11rdp session starts.

when pulseaudio loads our sink, it is relying on the DISPLAY env var
in
order to send the audio data to the right xrdp-chansrv socket matching
the
current session (aka channel server, which wraps the audio data into
the
RDPSND channel and send it back to client).
(you can look at:

https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311

)
The thing is, when you run pulse audio in a system-wide mode (as root),
the
DISPLAY env var might be wrong / not set.
I don't think we thought about system-wide scenario, as it make not
sense
to use it when you handle multiple different user sessions running on
the
same box.
HTH.
בתאריך יום ד׳, 13 ביולי 2016 ב-23:00 מאת bmullan <
<EMAIL_ADDRESS>
:

Ok I spent more time with this today and it does seem as though xrdp
doesn't continue to capture pulseaudio sound and pass it via the
RDPSND
channell if pulseaudio is run in "system wide" mode.
I tested this by starting pulseaudio in normal "per user" mode and
audio
from xrdp does come back to me (the remote user) via guacamole's RDP
connection to that server.
audio is generated on the server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
also... pavucontrol shows audio on the xrdp sink
Kill pulseaudio (sudo killall pulseaudio) and restart it in system
wide
mode
sudo su
pulseaudio --system
again generate audio on server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
and again... pavucontrol shows audio on the xrdp sink ... BUT ... no
audio/sound is now heard by me remotely via Guacamole's RDP
connection
!
Since Guacamole doesn't know/care about Pulseaudio in its RDP
connections
only the RDPSND channel audio I'm thinking xrdp must somehow not be
filling
the RDPSND channel with that audio any longer even though its SINK
shows
audio present?
Any ideas what I could try or a log I could try to look at?
A simple way to view what I'm doing would be something similar to a
headless RDP terminal server I guess.
thanks
brian
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232469459
,
or mute the thread
<

https://github.com/notifications/unsubscribe/ADTH1CGm5RPS0ltrzrJKMESyY3QyrojPks5qVUP4gaJpZM4JF-0g

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232516054
,
or mute the thread
<

https://github.com/notifications/unsubscribe/ABmtpyqhCzkd1l6cRmqGFd5AxP6VI1Wvks5qVXRxgaJpZM4JF-0g

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232523343
,
or mute the thread
<
https://github.com/notifications/unsubscribe/ADTH1EFQ1uBRYbASZGL60Jgh8GjrJPBtks5qVX_UgaJpZM4JF-0g
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232526808,
or mute the thread
https://github.com/notifications/unsubscribe/ABmtpx0tdEljq_37JIUXArjwkuqyZmt4ks5qVYYJgaJpZM4JF-0g
.

Idan..
My concept/setup is to require a remote desktop user to access my cloud
servers (AWS and Digital Ocean) using only a web browser - which is what
Guacamole provides.
Guacamole is an HTML5 web proxy (called "guacd") running on tomcat on a
cloud host/server (re NOT in an LXC container but on the physical host).
Pulseaudio also runs only on the physical host/server ... NOT in the LXC
containers!
The user connects to Guacamole on the host/server then ... via
configuration I've already created selects one of several Desktop
Environments (DE) to log into.
The DE's I've setup are Ubuntu-Mate, LXDE and XFCE and each of them runs in
a separate LXC container on that same Host/Server.
Guacamole's GUACD supports SSH, VNC and RDP.    But only VNC and RDP
support a remote-desktop display to the end user.
I do NOT want to use VNC because then there is the additional management of
VNC's display port requirement...  which using RDP as the protocol does NOT
require.
I also want to use Guacamole's RDP capability because then later I can also
support end user's logging into Window's servers for a Windows Desktop too.
In each LXC container on the Host/SErver I've installed XRDP and X11RDP.
So the end-user in Guacamole selects a DE to log into and Guacamole sets to
the DE in that LXC container with an RDP session.
All of that works great, performance is great and I can even run a browser
in that LXC container and watch Youtube Video's and the Video's are just
like watching them from my own Desktop/Laptop performance wise.
However, since the LXC container's do NOT have direct access to the
Host/Server's  /dev/snd sound device I am using Pulseaudio's native-TCP
module to allow audio/sound in those Containers to be redirected to the
Pulseaudio "server" running in the Host/Server itself.
In the Host Pulseaudio is configured for TCP connections per (
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/
)
so in /etc/pulse/default.pa (for per-user mode)..  default.pa contains the
following:
load-module module-native-protocol-tcp auth-ip-acl=<IP_ADDRESS>;<IP_ADDRESS>/24
note: 10.0.3.x is the IP subnet for all the LXC containers
load-module module-xrdp-sink
# so xrdp's "sink" is also present
In the Host/Server (re not in the Containers) the above 1st line enables
Pulseaudio to accept TCP connections from ONLY <IP_ADDRESS> (the host/server
itself) and also from ANY LXC container (10.0.3.x) but from no where else.
Now in each Container because of the Host/Server's Pulseaudio configuration
(those 2 lines above)... the Container  CAN see all of the Host's
Pulseaudio Modules even though the containers themselves have NO /dev/snd
device.
Also in every LXC container... EVERY user account inherits the Pulseaudio
Environment variable:
PULSE_SERVER=<IP_ADDRESS>
The above  PULSE_SERVER redirects any Pulseaudio sound to the Host/Server
(Host's IP address from within each container is <IP_ADDRESS>).
So XRDP in each container takes the PulseAudio sound, puts it in RDPSND
channel so the end-user Guacamole RDP connection to the DE in that
Container can provide the audio/sound BACK to the remote user to hear.
My ONLY problem with Sound  in this setup is that UNLESS the User starts &
keeps open a Desktop Session to the Host/Server's DE... Pulseaudio (in
per-user mode) will not start and if it doesn't start then any DE session
the user has in one of the LXC Containers will work ... BUT ... it will not
have any sound/audio played remotely (because the container's need access
to the Host/Server's /dev/snd device.
As you are probably ware Pulseaudio's default is "per-user" mode and in
that mode Pulseaudio ONLY get's started for a User upon initially starting
a login session.
To make sure Pulseaudio in the Host/Server is ALWAYs running in the
Host/Server even if no User is logged into the Host/Server's own DE...   I
setup Pulseaudio in "system wide" mode.   This is basically what people do
with Headless server's they use for an Audio server in their homes or
businesses and perhaps the only legitimate use of Pulseaudio's
"system-wide" mode I know of.
As part of the Pulseaudio System Wide mode configuration I have to move the
2 statements:
load-module module-native-protocol-tcp auth-ip-acl=<IP_ADDRESS>;<IP_ADDRESS>/24
note: 10.0.3.x is the IP subnet for all the LXC containers
load-module module-xrdp-sink
# so xrdp's "sink" is also present
FROM /etc/pulse/default.pa ... TO .... /etc/pulse/system.pa    as in System
Wide mode Pulseaudio uses system.pa file instead.
Again, this ALL works and at Boot the Server/Host starts Pulseaudio and it
stays running.
As an end-user I can log in via Guacamole directly to any of the LXC
container DE's and use that Container's linux desktop to do "work".
BUT .... audio/sound no longer plays remotely for me.
As I'd mentioned in a message yesterday...  I DO see via PAVUCONTROL that
the XRDP SINK does show audio/sound in it.... its just that XRDP for some
reason no longer transfers that audio/sound to the RDPSND channell so
Guacamole can relay it to me remotely.
This has to be due to the fact that the Pulseaudio is running in "system
wide" mode now instead of the normal "per user" mode.
I hope this all makes sense to you as there are alot of moving parts.
Overall the architecture works really well except for the sticking point
with Audio.
I don't want to tell users they HAVE to start a Desktop session with the
Host/Server & just leave it open if they want to have Audio play from the
DE's in the LXC containers and running Pulseaudio in system wide mode
"should" be the way to support that.
If you'd like to try using this first hand we could exchange via email the
info you'd need (IP address to put in your web browser) and i can setup a
UserID/Password in Guacamole for you to log in with
Anyway thianks again.    This is a great use for xrdp and as soon as I get
this audio issue worked out I'm going to post my 6 bash scripts that
install everything auto-magically on Github along with a user guide I've
written so others can use it too.
Brian
On Wed, Jul 13, 2016 at 8:42 PM, Idan Freiberg<EMAIL_ADDRESS>wrote:

I see what you're saying regarding containers and its popularity.
I didn't use any of them yet.
Can you help me to understand why you want xrdp running inside a container
?
בתאריך יום ה׳, 14 ביולי 2016 ב-3:16 מאת bmullan<EMAIL_ADDRESS>
:

Idan

I understand... and don't take me wrong. I just thought with
Container's becoming such a "big thing" I'd try to communicate what I was
seeing with LXC
even though its not Docker-style containers...

I didn't try PA "system wide" mode ever, but there are 2 things to be
aware
of:

PA must load our sink (aka module-xrdp-sink.so). in a normal per-user
session we set (xrdp-sesman) the PULSE_SCRIPT env var
in the USER session to point to /etc/xrdp/pulse/default.pa file, which
instructs PA to load our pulse config file instead of the deafult
per-user
config /etc/pulse/default.pa when X11rdp session starts.

I tried to overcome that by putting the following into the /etc/pulse/
system.pa file:

load-module module-native-protocol-tcp
auth-ip-acl=<IP_ADDRESS>;IP-of-Containers auth-anonymous=1
load-module module-xrdp-sink

and remember... as I said in my bug report... XRDP's SINK does show up
properly in "pavucontrol" output and DOES show data being passed its just
that
its not being passed to RDPSND from Pulseaudio SINK that says it sees the
data in....?

when pulseaudio loads our sink, it is relying on the DISPLAY env var
in
order to send the audio data to the right xrdp-chansrv socket matching
the
current session (aka channel server, which wraps the audio data into the
RDPSND channel and send it back to client). (you can look at:

https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311

)
The thing is, when you run pulse audio in a system-wide mode (as root),
the
DISPLAY env var might be wrong / not set.

I can check this again?

I don't think we thought about system-wide scenario, as it make not sense
to use it when you handle multiple different user sessions running on the
same box.

again... I think that the whole lot of attention being giving to
"Containers" may mean that Pulseaudio and/or those that use it to help
make
Pulseaudio "system mode" work for more headless-type operation....
especially with "cloud".

thanks so much ...
Brian Mullan
Raleigh North Carolina USA.
HTH.
On Wed, Jul 13, 2016 at 7:27 PM, Idan Freiberg<EMAIL_ADDRESS>wrote:

Hi Brian,
I didn't try PA "system wide" mode ever, but there are 2 things to be
aware
of:

PA must load our sink (aka module-xrdp-sink.so).
in a normal per-user session we set (xrdp-sesman) the PULSE_SCRIPT env
var
in the USER session to point to /etc/xrdp/pulse/default.pa file, which
instructs PA to load our pulse config file instead of the deafult
per-user
config /etc/pulse/default.pa when X11rdp session starts.

when pulseaudio loads our sink, it is relying on the DISPLAY env var
in
order to send the audio data to the right xrdp-chansrv socket matching
the
current session (aka channel server, which wraps the audio data into
the
RDPSND channel and send it back to client).
(you can look at:

https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311

)
The thing is, when you run pulse audio in a system-wide mode (as root),
the
DISPLAY env var might be wrong / not set.
I don't think we thought about system-wide scenario, as it make not
sense
to use it when you handle multiple different user sessions running on
the
same box.
HTH.
בתאריך יום ד׳, 13 ביולי 2016 ב-23:00 מאת bmullan <
<EMAIL_ADDRESS>
:

Ok I spent more time with this today and it does seem as though xrdp
doesn't continue to capture pulseaudio sound and pass it via the
RDPSND
channell if pulseaudio is run in "system wide" mode.
I tested this by starting pulseaudio in normal "per user" mode and
audio
from xrdp does come back to me (the remote user) via guacamole's RDP
connection to that server.
audio is generated on the server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
also... pavucontrol shows audio on the xrdp sink
Kill pulseaudio (sudo killall pulseaudio) and restart it in system
wide
mode
sudo su
pulseaudio --system
again generate audio on server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
and again... pavucontrol shows audio on the xrdp sink ... BUT ... no
audio/sound is now heard by me remotely via Guacamole's RDP
connection
!
Since Guacamole doesn't know/care about Pulseaudio in its RDP
connections
only the RDPSND channel audio I'm thinking xrdp must somehow not be
filling
the RDPSND channel with that audio any longer even though its SINK
shows
audio present?
Any ideas what I could try or a log I could try to look at?
A simple way to view what I'm doing would be something similar to a
headless RDP terminal server I guess.
thanks
brian
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232469459
,
or mute the thread
<

https://github.com/notifications/unsubscribe/ADTH1CGm5RPS0ltrzrJKMESyY3QyrojPks5qVUP4gaJpZM4JF-0g

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232516054
,
or mute the thread
<

https://github.com/notifications/unsubscribe/ABmtpyqhCzkd1l6cRmqGFd5AxP6VI1Wvks5qVXRxgaJpZM4JF-0g

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232523343
,
or mute the thread
<
https://github.com/notifications/unsubscribe/ADTH1EFQ1uBRYbASZGL60Jgh8GjrJPBtks5qVX_UgaJpZM4JF-0g

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232526808,
or mute the thread
https://github.com/notifications/unsubscribe/ABmtpx0tdEljq_37JIUXArjwkuqyZmt4ks5qVYYJgaJpZM4JF-0g
.

Idan...
I found the following comment regarding a difference in how Pulseaudio uses
DBus when run in "system wide" mode versus the normal "per user" mode:
reference raspberry pi thread (
https://github.com/masmu/pulseaudio-dlna/issues/159)

the pulseaudio service in system mode is only exposing
org.pulseaudio.Server on the system bus, while in user mode also
org.PulseAudio1 is present and both endpoints are on the session bus.*
I do not know how XRDP normally picks up pulseaudio and transfers it to
RDPSND channel that Guacamole uses but perhaps that's a clue why when
Pulseaudio is in "system wide" there is no audio in Guacamole?

On Thu, Jul 14, 2016 at 8:59 AM, brian mullan<EMAIL_ADDRESS>wrote:

Idan..
My concept/setup is to require a remote desktop user to access my cloud
servers (AWS and Digital Ocean) using only a web browser - which is what
Guacamole provides.
Guacamole is an HTML5 web proxy (called "guacd") running on tomcat on a
cloud host/server (re NOT in an LXC container but on the physical host).
Pulseaudio also runs only on the physical host/server ... NOT in the LXC
containers!
The user connects to Guacamole on the host/server then ... via
configuration I've already created selects one of several Desktop
Environments (DE) to log into.
The DE's I've setup are Ubuntu-Mate, LXDE and XFCE and each of them runs
in a separate LXC container on that same Host/Server.
Guacamole's GUACD supports SSH, VNC and RDP.    But only VNC and RDP
support a remote-desktop display to the end user.
I do NOT want to use VNC because then there is the additional management
of VNC's display port requirement...  which using RDP as the protocol does
NOT require.
I also want to use Guacamole's RDP capability because then later I can
also support end user's logging into Window's servers for a Windows Desktop
too.
In each LXC container on the Host/SErver I've installed XRDP and X11RDP.
So the end-user in Guacamole selects a DE to log into and Guacamole sets
to the DE in that LXC container with an RDP session.
All of that works great, performance is great and I can even run a browser
in that LXC container and watch Youtube Video's and the Video's are just
like watching them from my own Desktop/Laptop performance wise.
However, since the LXC container's do NOT have direct access to the
Host/Server's  /dev/snd sound device I am using Pulseaudio's native-TCP
module to allow audio/sound in those Containers to be redirected to the
Pulseaudio "server" running in the Host/Server itself.
In the Host Pulseaudio is configured for TCP connections per (
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/
)
so in /etc/pulse/default.pa (for per-user mode)..  default.pa contains
the following:
load-module module-native-protocol-tcp auth-ip-acl=<IP_ADDRESS>;<IP_ADDRESS>/24
note: 10.0.3.x is the IP subnet for all the LXC containers
load-module module-xrdp-sink
# so xrdp's "sink" is also present
In the Host/Server (re not in the Containers) the above 1st line enables
Pulseaudio to accept TCP connections from ONLY <IP_ADDRESS> (the host/server
itself) and also from ANY LXC container (10.0.3.x) but from no where else.
Now in each Container because of the Host/Server's Pulseaudio
configuration (those 2 lines above)... the Container  CAN see all of the
Host's Pulseaudio Modules even though the containers themselves have NO
/dev/snd device.
Also in every LXC container... EVERY user account inherits the Pulseaudio
Environment variable:
PULSE_SERVER=<IP_ADDRESS>
The above  PULSE_SERVER redirects any Pulseaudio sound to the Host/Server
(Host's IP address from within each container is <IP_ADDRESS>).
So XRDP in each container takes the PulseAudio sound, puts it in RDPSND
channel so the end-user Guacamole RDP connection to the DE in that
Container can provide the audio/sound BACK to the remote user to hear.
My ONLY problem with Sound  in this setup is that UNLESS the User starts &
keeps open a Desktop Session to the Host/Server's DE... Pulseaudio (in
per-user mode) will not start and if it doesn't start then any DE session
the user has in one of the LXC Containers will work ... BUT ... it will not
have any sound/audio played remotely (because the container's need access
to the Host/Server's /dev/snd device.
As you are probably ware Pulseaudio's default is "per-user" mode and in
that mode Pulseaudio ONLY get's started for a User upon initially starting
a login session.
To make sure Pulseaudio in the Host/Server is ALWAYs running in the
Host/Server even if no User is logged into the Host/Server's own DE...   I
setup Pulseaudio in "system wide" mode.   This is basically what people do
with Headless server's they use for an Audio server in their homes or
businesses and perhaps the only legitimate use of Pulseaudio's
"system-wide" mode I know of.
As part of the Pulseaudio System Wide mode configuration I have to move
the 2 statements:
load-module module-native-protocol-tcp auth-ip-acl=<IP_ADDRESS>;<IP_ADDRESS>/24
note: 10.0.3.x is the IP subnet for all the LXC containers
load-module module-xrdp-sink
# so xrdp's "sink" is also present
FROM /etc/pulse/default.pa ... TO .... /etc/pulse/system.pa    as in
System Wide mode Pulseaudio uses system.pa file instead.
Again, this ALL works and at Boot the Server/Host starts Pulseaudio and it
stays running.
As an end-user I can log in via Guacamole directly to any of the LXC
container DE's and use that Container's linux desktop to do "work".
BUT .... audio/sound no longer plays remotely for me.
As I'd mentioned in a message yesterday...  I DO see via PAVUCONTROL that
the XRDP SINK does show audio/sound in it.... its just that XRDP for some
reason no longer transfers that audio/sound to the RDPSND channell so
Guacamole can relay it to me remotely.
This has to be due to the fact that the Pulseaudio is running in "system
wide" mode now instead of the normal "per user" mode.
I hope this all makes sense to you as there are alot of moving parts.
Overall the architecture works really well except for the sticking point
with Audio.
I don't want to tell users they HAVE to start a Desktop session with the
Host/Server & just leave it open if they want to have Audio play from the
DE's in the LXC containers and running Pulseaudio in system wide mode
"should" be the way to support that.
If you'd like to try using this first hand we could exchange via email the
info you'd need (IP address to put in your web browser) and i can setup a
UserID/Password in Guacamole for you to log in with
Anyway thianks again.    This is a great use for xrdp and as soon as I get
this audio issue worked out I'm going to post my 6 bash scripts that
install everything auto-magically on Github along with a user guide I've
written so others can use it too.
Brian
On Wed, Jul 13, 2016 at 8:42 PM, Idan Freiberg<EMAIL_ADDRESS>wrote:

I see what you're saying regarding containers and its popularity.
I didn't use any of them yet.
Can you help me to understand why you want xrdp running inside a
container ?
בתאריך יום ה׳, 14 ביולי 2016 ב-3:16 מאת bmullan<EMAIL_ADDRESS>
:

Idan

I understand... and don't take me wrong. I just thought with
Container's becoming such a "big thing" I'd try to communicate what I
was
seeing with LXC
even though its not Docker-style containers...

I didn't try PA "system wide" mode ever, but there are 2 things to be
aware
of:

PA must load our sink (aka module-xrdp-sink.so). in a normal
per-user
session we set (xrdp-sesman) the PULSE_SCRIPT env var
in the USER session to point to /etc/xrdp/pulse/default.pa file, which
instructs PA to load our pulse config file instead of the deafult
per-user
config /etc/pulse/default.pa when X11rdp session starts.

I tried to overcome that by putting the following into the /etc/pulse/
system.pa file:

load-module module-native-protocol-tcp
auth-ip-acl=<IP_ADDRESS>;IP-of-Containers auth-anonymous=1
load-module module-xrdp-sink

and remember... as I said in my bug report... XRDP's SINK does show up
properly in "pavucontrol" output and DOES show data being passed its
just
that
its not being passed to RDPSND from Pulseaudio SINK that says it sees
the
data in....?

when pulseaudio loads our sink, it is relying on the DISPLAY env var
in
order to send the audio data to the right xrdp-chansrv socket matching
the
current session (aka channel server, which wraps the audio data into the
RDPSND channel and send it back to client). (you can look at:

https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311

)
The thing is, when you run pulse audio in a system-wide mode (as root),
the
DISPLAY env var might be wrong / not set.

I can check this again?

I don't think we thought about system-wide scenario, as it make not
sense
to use it when you handle multiple different user sessions running on
the
same box.

again... I think that the whole lot of attention being giving to
"Containers" may mean that Pulseaudio and/or those that use it to help
make
Pulseaudio "system mode" work for more headless-type operation....
especially with "cloud".

thanks so much ...
Brian Mullan
Raleigh North Carolina USA.
HTH.
On Wed, Jul 13, 2016 at 7:27 PM, Idan Freiberg <
<EMAIL_ADDRESS>wrote:

Hi Brian,
I didn't try PA "system wide" mode ever, but there are 2 things to be
aware
of:

PA must load our sink (aka module-xrdp-sink.so).
in a normal per-user session we set (xrdp-sesman) the PULSE_SCRIPT env
var
in the USER session to point to /etc/xrdp/pulse/default.pa file,
which
instructs PA to load our pulse config file instead of the deafult
per-user
config /etc/pulse/default.pa when X11rdp session starts.

when pulseaudio loads our sink, it is relying on the DISPLAY env
var
in
order to send the audio data to the right xrdp-chansrv socket matching
the
current session (aka channel server, which wraps the audio data into
the
RDPSND channel and send it back to client).
(you can look at:

https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311

)
The thing is, when you run pulse audio in a system-wide mode (as
root),
the
DISPLAY env var might be wrong / not set.
I don't think we thought about system-wide scenario, as it make not
sense
to use it when you handle multiple different user sessions running on
the
same box.
HTH.
בתאריך יום ד׳, 13 ביולי 2016 ב-23:00 מאת bmullan <
<EMAIL_ADDRESS>
:

Ok I spent more time with this today and it does seem as though xrdp
doesn't continue to capture pulseaudio sound and pass it via the
RDPSND
channell if pulseaudio is run in "system wide" mode.
I tested this by starting pulseaudio in normal "per user" mode and
audio
from xrdp does come back to me (the remote user) via guacamole's RDP
connection to that server.
audio is generated on the server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
also... pavucontrol shows audio on the xrdp sink
Kill pulseaudio (sudo killall pulseaudio) and restart it in system
wide
mode
sudo su
pulseaudio --system
again generate audio on server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
and again... pavucontrol shows audio on the xrdp sink ... BUT ... no
audio/sound is now heard by me remotely via Guacamole's RDP
connection
!
Since Guacamole doesn't know/care about Pulseaudio in its RDP
connections
only the RDPSND channel audio I'm thinking xrdp must somehow not be
filling
the RDPSND channel with that audio any longer even though its SINK
shows
audio present?
Any ideas what I could try or a log I could try to look at?
A simple way to view what I'm doing would be something similar to a
headless RDP terminal server I guess.
thanks
brian
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232469459
,
or mute the thread
<

https://github.com/notifications/unsubscribe/ADTH1CGm5RPS0ltrzrJKMESyY3QyrojPks5qVUP4gaJpZM4JF-0g

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232516054
,
or mute the thread
<

https://github.com/notifications/unsubscribe/ABmtpyqhCzkd1l6cRmqGFd5AxP6VI1Wvks5qVXRxgaJpZM4JF-0g

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232523343
,
or mute the thread
<
https://github.com/notifications/unsubscribe/ADTH1EFQ1uBRYbASZGL60Jgh8GjrJPBtks5qVX_UgaJpZM4JF-0g

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232526808,
or mute the thread
https://github.com/notifications/unsubscribe/ABmtpx0tdEljq_37JIUXArjwkuqyZmt4ks5qVYYJgaJpZM4JF-0g
.

Idan... in particular near the bottom of the thread (
https://github.com/masmu/pulseaudio-dlna/issues/159)
It points to the solution that the Raspberry Pi users/devs apparently found:
http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/DBus/ConnectingToServer/
Lookup Service Details
To give some background information (and to document this stuff
somewhere), this is how server discovery works from PulseAudio's point of
view:
*Contrary to earlier behavior, running the pulseaudio executable with D-Bus
support compiled in doesn't necessary start a proper sound server. *
*In certain circumstances only the server lookup service, as described
above, is started. *
This happens in two cases: the executable is run by a non-root user and
the daemon is configured to run in the system mode, or the daemon
configuration just says that no local server should be started (which is
useful when only remote servers are intended to be used).
There is a new option in daemon.conf: local-server-type. Its value can be
either "user", "system" or "none". The default is "user". However, the
option conflicts with the old option system-instance. If system-instance is
set and local-server-type is not, system-instance value is honored. On the
other hand, if local-server-type is set, it overrides whatever is the value
of system-instance.
*If user's pulseaudio executable isn't running when a client reads the
Address property, D-Bus automatically starts pulseaudio. *
*Depending on server configuration, a real sound server may be started, but
another possibility is that only the server lookup service is enabled. The
server lookup service, i.e. the Address property, works by first reading
the user's (or in absence of that, the system version of) client.conf.
client.conf too has a new option: default-dbus-server. *
*If it is set, then that value is returned to the client. *
*If default-dbus-server is not set, the address is deduced from the
local-server-type option: *
in case of "user" the returned address is the unix socket of the user's
server (~/.pulse/:runtime/dbus-socket), in case of "system" the returned
address is the system server's unix socket (/var/run/pulse/dbus-socket),
and in case of "none" the returned address is an empty string.
On Sat, Jul 23, 2016 at 8:07 PM, brian mullan<EMAIL_ADDRESS>wrote:

Idan...
I found the following comment regarding a difference in how Pulseaudio
uses DBus when run in "system wide" mode versus the normal "per user" mode:
reference raspberry pi thread (
https://github.com/masmu/pulseaudio-dlna/issues/159)

the pulseaudio service in system mode is only exposing
org.pulseaudio.Server on the system bus, while in user mode also
org.PulseAudio1 is present and both endpoints are on the session bus.*
I do not know how XRDP normally picks up pulseaudio and transfers it to
RDPSND channel that Guacamole uses but perhaps that's a clue why when
Pulseaudio is in "system wide" there is no audio in Guacamole?

On Thu, Jul 14, 2016 at 8:59 AM, brian mullan<EMAIL_ADDRESS>wrote:

Idan..
My concept/setup is to require a remote desktop user to access my cloud
servers (AWS and Digital Ocean) using only a web browser - which is what
Guacamole provides.
Guacamole is an HTML5 web proxy (called "guacd") running on tomcat on a
cloud host/server (re NOT in an LXC container but on the physical host).
Pulseaudio also runs only on the physical host/server ... NOT in the LXC
containers!
The user connects to Guacamole on the host/server then ... via
configuration I've already created selects one of several Desktop
Environments (DE) to log into.
The DE's I've setup are Ubuntu-Mate, LXDE and XFCE and each of them runs
in a separate LXC container on that same Host/Server.
Guacamole's GUACD supports SSH, VNC and RDP.    But only VNC and RDP
support a remote-desktop display to the end user.
I do NOT want to use VNC because then there is the additional management
of VNC's display port requirement...  which using RDP as the protocol does
NOT require.
I also want to use Guacamole's RDP capability because then later I can
also support end user's logging into Window's servers for a Windows Desktop
too.
In each LXC container on the Host/SErver I've installed XRDP and X11RDP.
So the end-user in Guacamole selects a DE to log into and Guacamole sets
to the DE in that LXC container with an RDP session.
All of that works great, performance is great and I can even run a
browser in that LXC container and watch Youtube Video's and the Video's are
just like watching them from my own Desktop/Laptop performance wise.
However, since the LXC container's do NOT have direct access to the
Host/Server's  /dev/snd sound device I am using Pulseaudio's native-TCP
module to allow audio/sound in those Containers to be redirected to the
Pulseaudio "server" running in the Host/Server itself.
In the Host Pulseaudio is configured for TCP connections per (
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/
)
so in /etc/pulse/default.pa (for per-user mode)..  default.pa contains
the following:
load-module module-native-protocol-tcp auth-ip-acl=<IP_ADDRESS>;<IP_ADDRESS>/24
note: 10.0.3.x is the IP subnet for all the LXC containers
load-module module-xrdp-sink
# so xrdp's "sink" is also present
In the Host/Server (re not in the Containers) the above 1st line enables
Pulseaudio to accept TCP connections from ONLY <IP_ADDRESS> (the host/server
itself) and also from ANY LXC container (10.0.3.x) but from no where else.
Now in each Container because of the Host/Server's Pulseaudio
configuration (those 2 lines above)... the Container  CAN see all of the
Host's Pulseaudio Modules even though the containers themselves have NO
/dev/snd device.
Also in every LXC container... EVERY user account inherits the Pulseaudio
Environment variable:
PULSE_SERVER=<IP_ADDRESS>
The above  PULSE_SERVER redirects any Pulseaudio sound to the Host/Server
(Host's IP address from within each container is <IP_ADDRESS>).
So XRDP in each container takes the PulseAudio sound, puts it in RDPSND
channel so the end-user Guacamole RDP connection to the DE in that
Container can provide the audio/sound BACK to the remote user to hear.
My ONLY problem with Sound  in this setup is that UNLESS the User starts
& keeps open a Desktop Session to the Host/Server's DE... Pulseaudio (in
per-user mode) will not start and if it doesn't start then any DE session
the user has in one of the LXC Containers will work ... BUT ... it will not
have any sound/audio played remotely (because the container's need access
to the Host/Server's /dev/snd device.
As you are probably ware Pulseaudio's default is "per-user" mode and in
that mode Pulseaudio ONLY get's started for a User upon initially starting
a login session.
To make sure Pulseaudio in the Host/Server is ALWAYs running in the
Host/Server even if no User is logged into the Host/Server's own DE...   I
setup Pulseaudio in "system wide" mode.   This is basically what people do
with Headless server's they use for an Audio server in their homes or
businesses and perhaps the only legitimate use of Pulseaudio's
"system-wide" mode I know of.
As part of the Pulseaudio System Wide mode configuration I have to move
the 2 statements:
load-module module-native-protocol-tcp auth-ip-acl=<IP_ADDRESS>;<IP_ADDRESS>/24
note: 10.0.3.x is the IP subnet for all the LXC containers
load-module module-xrdp-sink
# so xrdp's "sink" is also present
FROM /etc/pulse/default.pa ... TO .... /etc/pulse/system.pa    as in
System Wide mode Pulseaudio uses system.pa file instead.
Again, this ALL works and at Boot the Server/Host starts Pulseaudio and
it stays running.
As an end-user I can log in via Guacamole directly to any of the LXC
container DE's and use that Container's linux desktop to do "work".
BUT .... audio/sound no longer plays remotely for me.
As I'd mentioned in a message yesterday...  I DO see via PAVUCONTROL that
the XRDP SINK does show audio/sound in it.... its just that XRDP for some
reason no longer transfers that audio/sound to the RDPSND channell so
Guacamole can relay it to me remotely.
This has to be due to the fact that the Pulseaudio is running in "system
wide" mode now instead of the normal "per user" mode.
I hope this all makes sense to you as there are alot of moving parts.
Overall the architecture works really well except for the sticking point
with Audio.
I don't want to tell users they HAVE to start a Desktop session with the
Host/Server & just leave it open if they want to have Audio play from the
DE's in the LXC containers and running Pulseaudio in system wide mode
"should" be the way to support that.
If you'd like to try using this first hand we could exchange via email
the info you'd need (IP address to put in your web browser) and i can setup
a UserID/Password in Guacamole for you to log in with
Anyway thianks again.    This is a great use for xrdp and as soon as I
get this audio issue worked out I'm going to post my 6 bash scripts that
install everything auto-magically on Github along with a user guide I've
written so others can use it too.
Brian
On Wed, Jul 13, 2016 at 8:42 PM, Idan Freiberg<EMAIL_ADDRESS>wrote:

I see what you're saying regarding containers and its popularity.
I didn't use any of them yet.
Can you help me to understand why you want xrdp running inside a
container ?
בתאריך יום ה׳, 14 ביולי 2016 ב-3:16 מאת bmullan <
<EMAIL_ADDRESS>
Idan

I understand... and don't take me wrong. I just thought with
Container's becoming such a "big thing" I'd try to communicate what I
was
seeing with LXC
even though its not Docker-style containers...

I didn't try PA "system wide" mode ever, but there are 2 things to be
aware
of:

PA must load our sink (aka module-xrdp-sink.so). in a normal
per-user
session we set (xrdp-sesman) the PULSE_SCRIPT env var
in the USER session to point to /etc/xrdp/pulse/default.pa file,
which
instructs PA to load our pulse config file instead of the deafult
per-user
config /etc/pulse/default.pa when X11rdp session starts.

I tried to overcome that by putting the following into the /etc/pulse/
system.pa file:

load-module module-native-protocol-tcp
auth-ip-acl=<IP_ADDRESS>;IP-of-Containers auth-anonymous=1
load-module module-xrdp-sink

and remember... as I said in my bug report... XRDP's SINK does show up
properly in "pavucontrol" output and DOES show data being passed its
just
that
its not being passed to RDPSND from Pulseaudio SINK that says it sees
the
data in....?

when pulseaudio loads our sink, it is relying on the DISPLAY env
var in
order to send the audio data to the right xrdp-chansrv socket matching
the
current session (aka channel server, which wraps the audio data into
the
RDPSND channel and send it back to client). (you can look at:

https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311

)
The thing is, when you run pulse audio in a system-wide mode (as
root), the
DISPLAY env var might be wrong / not set.

I can check this again?

I don't think we thought about system-wide scenario, as it make not
sense
to use it when you handle multiple different user sessions running on
the
same box.

again... I think that the whole lot of attention being giving to
"Containers" may mean that Pulseaudio and/or those that use it to help
make
Pulseaudio "system mode" work for more headless-type operation....
especially with "cloud".

thanks so much ...
Brian Mullan
Raleigh North Carolina USA.
HTH.
On Wed, Jul 13, 2016 at 7:27 PM, Idan Freiberg <
<EMAIL_ADDRESS>wrote:

Hi Brian,
I didn't try PA "system wide" mode ever, but there are 2 things to be
aware
of:

PA must load our sink (aka module-xrdp-sink.so).
in a normal per-user session we set (xrdp-sesman) the PULSE_SCRIPT
env
var
in the USER session to point to /etc/xrdp/pulse/default.pa file,
which
instructs PA to load our pulse config file instead of the deafult
per-user
config /etc/pulse/default.pa when X11rdp session starts.

when pulseaudio loads our sink, it is relying on the DISPLAY env
var
in
order to send the audio data to the right xrdp-chansrv socket
matching
the
current session (aka channel server, which wraps the audio data into
the
RDPSND channel and send it back to client).
(you can look at:

https://github.com/neutrinolabs/xrdp/blob/devel/sesman/chansrv/pulse/module-xrdp-sink.c#L311

)
The thing is, when you run pulse audio in a system-wide mode (as
root),
the
DISPLAY env var might be wrong / not set.
I don't think we thought about system-wide scenario, as it make not
sense
to use it when you handle multiple different user sessions running
on the
same box.
HTH.
בתאריך יום ד׳, 13 ביולי 2016 ב-23:00 מאת bmullan <
<EMAIL_ADDRESS>
:

Ok I spent more time with this today and it does seem as though
xrdp
doesn't continue to capture pulseaudio sound and pass it via the
RDPSND
channell if pulseaudio is run in "system wide" mode.
I tested this by starting pulseaudio in normal "per user" mode and
audio
from xrdp does come back to me (the remote user) via guacamole's
RDP
connection to that server.
audio is generated on the server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
also... pavucontrol shows audio on the xrdp sink
Kill pulseaudio (sudo killall pulseaudio) and restart it in system
wide
mode
sudo su
pulseaudio --system
again generate audio on server using: aplay
/usr/share/sounds/alsa/Front_Center.wav
and again... pavucontrol shows audio on the xrdp sink ... BUT ...
no
audio/sound is now heard by me remotely via Guacamole's RDP
connection
!
Since Guacamole doesn't know/care about Pulseaudio in its RDP
connections
only the RDPSND channel audio I'm thinking xrdp must somehow not be
filling
the RDPSND channel with that audio any longer even though its SINK
shows
audio present?
Any ideas what I could try or a log I could try to look at?
A simple way to view what I'm doing would be something similar to a
headless RDP terminal server I guess.
thanks
brian
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232469459
,
or mute the thread
<

https://github.com/notifications/unsubscribe/ADTH1CGm5RPS0ltrzrJKMESyY3QyrojPks5qVUP4gaJpZM4JF-0g

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232516054
,
or mute the thread
<

https://github.com/notifications/unsubscribe/ABmtpyqhCzkd1l6cRmqGFd5AxP6VI1Wvks5qVXRxgaJpZM4JF-0g

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232523343>,
or mute the thread
<
https://github.com/notifications/unsubscribe/ADTH1EFQ1uBRYbASZGL60Jgh8GjrJPBtks5qVX_UgaJpZM4JF-0g

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/neutrinolabs/xrdp/issues/395#issuecomment-232526808,
or mute the thread
https://github.com/notifications/unsubscribe/ABmtpx0tdEljq_37JIUXArjwkuqyZmt4ks5qVYYJgaJpZM4JF-0g
.

Bump


Workaround rollup messing up default imports

Tackles https://github.com/rust-analyzer/rust-analyzer/issues/5257#issuecomment-655435271
Related: https://github.com/rollup/plugins/issues/491

bors r+


Only record extra Evaluator data when needed

This saves memory. Otherwise, the extra list tips over the memory sensitive GC aware code from the ProjectCollection cache (and potentially other special MSBuild caches) leading to a lot of GC calls and thus performance hits.

@dsplaisted @AndyGerlicher

If possible, I'd prefer it if the getter for EvaluatedItemElements would call ReevaluateForPostMortemAnalysisIfNecessary rather than everyone that accesses it knowing they need to call this method.  That would make it less error prone.
Otherwise, :shipit:

@dsplaisted I looked into doing that but it hits ugly re-entrancy issues because the Evaluator is also calling that getter while evaluating. Making it work nicely complicates that part of the code quite a bit, so I don't think it's worth doing.

If possible, I'd prefer it if the getter for EvaluatedItemElements would call ReevaluateForPostMortemAnalysisIfNecessary rather than everyone that accesses it knowing they need to call this method. That would make it less error prone.
Otherwise, :shipit:


Link transparency refers to link type index rather than link type itself during timeplay

While time-stepping through data we had a new link type appear at a certain timestep, and when that happened the number of link types increased by 1 which shifted the index of the pre-existing link types. The transparency settings for links were then shifted by one.
Example:
TIMESTEP 1
link_type 1 (transparency @ 100%)
link_type 2 (transparency @ 50%)
link_type 3 (transparency @ 100%)
link_type 4 (transparency @ 100%)
TIMESTEP 2
link_type 5 (transparency @ 100%)
link_type 1 (transparency @ 50%)
link_type 2 (transparency @ 100%)
link_type 3 (transparency @ 100%)
link_type 4 (transparency @ 100%)
Note that at timepoint 1 link_type 2 is set to 50% transparency, but at timepoint 2 link_type 1 is now at 50%, and link_type 2 has been shifted to index 3 and transparency 100%.

Discovered during out meeting with the California PHL today.


Implementation of Node and Activities Rest Endpoints

In this issue we are focus to develop needed rest endpoints for Node Configuration, versioning, and Activities Rest Endpoints which will be used of the home page in Andy X Portal

Merged with v3/main


How can I set the bounds of a map to fit all of the markers on a map?

I feel like this should be simple, but I'm just missing something. Happy to add the solution to the examples page once I have it.
Thanks!

If you have all markers in a featureGroup, you can use yourFeatureGroup.getBounds()
If you need some padding, you can use the pad() method on the returned bounds.

Thanks for the response! So, I was following the examples on the ui-leaflet page, and added my markers by following those examples, e.g:
$scope.markers = [
  lat: 59.91,
  lng: 10.75,
  message: "I want to travel here!",
  focus: true,
  draggable: false
]

Not sure how to add them via a featureGroup; or, by adding the markers this way are they automatically added to a featureGroup? I see the link you pasted about featureGroups references the main leaflet documentation, but that seemed to be incorrect in context of this Angular project.

This was not tested, but may point you in the right direction:
$scope.markers = {
  marker1: {
    layer: 'markers', // This tells ui-leaflet to put this marker in the overlay with name 'markers'
    lat: 59.91,
    lng: 10.75,
    message: 'I want to travel here!',
    focus: true,
    draggable: false
  },
  marker2: {
    layer: 'markers', // This tells ui-leaflet to put this marker in the overlay with name 'markers'
    lat: 70,
    lng: 12,
    message: 'Another message',
    focus: true,
    draggable: false
  },
  // ...
};

$scope.overlays = {
  markers: {
    type: 'featureGroup',
    name: 'markers', // This is the name of the overlay
    visible: true
  }
};

That sadly threw some error messages. I change my directive to
<leaflet markers="markers" layers="layers"></leaflet>
and added the layer attribute to each marker, but I'm getting both a Cannot read property 'baselayers' of undefined and a  A marker can only be added to a layer of type "group" error.

Did you figure this out?

@chrismanderson You have found a solution to the error Cannot read property 'baselayers' of undefined? I too have the same problem ...

@jackeo, This error happen when layers attribute is not defined in the $scope.
Please assign a value to layers attribute as:
$scope.layers = {
  baselayers: {},
  overlays: {}
}

It may be a bit late but here is how I tackled this.
As per the documentation, inject leafletData into your controller.
Then you can do:
leafletData.getMap().then((map) => {
    map.fitBounds(markersArray);
});

I might be stupid, but how to get raw leaflet featureGroup from angular scoped markers array / overlay option (/ geojson option in my case)


Layout broken

Hi,
Just wanted to let you know that the layout is broken in your git repo, something is wrong in the code when you clone and open index.html you'll figure out this
(it is supposed to open like the demo but it is not)

the issue is that the file it is trying to load is jQuery-2.1.4.min.js
however the file in the plugins/jQuery  is jquery-2.1.4.min.js
notice the uppercase Q
it seems like this would either need a case insensitive Apache module.  or simply rename the file with the uppercase Q


Cor5in docker

From this issue [Missing . in docker build command #919]
I added . at the end of docker build command
I added '.' because it means that Dockerfile is in the current directory.

@bobtabor-msft
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Thanks.
Kinds regards


No Response when trying to view camera

I just installed this and I think it’s almost working. I can see a static image of my camera in homekit but when I tap on it homekit says No Response. I am running homebridge on a Pi Zero. I noticed that when I try to view the camera that my Pi’s CPU usage goes to 100%. When I close the Home app the CPU usage goes back down to like 5%. Is it possible that the Pi Zero is too weak to run this? I’m guessing there’s some video processing going on with ffmpeg and that might be a little too much for my little Zero to handle.

Yeah, Raspberry Pi’s CPU is too weak to handle transcoding properly. I’ll try to push an update later today to offer an option to use OMX hardware acceleration on Raspberry Pi.

Ok cool. Check out this comment on Reddit too.. https://www.reddit.com/r/HomeKit/comments/7fncev/nest_cams_finally_have_a_homebridge_plugin_use/

Alright, 0.0.3 has the OMX option now. You may need a special ffmpeg to use that.


Coalesce and normalize squashed mappable regions

[ch9604]

Published snapshot as 147.1.1-6403892

Still needs unit tests, thus the :stop_sign:, but I've manually tested with the query in ch9604 and ch9238. In both cases compile times improved an order of magnitude. Also passes all mimir integration tests.

👍 looks good
will look again after unit tests are pushed


Add GA4 tracking to some missions page blocks

What / Why

Adds GA4 tracking to some missions page blocks as this was missing in the initial release
Adds the link tracker for the Menu, Boxes and Org logo links
Adds the event tracker for the Menu button
See the implementation guide if you'd like to verify the JSON values.
I had to create a new container block for the boxes to give me a nice way to track them. This is because they're rendered separately from each other in the code, and for the purposes of GA4 indexes I needed to capture all of them in one <div> so the indexes could be set. Therefore there's a new box_container block. (I didn't want to add the tracking on to the existing columns_layout <div> that surrounds all of them already, as I don't think columns_layout should have any tracking on it.)
Trello cards:

https://trello.com/c/EGZOPdxC/215-add-ga4-tracking-to-blocks
https://trello.com/c/lumWLkCq
https://trello.com/c/ccYUfF9Q
https://trello.com/c/EQPR2GYw

Thanks @andysellick  - should be ready to re-review. Also had to rebase as the organisation logo's render statement moved to a new template.

Thanks @andysellick - should be ready to review again 👍


don't use ParsedArgs in rawDebugSession; fixes #80461

There are conflicts with the master branch since Ben moved a lot of code around. And I see no rush to do this before endgame.
Thus moving to October.

I have resolved conflicts with the master branch. However I still see no rush for this. Thus I will merge this in debt week in 8 days. Leaving for October.

Didn't use this PR but fixed the issue via https://github.com/microsoft/vscode/commit/ee432c084a79537280e8390f95cb347193d46f33


fix(msv): multiple fixes to the msv logic

When a volume is being destroyed, it may not have any replicas or nexuses but we still need to
delete the MSV, so make sure we don't exit early.
Add all of the msv event "del" logic to the serialization queue, otherwise it could be ran before
the "new" event has been processed.
Skip volume update for faulted volumes.
Don't import volumes which are already created. This happens right after a volume is created,
which is an unfortunate side effect, so we can just skip it.
Don't show throw invalid extending volume error when the volume size has not yet been set.

bors merge


libredirect on non-NixOS

Issue description
Steps to reproduce
When using libredirect on non-NixOS distro, e.g. Debian 9, LD_PRELOAD is propagated, so if wrapped application runs some system binary, there is an error:
sh: relocation error: /nix/store/sgjc1147vi5hd57ck9xgck5xjkydg5lz-glibc-2.25/lib/libdl.so.2: symbol _dl_catch_error, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference

Is there a way to fix that?
Technical details

System: (NixOS: nixos-version, Ubuntu/Fedora: lsb_release -a, ...)
Nix version: (run nix-env --version)
Nixpkgs version: (run nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion)
Sandboxing enabled: (run grep build-use-sandbox /etc/nix/nix.conf)

That confuses me a bit.  I thought the main point of libredirect is to avoid using LD_PRELOAD.

@vcunat I mean't NixOS own libredirect simple proxy https://github.com/NixOS/nixpkgs/tree/master/pkgs/build-support/libredirect
And here is how we use it https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/security/enpass/default.nix#L87
Is it possible to allow glibc from nixpkgs to read an additional environment variable to LD_PRELOAD, say LD_NIX_PRELOAD (as we do with reading /etc/ld-nix-preload.so https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/glibc/dont-use-system-ld-so-preload.patch), so dynamic loader of host system will not suffer from our packages?

I'm sorry, I confused those :-/
It certainly is possible to add a new variable for this.  I wonder if it's a good idea; I don't see any caveats yet.

One way to avoid this, is to unset LD_LIBRARY in the libredirect code.
So it will be only used by the actual process will pick it up.

Well, it's a problem on NixOS as well that the redirect leaks to all possible child processes.
Maybe libredirect could remove itself from LD_PRELOAD on startup.

I suppose this depends on the particular use case.  I can imagine you to want to "sandbox" all child processes as well, because they are e.g. just parts of the same application.

For maximal flexibility, there could e.g. be a build-time parameter to libredirect – a list of nix-store paths, and it would deactivate itself when in a process outside those subtrees.  But it seems useless to implement such cannons until we know at least some particular use case.

There have been occassional complaints on IRC about the Teamspeak client (which uses libredirect) being unable to open links in Chromium because the inherited libredirect causes Chromium to crash.

Currently having this problem as well:

Installed sublime3 and ctags.
Installed the CTags package inside sublime.
Try to run ctags from within sublime leads to:

sort: relocation error: /nix/store/bwax7l3946zn3l806727sd1fk8ssjgpv-glibc-2.25-49/lib/libdl.so.2: symbol _dl_catch_error, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
ctags: cannot sort tag file : No such file or directory

I've worked around this issue by installing nixpkgs.coreutils, to get the sort command from nixpkgs.

I just tested and unsetenv("LD_PRELOAD"); does not work reliable: https://stackoverflow.com/questions/3275015/ld-preload-affects-new-child-even-after-unsetenvld-preload
Maybe wrapping exec and do the cleanup their does the job.

It might be worth asking the glibc people if they'd be willing to have an option like ${glibc}/lib/ld-linux.so.2 --preload implemented in the dynamic linker similar to the --library-path option they have. Then instead of adding an environment variable, makeWrapper could prefix the command with an explicit call to the linker.

If anyone is hitting this with Haskell stack on non-NixOS distros, just use the nix integration for Stack:
Put:
nix:
  enable: true

in your ~/.stack/config.yaml or project specific stack.yaml and you're done.


That's an error

This user-agent is not permitted to make an OAuth authorization request to Google as It is classified as an embedded user-agent...

Please see the deprecation notice
Duplicate of #84 & #85

Hi @thomasvl , so I should use https://github.com/google/GTMAppAuth instead?

Yup

Thank you :dancing_men:


deliver broadcast messages asynchronously

Deliver messages, which are called by method trigger,  asynchronously
It`s a not final PR

@palkan hi!
I sum up the changes
Currently, we have two adapters, "Inline" and "ActiveJob" in two files
The specific adapter is chosen by DeliveryAdapter.lookup and settings in the configuration (delivery_method)
Also, we have a custom serializer AnyCableSubscriptionSerializer which helps do not think about an instance of class AnyCableSubscriptions in active jobs, for example here
But for example here I used the arguments forwarding shorthand, which exists in ruby 2.7 (I see that ci-cd checks on ruby 2.7 and upper), but this gem has a dependency anycable-rails, which requires minimum 2.6 ruby
Maybe here I need not to use the arguments forwarding shorthand


Dynamically created Vue instances

Thanks for such an awesome devtool, it's really helpful. The problem I'm having is when I create a new Vue({ ... }) instance in a place such as $.ajax(...).done(function () { /* here */ }) this devtool doesn't show it. Is that something I'm doing wrong? Do you need a full example to reproduce the issue?

I took a look through the source code. If only there's a way to call scan function in backend/index.js, I could do that manually every time, until somebody patches the devtool.

Is this still an issue for you? I create Vue instances on the fly using a similar mechanism and I can inspect them within DevTools.

@sirlancelot just tried new Vue({ el: '#footer' }); on console and it's not visible in Vue DevTools tab.

@hkan this use case with multiple separated roots belongs to https://github.com/vuejs/vue-devtools/issues/98.
Try specifying parent:
var vm = new Vue({ el: '#root' }); // main root
var header = new Vue({ el: '#footer', parent: vm });

If this works, then I consider the issue resolved.

@simplesmiler yeah, if I specify a parent, Vue DevTools tab shows the new component.


⚠ Bofrost.de has degraded performance

In fa56ac5, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 2379 ms

Resolved: Bofrost.de performance has improved in 65643cb.


Rewrite update without lodash

Prerequisites

[x] I have read the Contributing guidelines
[x] I have read the Code of conduct and I agree with it

Description
Rewrite update without lodash
Issue : #109

Codecov Report

Merging #120 into feature/107 will not change coverage.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           feature/107   #120   +/-   ##
==========================================
  Coverage          100%   100%
==========================================
  Files               74     75    +1
  Lines              244    246    +2
  Branches            47     47
==========================================
+ Hits               244    246    +2

Impacted Files
Coverage Δ

src/core/update.js
100% <100%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e5dcae9...68c1d7a. Read the comment docs.


 Just tossing it out for a thorough beating by the group...
I had a backer call me up and ask if it would be possible to use the SDRs as a backup radio. He was initially thinking of a full transceiver, and I explained that the SDRs were strictly receivers. So he suggested that they could still be a good back up receiver - perhaps for listening to ATIS / AWOS.
I realize that the antennas we're using are not tuned for the low MHz range of VHF, but what do you think? Would it be useful to be able to pull one of the SDRs off of data modem duty and assign it as an AM receiver? Perhaps output the audio to the Pi's analog jack or stream it to a web page?

Stick another $20 sdr on?  Or even use a separate RPi2 with it's own
receiver, just for "miscellaneous" other receiver functions?  :)
ATIS/AWOS, instrument landing system with much better graphics
(backup!), and so on and so on...
 Just tossing it out for a
thorough beating by the group...
I had a backer call me up and ask if it would be possible to use the
SDRs as a backup radio. He was initially thinking of a full
transceiver, and I explained that the SDRs were strictly receivers. So
he suggested that they could still be a good back up receiver -
perhaps for listening to ATIS / AWOS.
I realize that the antennas we're using are not tuned for the low MHz
range of VHF, but what do you think? Would it be useful to be able to
pull one of the SDRs off of data modem duty and assign it as an AM
receiver? Perhaps output the audio to the Pi's analog jack or stream
it to a web page?
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/215.

Great idea! Streaming via WiFi and/or playing to the RPi's audio-out are both options.
While we're talking about new features, is there any interest in serialout? I made an image for someone to test on a Chelton EFIS. Anyone else want to test? https://www.dropbox.com/s/owvhmhxt3w6c31n/stratux-serialout_test.img.zip?dl=0 + http://amzn.com/B0007T27H8. I've bench tested it.

I'm sure there's user demand for a serial out option. I don't have an EFIS (funny, just wrote a blog post about that) but I bet there are plenty of people over on vansairforce.net who would probably jump at the chance.

I would love an "IN" so I could feed the ZAON data into WingX via Stratux WIFI - currently its either ZAON or Stratux I have connected via Wifi.
The iLevil products allows you connect ZAON serially to it and it feeds both ADS-B and ZAON traffic.
Maybe I am the last of a dying breed using ZAON but its on every flight.

ZAON send out GDL90?

Don't have the documentation at hand but @HiltonG might know, he implemented it into WingX about 3+ years ago.

First package I ran on my mac with my first SDR was GQRX.  Had it tune my field's Unicom and zap!
Nice AM reception on 122.72 MHz with reasonable sensitivity using the supplied short whip.
Equivalent code exists for the Pi. Unlikely that the AM receiver code would co-execute
with Stratux, and  it needs a terminal front-end for tuning, setting demodulation, etc.
Probably cheaper and more practical to get a receive-only airband handheld receiver.
Of course, if you want to experiment, one could rewrite the Pi version of GQRX or RTL-SDR
to use a wifi link to a tablet front-end and maybe even bluetooth audio out receiver

It's interesting in part as an experiment, and in part because of the price
point. VHF COM is nice, but I think the "money" is probably VOR / ILS. You
could never get it certified, but it could make one heck of a good backup.
On Sat, Jan 23, 2016 at 6:08 PM, 224XS<EMAIL_ADDRESS>wrote:

First package I ran on my mac with my first SDR was GQRX. Had it tune my
field's Unicom and zap!
Nice AM reception on 122.72 MHz with reasonable sensitivity using the
supplied short whip.
Equivalent code exists for the Pi. Unlikely that the AM receiver code
would co-execute
with Stratux, and it needs a terminal front-end for tuning, setting
demodulation, etc.
Probably cheaper and more practical to get a receive-only airband handheld
receiver.
Of course, if you want to experiment, one could rewrite the Pi version of
GQRX or RTL-SDR
to use a wifi link to a tablet front-end and maybe even bluetooth audio
out receiver
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/215#issuecomment-174235982.

--
Steven Sokol
408 Camelot Drive
Liberty, MO 64068
mobile: +1<PHONE_NUMBER>
fax: +1<PHONE_NUMBER>

I like the idea of a backup receiver. But the ability to easily tune the freq is a bit of a task. I would assume I would have open the webGUI and enter the freq there. That seems cumbersome.
If it was possible to have the EFB sent http or ssh commands to switch an SDR and stream or send to audio out and use an adaptor for your headset or something like that.
You could get the ATIS at the APT that way for sure
Some might say the backup receiver would be an option but to be useful you would need an amplified speaker or hook up your headset. if your headset is hooked up then you cannot use the a/c transmitter(if working).
As an AirTraffic Controller I can tell you that if you have a com fail it would be nice to still be able to hear ATC. "If you can hear the tower, IDENT" type stuff.
As far as ILS. AHRS should be enough in an emergency? The VOR is an option but now it looks like an APP would be needed to handle to custom capabilities of the "FlightBox"
If there was a companion APP to the Flight Box then we could take full advantage of any "extra" functionality we would like to add. On android I can envision an APP that has a status bar icon when connected to the "Stratux" SSID that way any other functions can be accessed quickly. The app could function in an overlay to the current active application allowing you to change functions without leafing the EFB app

Consolidating to #228.


Feature sync date and date time format separator

Basic information

nrich version:
1.2.1
Module:
nrich-search, nrich-registry

Additional information

Description
Summary
Sync date and date time format separators.
Details
Sync date and date time format separators.
Related issue
https://github.com/croz-ltd/nrich/issues/77
Types of changes

Refactoring

Checklist

[x] I have read the project's CONTRIBUTING document
[x] I have checked my code with the project's static analysis tooling
[x] I have formatted my code with the project's IDEA code-style configuration
[x] I have checked my code for misspellings
[x] I have organized my changes in easy-to-follow commits
[x] My change requires a change to the documentation
[x] I have updated the documentation accordingly
I have added tests to cover my changes
[x] All new and existing tests pass.

Please also move the date formats in the excel modules to dd-MM-yyyy and other than that everything looks fine.

Changed them all with dot separator since thats what we'll be using mostly so no need for this.


FileSystemException: FileSystemException: Cannot copy file

I have been having this issue for a while now and I have tried to change my Flutter SDK directory as well but it is not working.
FileSystemException: FileSystemException: Cannot copy file to 'C:\Users\DELL\Documents\Flutter\tutorial\android\app\src\main\res\mipmap-hdpi\ic_launcher.png', path = 'C:\Users\DELL\Documents\Apps\flutter\packages\flutter_tools\templates\app\android.tmpl\app\src\main\res\mipmap-hdpi\ic_launcher.png' (OS Error: Access is denied.
, errno = 5)

Hi @UncleSam-tech
I see there's an open issue (https://github.com/flutter/flutter/issues/69116) addressing the case you described.
Please follow up on that issue, I'm closing the current one as a duplicate.
If you disagree, please write in the comments and I will reopen it.
Thank you

Okay, but please can I get a solution today.

I'm not sure about that.
This usually happens when Flutter is installed in a directory where he does not have sufficient permissions to copy/read/write. You can try give permissions to Flutter or move Flutter SDK to a different directory.

I have done all this and it is still the same error I get.


[Question] [ws-sdk] Have an issue with the call_ws_api function.

The call_ws_api function started hung on the deleteProduct request  about a month ago.
I used it with the ws-sdk~=<IP_ADDRESS>
I use such a function to remove old products:
def delete_product(ws_conn, conf, token) :
    request_type = "deleteProduct"
    kv_dict = { "userKey": f"{conf['ws_user_key']}",
                "orgToken" : f"{conf['ws_token']}",
                'productToken': f"{token}"
    }
    result = ws_conn.call_ws_api(request_type, kv_dict)
    logger.info(f" {result}")

A you can see from logs I got the "Expiring request cache " issue after 2 min timeot. If I have a lot of products to delete it works 30+ minutes until token expires and code failes in the middle of work.
INFO 23-05-29 06:30:27<PHONE_NUMBER>72832 sdk: Deleting Product:  name: LL-Enterprise - v14.5.0
DEBUG 23-05-29 06:30:27<PHONE_NUMBER>72832 ws_sdk.web: Calling: https://saas-eu.whitesourcesoftware.com/api/v1.3 with requestType: deleteProduct
DEBUG 23-05-29 06:32:48<PHONE_NUMBER>72832 requests_cache.session: Pre-cache checks for response from https://saas-eu.whitesourcesoftware.com/api/v1.3: {'disabled cache': False, 'disabled method': False, 'disabled status': False, 'disabled by filter': False, 'disabled by headers or expiration params': False}
DEBUG 23-05-29 06:32:48<PHONE_NUMBER>72832 ws_sdk.web: Expiring request cache
DEBUG 23-05-29 06:32:48<PHONE_NUMBER>72832 ws_sdk.web: API deleteProduct call on orgToken ***secretToken*** succeeded
INFO 23-05-29 06:32:48<PHONE_NUMBER>72832 sdk:  {'message': 'Successfully deleted product LL-Enterprise - v14.5.0'}

after I have updated ws-sdk to the latest version it started hang forever on this deleteProduct api call.

As I see API call removes Product, but don't give any responce successfull or not, and function hungs waiting for API responce.

Latest update. It start hung forever:
INFO 23-05-31 18:41:46<PHONE_NUMBER>39456 sdk:  {'message': 'Successfully deleted product Stream - v9.82.0'}
INFO 23-05-31 18:41:46<PHONE_NUMBER>39456 sdk: Deleting Product:  name: Stream - v9.81.2
DEBUG 23-05-31 18:41:46<PHONE_NUMBER>39456 ws_sdk.web: Calling: https://saas-eu.whitesourcesoftware.com/api/v1.3 with requestType: deleteProduct
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 466, in _make_request
    six.raise_from(e, None)
  File "<string>", line 3, in raise_from
  File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 461, in _make_request
    httplib_response = conn.getresponse()
  File "/usr/local/lib/python3.7/http/client.py", line 1373, in getresponse
    response.begin()
  File "/usr/local/lib/python3.7/http/client.py", line 319, in begin
    version, status, reason = self._read_status()
  File "/usr/local/lib/python3.7/http/client.py", line 280, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/usr/local/lib/python3.7/socket.py", line 589, in readinto
    return self._sock.recv_into(b)
  File "/usr/local/lib/python3.7/ssl.py", line 1071, in recv_into
    return self.read(nbytes, buffer)
  File "/usr/local/lib/python3.7/ssl.py", line 929, in read
    return self._sslobj.read(len, buffer)
socket.timeout: The read operation timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/requests/adapters.py", line 449, in send
    timeout=timeout
  File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 799, in urlopen
    method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2]
  File "/usr/local/lib/python3.7/site-packages/urllib3/util/retry.py", line 550, in increment
    raise six.reraise(type(error), error, _stacktrace)
  File "/usr/local/lib/python3.7/site-packages/urllib3/packages/six.py", line 770, in reraise
    raise value
  File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 721, in urlopen
    chunked=chunked,
  File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 468, in _make_request
    self._raise_timeout(err=e, url=url, timeout_value=read_timeout)
  File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 358, in _raise_timeout
    self, url, "Read timed out. (read timeout=%s)" % timeout_value
urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='saas-eu.whitesourcesoftware.com', port=443): Read timed out. (read timeout=3600)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/ws_sdk/web.py", line 194, in call_ws_api
    resp = self.session.post(url=self.api_url, data=json.dumps(body), headers=self.headers, timeout=self.timeout)
  File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 590, in post
    return self.request('POST', url, data=data, json=json, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/requests_cache/session.py", line 122, in request
    **kwargs,
  File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 542, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python3.7/site-packages/requests_cache/session.py", line 148, in send
    response = self._send_and_cache(request, actions, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/requests_cache/session.py", line 178, in _send_and_cache
    response = super().send(request, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 655, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/requests/adapters.py", line 529, in send
    raise ReadTimeout(e, request=request)
requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='saas-eu.whitesourcesoftware.com', port=443): Read timed out. (read timeout=3600)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/src/app/product_clean.py", line 166, in <module>
    main()
  File "/usr/src/app/product_clean.py", line 163, in main
    delete_product(ws_conn, conf, prod[2])
  File "/usr/src/app/product_clean.py", line 89, in delete_product
    result = ws_conn.call_ws_api(request_type, kv_dict)
  File "/usr/local/lib/python3.7/site-packages/ws_sdk/web.py", line 196, in call_ws_api
    logger.exception(f"Received Error on {body[token[-1]]}")
KeyError: 'n'
[Pipeline] echo
hudson.AbortException: script returned exit code 1

An issue was solwed on Jun 7, 2023


Use our own lock for SystemProperties methods

We attempted to coordinate all access to system properties
for maximum security, but that didn't work out because it
also prevented reads from other threads while someone was
holding the lock. This is no longer a problem on Java 9,
but a deadlock is possible on Java 8.
We now only coordinate our own writes and accept that some
3rd party code may use setProperty() and bypass our checks
that way.
Fixes https://github.com/gradle/gradle-private/issues/1460

Done.

I wanted to rebase this onto release and ended up just pushing it.

I think this change reintroduces #6175 because the underlying issue was some user code calling System.setProperty(...) while Ivy code was iterating over System.getProperties().

I thought it was because of our JavaCompile task calling System.setProperty. In any case, I don't see how we can have both, given that Ant both

iterates over the properties without copying
logs, which causes us to acquire another lock

We could remove the path that accesses the system property in the logging infrastructure, but I agree that there's not a great solution here.

Starting with Java 9 it no longer synchronizes on reads. So we could use different locks depending on the Java version as another approach.