Re: [Tigervnc-devel] [PATCH] add resolutions to the default randr resolutions

2011-05-19 Thread Sebastiaan Breedveld
On 05/19/2011 11:46 AM, Pierre Ossman wrote:
 On Fri, 04 Mar 2011 10:07:09 +0100
 Sebastiaan Breedvelds.breedv...@erasmusmc.nl  wrote:

 On 03/03/2011 09:34 PM, Sebastiaan Breedveld wrote:
 Hi,

 Here is another patch. It adds a -resolutions argument with a list of
 resolutions to add to the default list:
 Xvnc -resolutions 1264x900 1400x1500

 Hi Sebastiaan,

 It seems this didn't provoke any major interest from the rest of the
 community. This is probably a good idea though, and it would be a shame
 if your efforts were wasted. Could you add a feature request entry in
 the Sourceforge tracker for this? Please include you patch as an
 attachment.

 Thanks
There weren't much hurray's :(

I was already planning to submit the patches on SF, but I wanted to 
check if they still apply well in the current version. Which is the 
(preferred) tree I should patch it against?

I hope to have time in the next 2 weeks to look after TigerVNC again.

Thanks!
Sebastiaan


--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] New pre-beta build

2011-03-18 Thread Sebastiaan Breedveld


On 03/16/2011 09:59 PM, Eric Stadtherr wrote:


On Wed, 16 Mar 2011 15:50:53 -0500, DRC wrote:


http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases

-- Reverts default behavior of vncserver but adds a 'vncserver
-autokill' option that will automatically kill Xvnc whenever xstartup exits.




How does this interact with the -once option to Xvnc?

% Xvnc --help

...

-once  Terminate server after one session

...


I think this option is only valid in combination with -inetd. It does 
not influence anything when run normally with Xvnc.





--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] New pre-beta build

2011-03-18 Thread Sebastiaan Breedveld

On 03/16/2011 09:50 PM, DRC wrote:
 http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases

 -- Reverts default behavior of vncserver but adds a 'vncserver
 -autokill' option that will automatically kill Xvnc whenever xstartup exits.

Builds fine, runs fine (Linux 64). No comments from me on this one.



--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] Refresh issue with GnuTLS and status of beta

2011-03-15 Thread Sebastiaan Breedveld
Hi,

3 points this time ;)

On 03/15/2011 09:45 AM, DRC wrote:
 I have lost track of the status of this.  Can anyone still reproduce a
 problem with the latest build I uploaded on 3/10?  If not, then I will
 spin a new build to incorporate the vncserver changes (reverting the
 default behavior + fixing vncserver -fg), and I think we'll be ready
 for beta.

1) The new vncserver script does something weird with -fg. When I use 
this switch, xfce4 refuses to start with:

Unable to contact settings server. Failed to connect to socket 
/tmp/dbus-GBOh4ZTlHF: Connection refused.

The culprit is the close(STDIN). I also cannot reproduce your behaviour:

  My assertion that 'vncserver -fg ' would produce the same behavior
was incorrect. If I did that, then pressing Enter would stop the job. I 
had to also close STDIN to make it work correctly.

as vncserver -fg 

works perfectly for me. Maybe this depends on the WM. When I run 
'startxfce4', I cannot put the job in the background (only closing the 
terminal very quickly works). However, I am using xfce4 now without the 
vncserver script problem.

This has to be figured out, as the WM does not start properly with 
close(STDIN) for me, and without for you. I have this on 2 different 
systems (Ubuntu lucid and natty-alpha).


2)
As for the Windows viewer: no delays have been noted.


3) I noticed that when moving a window left, the window looks garbaged. 
Moving into other directions is fine. Forcing a redraw (moving it 
vertically off/on the screen or switch desktop) works fine. Not all 
windows have this, but e.g. Thunar has. Both the Linux and Windows 
viewer have this. It is just a bit annoying sometimes, but I do not 
think we have to fix this in the beta. But attention should be payed later.

Greetings,
Sebastiaan


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread Sebastiaan Breedveld


  
  
It seems that the -fg was implemented differently than expected:

