Cygwin: Changing the Face of Windows
Use the X11 forwarding feature of SSH to get rid of the export DISPLAY routine that is inherent to XDMCP (X Display Manager Control Protocol). When I tried to install SSH, the proxy server made a mess of it. I tried to install it manually but received errors because a cryptographic library in the SSL package was not installed yet. So don't forget to add SSL when installing SSH. If you use the setup.exe tool, these dependencies are satisfied automatically.
Because no default SSH configuration is present, you need to go through the following steps to set up the SSH client configuration decently:
Create an ssh_config file in /etc. If you do not have the Cygwin version of vim installed yet, use these echo commands to obtain the file:
echo "ForwardX11 yes" > /etc/ssh_config echo "ForwardAgent yes" >> /etc/ssh_config
If you do not create this file, you have to set the DISPLAY variable locally before connecting to a remote server:
If you want to be able to connect to your Windows workstation using SSH, you need to perform these additional steps to run the SSH daemon:
Copy sshd_config and ssh_config from an existing UNIX machine to the Cygwin /etc directory, and make sure X11 forwarding is enabled.
Generate SSH host keys. This does not work off the bat, because the file does not exist. The solution is to run touch /etc/ssh_host_dsa_key and then generate the key using ssh-keygen and overwrite.
Change permissions on your private host key to 600.
Run mkpasswd and mkgroup, which create UNIX-style /etc/passwd and /etc/group files based on Windows user information.
Create the SSH privilege separation user, adding a line like the following to /etc/passwd:
sshd:*:74:74:SSH Privilege Separation User:/var/empty/sshd:/sbin/nologin
Now start SSH with the -Y option:
ssh -Y user@remote_host
Check the DISPLAY variable when you are logged in to the remote server; it should say something like remote_host:14.0. You now can start any graphical UNIX application, and it will be displayed on your Windows desktop.
While testing the graphical applications, I noticed that a number of GNOME applications are included in the package list. All the libraries that you need to run GNOME programs already are ported, but a full-blown desktop is not available yet--unless you do some compilation yourself, of course. As a workaround, use the standard -query option to the X server to display a complete remote desktop:
/usr/X11R6/bin/XWin.exe -query remote_host
On Solaris, the XDMCP feature still is enabled by default. On Linux, you need to change your XDM configuration, preferably serve fonts and your GNOME or KDE configuration. On my Fedora box, I did the following:
Comment the line DisplayManager.requestPort in /etc/X11/xdm/xdm-config.
Uncomment #* # any host can get a login window line in /etc/xdm/Xaccess.
Comment no-listen = tcp in /etc/X11/fs/config.
Run /etc/init.d/xfs restart
In /etc/X11/gdm/gdm.conf, change Enable=false to Enable=true.
Run pkill -HUP gdm.
Then, from the Windows station, make sure that the X server is stopped before entering the X -query command.
This kind of remote display, however, is not optimized. I included it here only to demonstrate the capabilities of Cygwin. A faster solution is the VNC client/server. In this method, the client goes on your Windows machine, and the server either is enabled through the inet daemon or is run independently on any UNIX system. If you need to display only one application, the method described above--the example with SSH and xclock--probably is the fastest. The data automatically is compressed through the secure connection.
The next problem I faced was the near-impenetrability of the MS ISA firewall/proxy. Although firewalls typically are designed to keep people out, our company's firewall was set up to keep people in. The only available ports for outgoing traffic were 80 and 443, HTTP and HTTPS. I wanted to connect to my home mail server. Also, being a system administrator, I'm used to having extra services available when solving troubles, such as IRC, my personal e-mail and my personal files. I had to get out of this prison. In the end, I managed to do so using an external Debian server. On that machine I configured SSH to listen on port 443 as well as on port 22, by simply entering this line to sshd_config:
I then discovered that the normal text-based SSH client that comes with Cygwin does not support authentication using the Windows domain name with a user and password pair. Putty, however, did the trick.
Putty also helped me with the last problem: I was denied access to a variety of interesting sites, for the strangest of reasons--the automatic scanning performed by the ISA server. To be able to surf wherever I want, I installed Squid on my external server on the default port 3128. Then, still using the SSH connection to port 443, I also configured port forwarding. Putty was instructed to forward local port 80 to port 3128 of the remote server.
After starting that connection, I configured my browser to use localhost:80 as a proxy, and I once again could surf to Amazon.co.uk and other interesting sites.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide