xlockmore: the UNofficial version of xlock, see Revisions for version # Primary site: ftp.x.org in /contrib/applications Maintainer: David A. Bagley Adapted from Patrick J. Naughton's original (and official) xlock. How to build? Check below to see if your machine is one mentioned that causes problems, otherwise it should be easy. Only if your using X11R6 then: xmkmf make depend make ./xlock -mode spline If your using X11R5 then: xmkmf make ./xlock -mode spline If your using X11R4 then: mv Imakefile Imakefile.r5 sed 's/^XCOMM/\/\*\*\/#/' > Imakefile < Imakefile.r5 xmkmf make ./xlock -mode spline Note: if you don't have 'xmkmf' or the "Makefile" it generates doesn't work well, edit Makefile.std for appropriate settings for XINCLUDEPATH and XLIBPATH, then try: make -f Makefile.std ./xlock -mode spline Likely problems: Solaris2.x users: Imake will compile with the -DSOLARIS_SHADOW switch. It doesn't use the root password feature, but otherwise should work for both local, NIS and NIS+ passwords. Is it possible to handle the root case for all configurations? With Gnu's gcc, get rid of the "-ansi" during compilation. With Sun's unbundled cc, compile with a "-DSVR4" and link with "-lnsl -lsocket". Solaris2.3 and greater users: Adjust the Imakefile to compile with HAS_NANOSLEEP. Also need to link with -lnsl -lposix4. With this, less CPU cycles are wasted and usleep is a lot more accurate (!). Solaris2.4 users: xlock will dump core if xlock is not setuid root. ESIX users: Similar to Solaris2.x. You will need a -DSVR4 to compile. chmod 440 /etc/shadow if you get libX11.so.xxx not found link with the static versions of the X libraries random() may be buggy use the one from GNU. chmod 2755 xlock XFree86 users: Control-Alt-Backspace will defeat locking mechanism and return your console back unless you put "DontZap" in your XF86Config file. (In X11R5, that would be a "dontzap" in your Xconfig file). Control-Alt-F1 (among others) will defeat locking mechanism with virtual terminals. This ain't too good, right? If your using Linux, try vlock on tsx-11.mit.edu in /pub/linux/sources/usr.bin . I hear that XFree86 3.2 when it comes out MAY have a server extension for catching or disabling VT switching. Any ideas in the meanwhile? Linux users: If you are using shadow passwords make sure you: chown root.shadow xlock chmod 2755 xlock Also check that the following was done: chown root.shadow /etc/shadow chmod 440 /etc/shadow So far, Slackware (a major Linux distribution) does NOT come with shadow passwords standard. If you want to install shadow passwords (be careful, it can be tricky) it's on sunsite.unc.edu in /pub/Linux/system/Admin . FreeBSD users: One may have to make xlock setuid root (are there any objections?). Alpha-OSF/1 enhanced security users: Compile with -DOFS1_ENH_SEC see Imakefile chown auth.auth xlock chmod 2755 xlock HP users: Shift-Control-Break is caught. xlock MAY bomb after 1 hour (or less) when the keyboard is pressed. This has been known to happen on HP-UX 9.0x with HP 7xx XIO: fatal IO error 0 (Error 0) on X server "unix:0.0" after xxxxx requests (xxxx known processed) with 1 events remaining. Maybe I introduced a bug in a later version? I tend not to think so now. If you get it working, LET ME KNOW. Note: I do not have an HP. I heard that it happens only with modes like galaxy and pyro (lots of XDrawPoints) and it never happens with modes like hyper. If true, mail me a more complete list, if not let me know. Known problem modes: galaxy, pyro, and worm. Suspected OK modes: hyper. I heard its runs OK at some sites ... If so tell me what version of the OS and machine, and what patches have been applied. Known problems exist on: HP 712/60 (HPPA-1.1), HP-UX 9.05 HP 750, HP-UX 9.01 HP 715/80, HP-UX 9.05 HP 725/75, HP-UX 9.01(3,5) HP 7xx, HP-UX 9.04 HP-UX with Secured Passwords: Compile with -DHPUX_SECURE_PASSWD and have xlock setuid to root. X-Terminal users (my heart bleeds for you): To get xlock to run, run with -remote option or set XLock.remote on in XLock.ad. VAX/VMS users: All you should need to do to build the executable is type @make To run xlock a symbol needs to be defined, for example: XLOCK:==$H268SYSEXE:XLOCK where H268SYSEXE is a logical name pointing to the directory where XLOCK.EXE resides. The '$' after == means this is a foreign command and VMS makes the command line available to the program. worm may look a bit strange, since the scaling is wrong. -allowroot only works if you have SYSPRV enabled which is a bit limiting. The XLock file normally in /usr/lib/X11/app-defaults needs to be in the directory DECW$SYSTEM_DEFAULTS on VMS systems and be called 'DECW$XLOCK.DAT'. 24-bit screen users (most people use 8): world is just a black screen and swirl gives sqrt: DOMAIN error. Public Lab Administrators: "bomb.c" contains a simple hack to provide a time-limited lock mode, at the end of which the user will be logged out. This is useful in public areas, where xlock could cause problems if terminals were left locked for long periods. The graphics for bomb are fairly basic, but the structure is fairly flexible and the changes localised as much as possible. It can be configured to offer this function as one mode among many (user's choice) (the default), or to force timed locks based on local policy (e.g. username or group). Don't PANIC, random will not run bomb, image, or blank, unless forcing is used, then of course, bomb will always run. You cannot run bomb as root, since it will kill all of root's processes, not a good idea. (Also bomb will not log you off if your debugging xlock). If bomb is forced, you can still run the other locks in -inwindow or -nolock. In bomb, you can not increase the delay for longer than 1 second. To force bomb edit the Imakefile and uncomment the -DFORCE_BOMB line. Edit your /etc/xlock.staff file (or whatever you want to call it). Code for forcing bomb is in bomb.c . (I personally tested it only on Solaris, SunOS, and Linux) I had to use #undef passwd and getpwnam in bomb.c . I am not sure if it was wise, but it worked. Shadow passwords conflicted with pwd.h . I would be curious to know if it works with shadow passwords besides Solaris 2.3. The only problem I've noticed is that for the Suns, when bomb is iconified, the time display does not stay in its window. xlock still does not work :-( : If all that does not work you may need to adjust xlock.h, usleep.c, xlock.c, and resource.c since these files are highly implementation dependent. If you have to make this kind of change to get it working, let me know. All done and xlock works :-) : You may want to compile xlock.c using -DMOUSEMOTION, then xlock will respond to (you guessed it) the motion of the mouse. This is not recommended if your using a virtual desktop; a default root window that may be larger than the physical displayed resolution on your screen. You may want to change the 1st line of XLock.ad "blank" to "random", "life", or whatever your favorite is and copy it to /usr/lib/X11/app-defaults or $HOME (or wherever your application defaults files are) and rename to XLock . You may want to move xlock into /usr/bin/X11 (or wherever your X binaries are). You may also want to move xlock.man to /usr/man/mann/xlock.n . You may want to try xautolock. It runs xlock after a user defined idle time. Its at ftp.x.org in /R5contrib, but I do not maintain it. Operation: (Blurb taken from Darren Senn's xlock) Under X, run xlock. The screen will clear, and some pretty animated picture (exactly which depends on which module is active) will appear on the screen. If you hit a key, then the screen will clear, and (unless you've changed the application defaults file that I packaged with this) you'll get a white screen with some graphics in the top center. These graphics consist of a reduced size image of the module you were viewing, the name of the user who executed xlock, and password prompt field, and some short instructions. At this point, you can either click on the graphic to return to xlock, or you can type a password. If the password is verifiable as the root password, or the password of the user listed above, then xlock will terminate. THIS IS THE ONLY WAY TO STOP XLOCK WITHOUT SHUTTING DOWN THE X SERVER. That's what makes it a lock. Resources: (Also taken from Darren Senn's xlock) There are two sets of resources for XLock. The first set are (what I call) global XLock resources, while the second set consists of module-specific resources. I'll get more into modules a little further below. The global resources are: XLock.mode: This sets the module. More about this later. XLock.font: This is the font used on the password entry screen. XLock.background: The background color for the password entry screen. XLock.foreground: The foreground color for the password entry screen. XLock.username: The label for the field indicating the user name. XLock.password: The label for the password prompt. XLock.info: The "short instructions" to print. XLock.validate: A message to display while checking the password XLock.invalid: A message to display if the password is incorrect XLock.nice: How much XLock should nice itself. XLock.timeout: How long to wait idle at the password prompt. XLock.timeelapsed: Message to see how long lock running (yes or no) XLock.mono: Monochrome mode (yes or no) XLock.nolock: disable the lock mechanism (yes or no) XLock.remote: allow remote locking (meaningless under linux) XLock.allowroot: allow the root password to unlock (yes or no) XLock.enablesaver: allow the system screensaver to work (yes or no) XLock.allowaccess: allow other clients to connect while active XLock.echokeys: Echo "?" for each password keypress (yes or no) XLock.usefirst: Ignore the first character typed (yes or no) XLock.verbose: Verbose mode. (yes or no) XLock.inwindow: allow the xlock to run in a window (yes or no) Xlock has a number of modules which it can display. (See the man page for a complete list). It turns out that each module is characterized by a number of initializations, separated by a number of "draws". Each module has the following resources defined: XLock..delay: How long to wait between draws (usec) XLock..batchcount: May mean various things (see man page). XLock..saturation: Saturation (as in HSV) of colors to use. Acknowledgements: I did not write the original algorithms in any of the lockscreens, although I did convert many of the new ones to run with xlock. I tried to follow the original style of Patrick Naughton. Updates will just overwrite the old file at ftp.x.org in directory /contrib/applications. Many of the additions were "borrowed" from xscreensaver (Jamie Zawinski jwz@lucid.com). At the time, I had trouble with getting it to compile so I moved the "interesting" algorithms to xlock. Many of the others were "borrowed" from old demos from Sun. My favorite of this new bunch is "spline", "borrowed" from Jef Poskanzer (jef@netcom.com || jef@well.sf.ca.us). I will consider putting new ones in if (1) they are more or less public domain, (2) they are neat (I am biased towards mathematically based programs), and (3) I have the time. Some open problems: (Suggestions for this would be nice) Xlock should check first to make sure it can have access to the password before locking the screen. If it does not have access it should suggest something like ... "Have your admininstrator setuid xlock to root". More bitmaps are needed like the HP and Sun icons (i.e. Linux & BSD) but they must be small (<= 64x64). It would be nice to have an option -idletime time. Where xlock would run after a certain idle time. (Here xautolock may help you, see above). Penrose tiling lockscreen needed. Anyone have an algorithm out there? Sometimes xlock runs out of colors (for example, it might happen if you run xfishtank and run xlock at the same time). A possible solution seems to be to have a private colormap for each screen, then xlock will not have any problem allocating new colors. Unfortunately, it appears that window manager still uses the default colormap, although the window uses another colormap. "swirl" cycles its colors, except black and white. This is easily seen when on a color monitor one enters: ./xlock -mode swirl -inwindow now move the mouse in the window. If you find this annoying compile swirl.c with -DFORCEFIXEDCOLORS. In "bounce" sometimes a ball does not roll off another ball. "maze" and "helix" are a bit of a kludge, they need better interrupt mechanisms. Essentially you can't stop them until they are done drawing. Fortunately this is not (usually) a long time.