diff between old and new
-system("$vncUserDir/xstartup  " .
quotedString($desktopLog) . " 21 ");
+if ($opt{'-fg'}) {
+ system("$vncUserDir/xstartup  " .
quotedString($desktopLog) . " 21");
+ if (kill 0, `cat $pidFile`) {
+ $opt{'-kill'} = ':'.$displayNumber;
+ Kill();
+ }
+} else {
+ system("($vncUserDir/xstartup; $0 -kill :$displayNumber)
 " . quotedString($desktopLog) . " 21 ");
+}

Seems like a wrongly patched file, as both strings now contain a
kill. The attached patch should fix it.

The new behaviour should only be invoked when adding the -fg switch.
If omitted, nothing should be different.

Sebastiaan





On 03/11/2011 03:25 PM, Robert Goley wrote:

  
  Just to throw my 2 cents in as well... I would prefer this
  behavior be reverted as well. I know it will end up causing us
  problems if for no other reason than window managers crash and we
  don't want everything else in our session to be taken down with
  them
  
  Robert
  
  
  On 03/11/2011 06:57 AM, Adam Tkac wrote:
  
On Thu, Mar 10, 2011 at 07:07:17AM -0600, DRC wrote:


  http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases

-- Windows TLS refresh issue fixed (I hope)
-- New vncserver -fg switch for running TigerVNC in grid environments
-- vncserver now automatically kills Xvnc whenever the window manager
running in the VNC session is exited


I'm quite reserved about this behavior, I would rather not kill the
Xvnc when WM exits.

Default .vnc/xstartup (generated by vncserver) file has following
lines:
...
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" 
twm 

So WM is actually successfully started but patched vncserver kills Xvnc
immediately.

In my opinion vast majority of VNC users start WM on the background
(with the "" character in the end of the script) and this change will
break all existing configurations.

In my opinion this change should be reverted.

Regards, Adam



  -- vncserver will no longer prompt user to create a VNC password if VNC
auth is not used
-- TLS support incorporated into Windows Visual C++ 32-bit build, so it
isn't necessary to use a separate installer for TLS support (note: Win64
support for TLS is still not there, because GnuTLS does not yet work
cleanly with the LLP64 data model.)

Enjoy!

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


  
  
  -- 
Robert Goley
  
  FOSS
Implementation Specialist
Toll Free: (800) 338-4984
Local: (770) 479-7933
Fax: (770) 479-4076
www.openrda.com
  
  America's only Free  Open Source
  fund accounting software company. 
  
  

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
  

___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel



  

--- vncserver.bad	2011-03-10 10:26:14.032313875 +0100
+++ /usr/bin/vncserver	2011-03-11 15:40:49.0 +0100
@@ -344,7 +344,7 @@
 Kill();
 }
 } else {
-system(($vncUserDir/xstartup; $0 -kill :$displayNumber)   . quotedString($desktopLog) .  21 );
+system($vncUserDir/xstartup   . quotedString($desktopLog) .  21 );
 }
 
 exit;
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] Improvements for Windows installer

2011-03-10 Thread Sebastiaan Breedveld

On 03/09/2011 11:31 PM, Robert Goley wrote:
It should at least have one of the improvements you suggested 
implemented.  I understand not wanting to invest much with a new 
viewer on the way but it sounds like it has a good bit to go right 
now.  That is not slighting his accomplishments in getting the viewing 
portion of it working on all platforms.  The mouse, keyboard and GUI 
are likely to take a bit of time.  Even hard setting some window 
redraws would be a welcome improvement over the current Windows viewer 
behavior.  I think it would be a good thing to do before 1.1.  My 2 
cents anyway.  This issue holds me up from letting more of my users 
work with TigerVNC and test it.


Robert

+1 for some fix in the 1.1 release. The client is pretty useless now 
when using TLS. I do not think that a beta release should be released 
with known bugs.


Sebastiaan




On 03/09/2011 05:13 PM, Martin Koegler wrote:

On Tue, Mar 08, 2011 at 08:33:20PM -0600, DRC wrote:

Windows is still suffering from the TLS refresh issue described earlier.
  It affects VirtualGL as well (you have to move the mouse to see the 3D
application change frames.)  I don't have the time to look into this at
the moment, but IMHO, it should be fixed before we release 1.1 beta.

Changing the priority of events (I could sent it as patch, if
requested) should improve this issue.

To get the full frame rate on the user display, you probably have to
investigate, how often to force a window update and need something
like tcbench for windows to verify the result.

Or should we ignore the problem, as we get a new common viewer?

Regards,
Martin Kögler





--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] [PATCH] vncserver checks ~/.vnc/passwd when not needed and -TermOnLogout option

2011-03-10 Thread Sebastiaan Breedveld

On 03/09/2011 07:58 AM, DRC wrote:

Committed as 4343, with modifications.  Please test.

Does not work right. If one of the checked arguments (SecurityTypes, 
rfbauth, etc.) is preceeded by an argument that is NOT processed by the 
vncserver script, but passed on to the Xvnc, the argument reading is off 
by 1.


E.g.:

vncserver -SecurityTypes none
works, but:
vncserver :1 -SecurityTypes none
fails.

Even so:
vncserver -fg -SecurityTypes none
works, and
vncserver :1 -AlwaysShared -SecurityTypes none
works as well

Problem is that the ARGV counter is increased when doing ++$i. Using 
$i+1 does not increase the loop counter, and leaves it up to the 
if-statements below if the added argument makes sense.


Now the patch, as attachment ;) Last time I have been on a mailing list, 
attachments were rejected (yes, it has been a long time since).


