I was going to write a post on how to install and configure your own virtual SSL-VPN server as I had in mind to make one myself as a means to surf safely while on hotspots and to access my System Cent
Ok, so I got the task to install the Linux Integration Service for Hyper-V R2 on a RedHat Enterprise Server 5. Something that turned out to be a bit more to handle than I would have thought. So here’s a little How-To. Preparations Read the documentation provided in the Linux Integration Services download. Much of the information in this article is in there, but some parts are not. Otherwise I would not have bothered writing about it. 😉 I’m not going to go through the OS installation process here, but make sure to select the “Software Development” packages since you will be needing it. In case you missed it, you can install them later by running these commands. # yum groupinstall "Development Tools"# yum install kernel-headers I’m not actually sure that you need to run the kernel-headers install manually or if it’s included in the “Development Tools” package. The first gotcha i ran into was the fact that the link to the Linux Integration Services–previously known as Linux Integration Components or LinuxIC–on RedHat’s information pages gave me a 404 and a redirect to a bing-search that returned the exact same 404. The page have simply been removed by Microsoft without any form of redirection to the new page. Anyway, a search on http://download.microsoft.com for “Linux Integration Components” do return the new page, and that’s where I learned about the new name. Thank you for making it easy for us Microsoft! Here’s a direct link to the search on the current name. And here’s a direct link to the actual download page. This download contains an ISO file that you can mount using the Hyper-V- or VMM-console, or you can do as I did and download the ISO to the virtual machine, mount it locally, copy the files and unmount it. Like this. # mkdir /mnt/ISO# mount -o loop /root/LinuxIC v21.iso /mnt/ISO# mkdir /opt/linux_ic_v21_rtm# cp /mnt/ISO/* -R /opt/linux_ic_v21_rtm/# umount /mnt/ISO
Error Description Here’s a little trouble-shooting guide for discovering Linux systems from OpsMgr R2 when getting the following error from the wizard: <stdout>Generating certificate with hostname="COMPUTERNAME"[/home/serviceb/TfsCoreWrkSpcRedhat/source/code/tools/scx_ssl_config/scxsslcert.cpp:198]Failed to allocate resource of type random data: Failed to get random data - not enough entropy</stdout><stderr>error: %post(scx-1.0.4-248.i386) scriptlet failed, exit status 1</stderr><returnCode>1</returnCode><DataItem type="Microsoft.SSH.SSHCommandData" time="2009-08-05T11:15:01.5800358-04:00" sourceHealthServiceId="0EB1D6DA-202C-7FC5-3D46-BDBB9208547D"><SSHCommandData><stdout>Generating certificate with hostname="COMPUTERNAME"[/home/serviceb/TfsCoreWrkSpcRedhat/source/code/tools/scx_ssl_config/scxsslcert.cpp:198]Failed to allocate resource of type random data: Failed to get random data - not enough entropy</stdout><stderr>error: %post(scx-1.0.4-248.i386) scriptlet failed, exit status 1</stderr><returnCode>1</returnCode></SSHCommandData></DataItem> But first, a little background on the actual “problem”. To generate the certificate, the entropy needs to be high enough to generate random data for the certificate creation. Without the certificate, the OpsMgr agent won’t be able to open up communications with the MS. So, what creates this entropy we need? Bluntly put, a selection of hardware components that are likely to produce non-predictable data. Like a keyboard, mouse and a monitor or videocard. Of course, there’s a lot more to it, but we really don’t need to know this. What we need to know is that there has to be a “bit bucket” of more than 256bytes of entropy for the certificate creation process to succeed. We also need to know that more enterprise-ish servers, like rack- or blade-servers tend to be void of things like directly attached keyboards, mouses and monitors that the linux kernel needs to be able to generate entropy. And herein lies the problem. If you have a new server that is not in full service (likely since we are trying to deploy the monitoring on it) which means that there’s not much random data flowing through the hardware and there’s no keyboard or mouse or monitor connected to it there is quite the risk that the system entropy is going to be very low. Of the linux systems that I have been deploying OpsMgr agents to, about half have failed because of “Not enough entropy”. So, here’s the steps I usually takes to ensure that discovery works. I use PuTTY to connect to the soon-to-be-monitored servers. This guide also assumes that you have SU rights on the system since all of these steps (except #1) needs it. Workaround 1. Check you current entropy cat /proc/sys/kernel/random/entropy_avail Is it less than, or close to, 256? It probably is. If you don’t feel like connecting a mouse and start wiggling it around—not really feasible in a data center—and see if the entropy increases, you can generate your own random data. 2. Generate you own random data. Be advised that this forced entropy will not be as random as the system-created on and thus not as secure. How much more insecure it is, I don’t know, and quite frankly I prefer to have my systems monitored yet slightly less secure than not monitored at all. Anyway, you can force your own random data by running:
Ok, so I reinstalled my linux partition with Ubuntu 9.04 x64 and decided to try EXT4 on the root partition. Like, yesterday. Managed to get the Citrix client running (way more easy on Ubuntu than Fedo
[updated, scroll down if you want to skip some nonsense] So, I did an upgrade to Ubuntu Studio 8.10 (basically Ubuntu with rt-kernel and lots of nice media-related packages easily accessible and a skin that rocks) from the earlier 8.04. And the upgrade itself was really easy. I just opened the “Software Sources”, set the Release upgrade to Normal Releases (you find it under the Updates tab). After that you get the option to do a Distribution Upgrade, which I did (took some 45 minutes to finish). I did however run into some serious problems with the NVidia Drivers after the upgrade. Basically, the new drivers dont seem to install correctly under the new kernel. This conclusion took me a day of laborating with settings, installing packages, uninstalling packages, reinstalling packages and a whole lot of googling. What I have come down to right now is doing the following: sudo apt-get install module-assistant This will install the module assistant and it will also make sure that you have all the correct linux headers to install the NVidia drivers. Going back to the “Software Sources” under i check the “Unsopported updates”. Then i execute sudo apt-get autoremove sudo apt-get install nvidia-177-kernel-source m-a auto-install nvidia UPDATE! After fiddling around with this Laptop (Lenovo Thinkpad T61) I really just needed these three steps to fix the problem. All of them from X using the regular nv-drivers. In a terminal, run sudo apt-get install module assistant In a terminal, run sudo m-a auto-install nvidia Open the “Hardware Drivers” application and pick the driver you want (177 in my case) and click Activate. If it worked alright, you’ll get the green recycle icon and be asked to reboot to activate the settings. Hopefully, this might help someone. It did work for me and I am now able to work with wobbly windows and all that crap. (Besides some serious 3d stuff 😉 ) Anyway. Since I did not save the urls, I cannot give credit to those who have pointed to stuff that did help me on the way, but I’ve actually not find information anywhere yet that solve the problem totally and, well… that’s why I did decide to post in here.