Sebastiaan


--- vncserver	2011-03-10 08:41:40.0 +0100
+++ /usr/bin/vncserver	2011-03-10 10:26:14.032313875 +0100
@@ -171,7 +171,7 @@
 # -SecurityTypes can be followed by a space or =
 my @splitargs = split('=', $ARGV[$i]);
 if (@splitargs = 1  $i  @ARGV - 1) {
-push(@splitargs, $ARGV[++$i]);
+push(@splitargs, $ARGV[$i+1]);
 }
 if (lc(@splitargs[0]) eq -securitytypes) {
 if (@splitargs  1) {
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] [PATCH] add resolutions to the default randr resolutions

2011-03-04 Thread Sebastiaan Breedveld

On 03/03/2011 09:34 PM, Sebastiaan Breedveld wrote:

Hi,

Here is another patch. It adds a -resolutions argument with a list of 
resolutions to add to the default list:

Xvnc -resolutions 1264x900 1400x1500

Of course this is a more flexible approach than specifying only 1 with 
the -geometry. Also, window managers tend to resize to the users' 
specified resolution (at least xfce does). It also allows adding odd 
screen resolutions (maybe someone frequently uses vnc viewer on his 
cell phone?).


My main purpose for this is that I want to add a list of pseudo 
resolutions, which gives the user a screen-filling window approach 
which does not hide the task bar: e.g. 1264x900 fits on a 1280x1024 
display.


Of course this can be done by using cvt and xrandr a couple of times, 
but that is quite a hassle.


I have 2 questions about this:
1) are there any restrictions on the resolutions? (e.g. divisable by 2 
or so?)
2) How can one use quotation marks in inetd? When called from inetd, 
the quotation marks are ignored.


Ok, answers come after a good nights sleep. In stead of a quotated 
string, supply the resolutions in a comma separated list:

Xvnc -resolutions 1264x900,1400x1500

so the inetd issue is resolved (although I am still interested in the 
answer).


There also does not seem to be much limitations on the resolutions, but 
the server crashes for anything smaller than 4x4 pixels.


Using 'cvt 1 1' forces the resolution to 8x1, which seems to be ok. 
Nevertheless, I guess it is a good choice to set the minumum to 64x64.



One more thing: the action is now to add these resolutions to the 
default (hard coded) list. Would it maybe more interesting to replace 
the whole list?


Greetings,
Sebastiaan



--- ../../../../unix/xserver/hw/vnc/xvnc.cc2011-02-21 
16:05:15.0 +0100

+++ xvnc.cc2011-03-04 10:00:16.798650722 +0100
@@ -78,6 +78,11 @@
 #include inputstr.h
 #ifdef RANDR
 #include randrstr.h
+/* Set default resolutions */
+#define RANDRMAXDISPLAYS 100
+static int RandRwidths[RANDRMAXDISPLAYS] =  { 1920, 1920, 1600, 1680, 
1400, 1360, 1280, 1280, 1280, 1280, 1024, 800, 640};
+static int RandRheights[RANDRMAXDISPLAYS] = { 1200, 1080, 1200, 1050, 
1050,  768, 1024,  960,  800,  720,  768, 600, 480};

+static int RandRNumDisplays = 13;
 #endif /* RANDR */
 #include X11/keysym.h
   extern char buildtime[];
@@ -170,7 +175,6 @@

 char *listenaddr = NULL;

-
 static void
 vfbInitializePixmapDepths(void)
 {
@@ -292,6 +296,7 @@
 ErrorF(-inetd has been launched from inetd\n);
 ErrorF(-interface IP_address  listen on specified interface\n);
 ErrorF(-noclipboard   disable clipboard settings 
modification via vncconfig utility\n);
+ErrorF(-resolutions X1xY1,X2xY2,... additional screen resolutions 
for RandR\n);

 ErrorF(\nVNC parameters:\n);

 fprintf(stderr,\n
@@ -575,6 +580,54 @@
 noclipboard = true;
 return 1;
 }
+
+if (strcmp(argv[i], -resolutions) == 0) {
+if (++i = argc) {
+UseMsg();
+return 2;
+}
+#ifdef RANDR
+/* Read the resolution string in pieces */
+int width, height, offset = 0;
+char ResString[20];
+
+while (offsetstrlen(argv[i])  sscanf(argv[i]+offset, 
%19[^','], ResString) == 1)

+{
+/* Read width and height */
+if (sscanf(ResString, %dx%d, width, height)==2 )
+{
+/* Offset + 1 to skip the space */
+offset = offset + strlen(ResString) + 1;
+
+/* Check if resolutions are sane */
+if (width64  height64)
+{
+/* Add resolution to list */
+if ( (RandRNumDisplays+1)RANDRMAXDISPLAYS )
+{
+RandRwidths[RandRNumDisplays] = width;
+RandRheights[RandRNumDisplays] = height;
+RandRNumDisplays++;
+} else
+{
+ErrorF(Too many resolutions specified!\n);
+}
+} else
+{
+ErrorF(Insane resolution of %d x %d specified!\n, 
width, height);

+return 2;
+}
+} else
+{
+ErrorF(Malformed resolution string at: %s , argv[i]+offset);
+ErrorF(Ignoring remainder!);
+return 2;
+}
+}
+#endif
+return 2;
+}
+

 if (rfb::Configuration::setParam(argv[i]))
 return 1;
@@ -846,13 +899,10 @@
   Bool ret, gotCurrent = FALSE;
   int i;

-  const int widths[] =  { 1920, 1920, 1600, 1680, 1400, 1360, 1280, 
1280, 1280, 1280, 1024, 800, 640 };
-  const int heights[] = { 1200, 1080, 1200, 1050, 1050,  768, 1024,  
960,  800,  720,  768, 600, 480 };

-
-  for (i = 0;i  sizeof(widths)/sizeof(*widths);i++) {
+  for (i = 0;i  RandRNumDisplays; i++) {
 RRScreenSizePtr pSize;

-pSize = RRRegisterSize(pScreen, widths[i], heights[i],
+pSize = RRRegisterSize(pScreen, RandRwidths[i], RandRheights[i

Re: [Tigervnc-devel] [PATCH] vncserver checks ~/.vnc/passwd when not needed and -TermOnLogout option

2011-03-03 Thread Sebastiaan Breedveld
This patch needs another line modified, to display the option when run 
with vncserver -h.

The second patch is for the man-page (I have not updated the date of the 
page, I will leave that to you).

Index: unix/vncserver
===
--- unix/vncserver  (revision 4301)
+++ unix/vncserver  (working copy)
@@ -122,7 +122,7 @@
  # Check command line options

  ParseOptions(-geometry,1,-depth,1,-pixelformat,1,-name,1,-kill,1,
- -help,0,-h,0,--help,0,-fp,1,-list,0);
+ -help,0,-h,0,--help,0,-fp,1,-list,0,-fg,0);

  Usage() if ($opt{'-help'} || $opt{'-h'} || $opt{'--help'});

@@ -306,7 +306,15 @@
  }
  $ENV{VNCDESKTOP}= $desktopName;

-system($vncUserDir/xstartup   .quotedString($desktopLog) .  21);
+if ($opt{'-fg'}) {
+system($vncUserDir/xstartup   .quotedString($desktopLog) .  21);
+if (kill 0, `cat $pidFile`) {
+$opt{'-kill'} = ':'.$displayNumber;
+Kill();
+}
+} else {
+system($vncUserDir/xstartup   .quotedString($desktopLog) .  21);
+}

  exit;
@@ -527,6 +535,7 @@
   [-geometrywidthxheight]\n.
   [-pixelformat rgbNNN|bgrNNN]\n.
   [-fpfont-path]\n.
+ [-fg]\n.
  Xvnc-options...\n\n.
 $prog -killX-display\n\n.
 $prog -list\n\n);



Patch for man:

--- vncserver.1.org2011-03-03 11:09:13.209078453 +0100

+++ vncserver.12011-03-03 11:11:15.807863890 +0100

@@ -14,6 +14,7 @@

  .IR format ]

  .RB [ \-fp

  .IR font-path ]

+.RB [ \-fg]

  .RI [ Xvnc-options... ]

  .br

  .BI vncserver \-kill : display#

@@ -105,6 +106,11 @@

  argument allows you to override the above fallback logic and specify a font

  path for Xvnc to use.

  

+.TP

+.B \-fg

+Run vncserver in the foreground. On finishing the Xsession (i.e. user logs

+out from its desktop) the VNC session is also terminated.

+

  .SH FILES

  Several VNC-related files are found in the directory $HOME/.vnc:

  .TP





--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


[Tigervnc-devel] [PATCH] specify inetd display range

2011-03-03 Thread Sebastiaan Breedveld
Hi,

In our environment, we have users that run persistent VNC sessions, and 
on request through inetd. For ease of reminding, I like to give the 
persistent users a low display number (e.g. 1-20). The problem is that a 
new persistent user may have its display blocked by an inetd session.

Therefor I like to specify a display range that inetd can use. The 
following patch allows an optional argument for inetd:
Xvnc -inetd 20-100; % uses displays 20-100
Xvnc -inetd; % uses the default 1-99

Greetings,
Sebastiaan

Ps: while testing incorrect input, I noticed that incorrect input is 
ignored by default. E.g. Xvnc -screen -1 10x20x24 only gives a message 
and the usage options, but runs Xvnc ignoring the incorrect argument.





--- ../../../../unix/xserver/hw/vnc/xvnc.cc2011-02-21 
16:05:15.0 +0100
+++ xvnc.cc2011-03-03 13:58:06.209531786 +0100
@@ -289,7 +289,8 @@
  ErrorF(-geometry WxH  set screen 0's width, height\n);
  ErrorF(-depth D   set screen 0's depth\n);
  ErrorF(-pixelformat fmt   set pixel format (rgbNNN or 
bgrNNN)\n);
-ErrorF(-inetd has been launched from inetd\n);
+ErrorF(-inetd [Start-End] has been launched from inetd\n);
+ErrorF(   Optionally, a display range can be 
given.\n);
  ErrorF(-interface IP_address  listen on specified interface\n);
  ErrorF(-noclipboard   disable clipboard settings 
modification via vncconfig utility\n);
  ErrorF(\nVNC parameters:\n);
@@ -532,26 +533,43 @@

  if (strcmp(argv[i], -inetd) == 0)
  {
+/* Check for optional argument */
+int DisplayStart=1, DisplayEnd=99;
+int argsread = 1;
+
+if ((i+1argc)  (sscanf(argv[i+1],%d-%d,DisplayStart,
+ DisplayEnd) == 2))
+{
+/* Display range argument was specified, check range */
+if (DisplayStart0 || DisplayStartMAXSCREENS || 
DisplayEnd0 || DisplayEnd  MAXSCREENS || DisplayStartDisplayEnd)
+{
+ErrorF(Invalid inetd port range %s\n, 
argv[i+1]);
+UseMsg();
+}
+argsread = 2;
+}
+
  dup2(0,3);
  vncInetdSock = 3;
  close(2);
-
+
  if (!displaySpecified) {
  int port = network::TcpSocket::getSockPort(vncInetdSock);
  int displayNum = port - 5900;
-if (displayNum  0 || displayNum  99 || 
!displayNumFree(displayNum)) {
-for (displayNum = 1; displayNum  100; displayNum++)
+if (displayNum  DisplayStart || displayNum  DisplayEnd || 
!displayNumFree(displayNum)) {
+for (displayNum = DisplayStart; displayNum  DisplayEnd; 
displayNum++)
  if (displayNumFree(displayNum)) break;

-if (displayNum == 100)
+if (displayNum == DisplayEnd+1)
  FatalError(Xvnc error: no free display number for -inetd);
  }

  display = displayNumStr;
  sprintf(displayNumStr, %d, displayNum);
+
  }
-
-return 1;
+return argsread;
  }

  if (strcmp(argv[i], -interface) == 0 ||


--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] [PATCH] vncserver checks ~/.vnc/passwd when not needed and -TermOnLogout option

2011-03-02 Thread Sebastiaan Breedveld

Hi,

On 03/01/2011 06:48 PM, Robert Goley wrote:
My understanding is that they were going to change the auth code so 
that it defaulted to using VeNCrypt so that you would no longer have 
to specify it on the command line.  You would however have to set the 
method priority.  The method priority would default to VncAuth for 
compatibility.  I do not know if that was completed or is in the 
current binaries that DRC built.  I am running the same binaries and I 
am still specifying in the old manner.  I have not tested the short 
form using them.  I was not sure if that work was completed yet.


Again this is my understanding from following that thread.  If 
anything in my 2 cents above is incorrect, please jump in let me know.


Working on understanding too: if VeNCrypt would be the default, the 
authentication is always done using PAM. However, a 'vnc' pam file is 
not present by default. It is also not trivial to make one since each 
distribution has its own way of configuring pam. I would suggest to 
default to /etc/pam.d/vnc if present, otherwise use /etc/pam.d/login 
(which is present on all systems).


Sebastiaan




Robert


On 03/01/2011 08:10 AM, Sebastiaan Breedveld wrote:

On 03/01/2011 12:13 PM, DRC wrote:

As far as checking for the VNC password, we're no longer requiring
VeNCrypt to be specified in the -SecurityTypes parameter, so checking
for that won't work.  The correct approach is to check whether
-SecurityTypes is not specified -- or -- whether -SecurityTypes is
specified and contains (case insensitive) VncAuth.  If either of those
conditions is true, then and only then should vncserver check for the
existence of the VNC password.


Looking at it again, the vncserver script adds --rfbauth automatically,
so a more structural change is necessary:

- if no options are given, force VeNCrypt, and do not use --rfbauth anymore
- force VeNCrypt by specifying SecurityTypes, and do not use --rfbauth
in that case

Or am I misunderstanding something?

Greetings,
Sebastiaan



--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


[Tigervnc-devel] [PATCH] vncserver checks ~/.vnc/passwd when not needed and -TermOnLogout option

2011-03-01 Thread Sebastiaan Breedveld
Hi all,

This is actually a 2-in-1 patch (not sure if that is a good idea). I ran 
into 2 problems with the old version:

1) When a VNC desktop is running, most users (accidentally) log out once 
or twice, and then complain that their screen is black (or worse, has a 
ghost image of the desktop). The users are usually not very interested 
in what went wrong, they want to be able to simply restart the desktop. 
I share their opinion, since the vncserver script is set-up in such a 
way that it starts a virtual desktop (rather than X alone), and on 
logout, no one is happy with an empty X session.

I have added an option -TermOnLogout to the script, which runs vncserver 
-kill after the desktop was shut down. The patch was inspired from here:
http://markmail.org/message/wh6avdxdbqm5kfwu#query:terminate%20vncserver%20on%20logout+page:1+mid:apdzqspklbhhhcdj+state:results

(Optionally, the vncserver script can be run with an  so users can log 
out of their shell.)


2) When using the VeNCrypt security type, the ~/.vnc/passwd is not 
necessary, yet the user is asked to create one. Same when using the 
securitytype none. The script now checks for the -SecurityType option 
and checks wether VeNCrypt type or none is specified. (That is, I am in 
the assumption that the VeNCrypt type does not use the vnc password.)


Greetings,
Sebastiaan

--- /usr/bin/vncserver2011-01-24 00:23:33.0 +0100
+++ vncserver2011-03-01 10:34:01.0 +0100
@@ -121,7 +121,7 @@
  # Check command line options

ParseOptions(-geometry,1,-depth,1,-pixelformat,1,-name,1,-kill,1,
-  -help,0,-h,0,--help,0,-fp,1);
+  -help,0,-h,0,--help,0,-fp,1,-TermOnLogout, 0);

Usage() if ($opt{'-help'} || $opt{'-h'} || $opt{'--help'});

@@ -146,6 +146,25 @@
  $fpArgSpecified = 1;
  }

+# Check the arguments to check if the VeNCrypt security type is set
+# If so, there is no need for a user password
+$needvncpass = 1;
+foreach $arg (@ARGV) {
+my @splitargs = split('=', $arg);
+
+if (lc(@splitargs[0]) eq -securitytypes)
+{
+my @splitargs2 = split(',', @splitargs[1]);
+
+if ((lc(@splitargs2[0]) eq vencrypt) || (lc(@splitargs2[0]) 
eq none))
+{
+# No password necessary
+$needvncpass = 0;
+}
+}
+}
+
+
CheckGeometryAndDepth();


@@ -157,14 +176,17 @@
  }
  }

-# Make sure the user has a password.

-($z,$z,$mode) = stat($vncUserDir/passwd);
-if (!(-e $vncUserDir/passwd) || ($mode  077)) {
-warn \nYou will require a password to access your desktops.\n\n;
-system($exedir.vncpasswd -q $vncUserDir/passwd);
-if (($?  8) != 0) {
-exit 1;
+# Make sure the user has a password, if required
+if ($needvncpass)
+{
+($z,$z,$mode) = stat($vncUserDir/passwd);
+if (!(-e $vncUserDir/passwd) || ($mode  077)) {
+warn \nYou will require a password to access your desktops.\n\n;
+system($exedir.vncpasswd -q $vncUserDir/passwd);
+if (($?  8) != 0) {
+exit 1;
+}
  }
  }

@@ -303,7 +325,16 @@
  }
  $ENV{VNCDESKTOP}= $desktopName;

-system($vncUserDir/xstartup   . quotedString($desktopLog) .  21 
);
+if ($opt{'-TermOnLogout'})
+{
+system($vncUserDir/xstartup   . quotedString($desktopLog) .  
21);
+system(vncserver -kill :$displayNumber);
+}
+else
+{
+system($vncUserDir/xstartup   . quotedString($desktopLog) .  
21 );
+}
+

  exit;

@@ -524,6 +555,7 @@
   [-geometry widthxheight]\n.
   [-pixelformat rgbNNN|bgrNNN]\n.
   [-fp font-path]\n.
+ [-TermOnLogout]\n.
   Xvnc-options...\n\n.
 $prog -kill X-display\n\n);
  }


--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] [PATCH] vncserver checks ~/.vnc/passwd when not needed and -TermOnLogout option

2011-03-01 Thread Sebastiaan Breedveld
Hi,

On 03/01/2011 12:13 PM, DRC wrote:
 TurboVNC implements this more simply as a vncserver -fg switch, which
 means run in the foreground.  It does the same thing you are doing
 below, except that it uses the built-in kill() function, which is safer
 than trying to invoke another instance of vncserver with -kill:

 if ($opt{'-fg'}) {
  system($vncUserDir/xstartup   .quotedString($desktopLog) . 
 21);
  if (kill 0, `cat $pidFile`) {
  $opt{'-kill'} = ':'.$displayNumber;
  Kill();
  }
 } else {
  system($vncUserDir/xstartup   .quotedString($desktopLog) . 
 21);
 }

 As you know, the implication of being able to kill Xvnc after the window
 manager exits is that vncserver has to run as a foreground process
 rather than returning control to the console.  CTRL-C'ing it will kill
 the session.  However, running vncserver as a foreground process is also
 necessary when used with most grid software.

 I would be OK with putting this same switch into TigerVNC, since it has
 been road tested with TurboVNC already.

Great! It is no problem that the control is not returned to the shell, 
since the vncserver script can be run in the background (vncserver ).

As for killing: the client always complains about something like Read 
failed: broken pipe. Isn't there a way to terminate the server nicely, 
or tell the viewer that the server was shut down? If not, this probably 
means a lot of programming to solve a non-problem.

 As far as checking for the VNC password, we're no longer requiring
 VeNCrypt to be specified in the -SecurityTypes parameter, so checking
 for that won't work.  The correct approach is to check whether
 -SecurityTypes is not specified -- or -- whether -SecurityTypes is
 specified and contains (case insensitive) VncAuth.  If either of those
 conditions is true, then and only then should vncserver check for the
 existence of the VNC password.

Then how does it work? If I start:

Xvnc :10

then I read on the server:
client requests security type VeNCrypt
but the client tries to authenticate with VncAuth.

The server then complains that neither Password or PasswordFile is set.


Apart from that, the vncserver script persistently adds the --rfbauth 
flag to ~/.vnc/passwd.



Greetings,
Sebastiaan


 DRC

 On 3/1/11 4:25 AM, Sebastiaan Breedveld wrote:
 Hi all,

 This is actually a 2-in-1 patch (not sure if that is a good idea). I ran
 into 2 problems with the old version:

 1) When a VNC desktop is running, most users (accidentally) log out once
 or twice, and then complain that their screen is black (or worse, has a
 ghost image of the desktop). The users are usually not very interested
 in what went wrong, they want to be able to simply restart the desktop.
 I share their opinion, since the vncserver script is set-up in such a
 way that it starts a virtual desktop (rather than X alone), and on
 logout, no one is happy with an empty X session.

 I have added an option -TermOnLogout to the script, which runs vncserver
 -kill after the desktop was shut down. The patch was inspired from here:
 http://markmail.org/message/wh6avdxdbqm5kfwu#query:terminate%20vncserver%20on%20logout+page:1+mid:apdzqspklbhhhcdj+state:results

 (Optionally, the vncserver script can be run with an  so users can log
 out of their shell.)


 2) When using the VeNCrypt security type, the ~/.vnc/passwd is not
 necessary, yet the user is asked to create one. Same when using the
 securitytype none. The script now checks for the -SecurityType option
 and checks wether VeNCrypt type or none is specified. (That is, I am in
 the assumption that the VeNCrypt type does not use the vnc password.)


 Greetings,
 Sebastiaan

 --- /usr/bin/vncserver2011-01-24 00:23:33.0 +0100
 +++ vncserver2011-03-01 10:34:01.0 +0100
 @@ -121,7 +121,7 @@
# Check command line options

 ParseOptions(-geometry,1,-depth,1,-pixelformat,1,-name,1,-kill,1,
 -  -help,0,-h,0,--help,0,-fp,1);
 +  -help,0,-h,0,--help,0,-fp,1,-TermOnLogout, 0);

 Usage() if ($opt{'-help'} || $opt{'-h'} || $opt{'--help'});

 @@ -146,6 +146,25 @@
$fpArgSpecified = 1;
}

 +# Check the arguments to check if the VeNCrypt security type is set
 +# If so, there is no need for a user password
 +$needvncpass = 1;
 +foreach $arg (@ARGV) {
 +my @splitargs = split('=', $arg);
 +
 +if (lc(@splitargs[0]) eq -securitytypes)
 +{
 +my @splitargs2 = split(',', @splitargs[1]);
 +
 +if ((lc(@splitargs2[0]) eq vencrypt) || (lc(@splitargs2[0])
 eq none))
 +{
 +# No password necessary
 +$needvncpass = 0;
 +}
 +}
 +}
 +
 +
 CheckGeometryAndDepth();


 @@ -157,14 +176,17 @@
}
}

 -# Make sure the user has a password.

 -($z,$z,$mode) = stat($vncUserDir/passwd);
 -if (!(-e $vncUserDir/passwd) || ($mode  077)) {
 -warn \nYou will require a password to access your desktops.\n\n;
 -system($exedir.vncpasswd -q $vncUserDir/passwd

Re: [Tigervnc-devel] PAM only works for local stored passwords

2011-02-26 Thread Sebastiaan Breedveld
Hi,

On 02/25/2011 11:16 PM, Martin Koegler wrote:
 On Fri, Feb 25, 2011 at 09:52:48AM +0100, Sebastiaan Breedveld wrote:
 Unfortunately, the radius configuration file contains a sectret
 string to authenticate against the Radius server, so it should not
 be world readable.

 I was actually under the impression that PAM is a query-service run
 as root: how else can a user be capable of obtaining root
 privellages by using su? Apparantly it works differently.

 Anyway, is there any way to make a construction to authenticate
 against a module with root-only readable configuration file as a
 normal user? (different than inetd/xdm, which does not have the
 features I need for this group of users).
 First, I would not set Xvnc setuid root - Xvnc is not written for such
 case. I would not be surprised, if such a setup can be used by a user
 to gain elevated privileges.

 If you really need such a setup, I would create a new radiusauth
 group, make the conf files group readable [maybe even with setfacl, if
 the normal group can not be changed] and make Xvnc setgid for this
 group [It can be possible, that you need to add calls to setregid to
 swap the gids]. In this setup, a user at most only get a copy of the
 radius conf files.

 A better solution would be to look for an pam module, which does not
 require extended privileges. Search, if there are pam modules
 authenticating against other services, which use your radius server -
 or pam modules which pass the autentification to a root owned daemon
 (sssd?).

 Regards,
 Martin Kögler
It seems that the sssd is the only correct approach. I have not heard of 
this project before but looks interesting. I will look into it later.

Thanks!
Sebastiaan


--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] PAM only works for local stored passwords

2011-02-25 Thread Sebastiaan Breedveld
Hi,

On 02/25/2011 09:13 AM, Martin Koegler wrote:
 tigervnc currently only uses the auth section - account, session and
 password are ignored.

 Xvnc simply passes username  password to pam and waits for the
 result. I have tested it for example with the pam_krb5 module
 successfully.

 The problem is, that some pam modules react differently, if they are
 invoked by root or a normal user.

 The debian pam_unix eg. let normal users only verify their own
 password and fails on any other user name. Other modules like pam_krb5,
 (also pam_ldap?) allow a normal user to verify the password of any user.

 I would check, if your pam_radius_auth has any config/data file, which
 are only root accessible. If that is the case, it will probably only
 work, if Xvnc runs as root [or gets otherwise access to these files].

 Regards,
 Martin Kögler
Thank you! I just tried it on Gentoo which has more verbose logging and 
at indeed turned out that the problem was the read permissions of the 
radius configuration file. Setting this to world-readable makes it 
possible to log in.

Unfortunately, the radius configuration file contains a sectret string 
to authenticate against the Radius server, so it should not be world 
readable.

I was actually under the impression that PAM is a query-service run as 
root: how else can a user be capable of obtaining root privellages by 
using su? Apparantly it works differently.

Anyway, is there any way to make a construction to authenticate against 
a module with root-only readable configuration file as a normal user? 
(different than inetd/xdm, which does not have the features I need for 
this group of users).


Sincerely,
Sebastiaan



--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


[Tigervnc-devel] PAM only works for local stored passwords

2011-02-24 Thread Sebastiaan Breedveld
Dear list,

I am testing the 1.1 pre-beta (2/21/11) 64 bit Linux binary on an Ubuntu 
Natty machine. According to previous posts, I start the VNC server as:
./Xvnc :4 -SecurityTypes=VeNCrypt,Plain -PlainUsers=sebastiaan 
pam_service=vnc

which works fine when connecting with:
./vncviewer :4 -SecurityTypes=VeNCrypt,Plain
and supplying my credentials.

Unfortunately, if the password of the user is not stored locally, but 
has to be retrieved from a server (a RADIUS server in my case), the 
connection fails:
./Xvnc :4 -SecurityTypes=VeNCrypt,Plain -PlainUsers=sebastiaanRemote 
pam_service=vnc


/var/log/auth.log simply responds:
Feb 24 21:34:35 uluru01 Xvnc: pam_unix(vnc:auth): authentication 
failure; logname= uid=1000 euid=1000 tty= ruser= rhost=  
user=sebastiaanRemote


Xvnc gives the message:
Thu Feb 24 21:33:44 2011
  Connections: accepted: 10.177.20.2::53817
  SConnection: Client needs protocol version 3.8
  SConnection: Client requests security type VeNCrypt(19)

Thu Feb 24 21:34:36 2011
  SConnection: AuthFailureException: invalid password or username
  Connections: closed: 10.177.20.2::53817 (invalid password or username)


My /etc/pam.d/vnc looks like this:
auth[success=2 default=ignore]pam_unix.so nullok_secure
authsufficient  pam_radius_auth.so debug
authrequisitepam_deny.so
authrequiredpam_permit.so

account [success=2 new_authtok_reqd=done default=ignore]pam_unix.so
account sufficient  pam_radius_auth.so
account requisite   pam_deny.so
account requiredpam_permit.so

which works fine for other services. I copied this file to a pretty 
simple service like chfn (cp /etc/pam.d/vnc /etc/pam.d/chfn) and it 
works fine.

I am not sure where it goes wrong, but I am happy to help looking.

Sincerely,
Sebastiaan


--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel