- Written by Super User
- Category: Industry News and Events
- Published: 04 March 2014
- Last Updated: 04 March 2014
On the 20th of February 2014, I published some of my PowerCLI scripts to GitHub in an attempt to have some sort of version control system in place as well as to make the scripts available to the general public. However, my current role doesn't really require that much scripting, and it really is only the occasional script that I have to put together. Therefore, I've only learned a little of PowerShell, basically enough to get the job done. I come from a C/C++ programming background and feel much more comfortable when working on a file with a .c, .cpp or a .h file extension.
However, I am aware that there are some real PowerShell gurus out there with outstanding scripting skills and most probably some good scripts as well. Wouldn't it be great if we can pull all the scripts together in a repository that is open to the public? If you have a script that you wrote and that you would like to share with the virtualization community, please feel free to contribute the script to my ScriptKit repository on GitHub.
To contribute, browse to the repository at https://github.com/rynardtspies/ScriptKit and hit the "Fork" button. This will allow you to clone the entire repository to your own FREE GitHub account. You can then add scripts to the repository or make changes to the existing files in the repository. Once you are happy with your changes, create a pull request on GitHub. This will inform the repository maintainer (currently myself, but I could hand that responsibility to someone more qualified in the future) that there are changes that are waiting to be pulled in. If the changes meet the requirements, they will be included in the ScriptKit. Simple :)
If you would like to contribute, but you can't be bothered with Git and Forking repos, then you can always fire the content over to me and I'll upload the content, credited to you :)
I only have one rule. Please only contribute content that you have the rights to and please do not upload copyrighted content or content that was written by someone else without getting their permission first.
- Written by Rynardt Spies
- Category: Tools
- Published: 20 February 2014
- Last Updated: 20 February 2014
Too many times now have I had to browse in a billion locations on my file systems, trying to find that one script that I wrote two or three years ago. I really have a bad habit of misfiling little scripts. That has got to change. So, I have started a little project to collect all of the PowerCLI scripts that I write and use from time to time, in a Git repository. I really needed to find a way of keeping scripts version controlled in a distributed system, whilst at the same time keeping them in a cloud based storage location other than simply Dropbox, where others can collaborate and add to it if they would wish to do so.
The repository is still very small, as I've only started working on it yesterday, however, as I write more and more scripts, I will be adding them to the repository and pushing them up to GitHub. There's no need to be able to use Git in order to make use of the scripts. Just download whatever you need and run them. However, feel free to contribute more scripts if you like.
Here is the URL to the repository: https://github.com/rynardtspies/ScriptKit
- Written by Rynardt Spies
- Category: Linux
- Published: 08 December 2013
- Last Updated: 02 February 2014
I remember struggling to get my head around Apache Webserver file permissions. It's a common issue, and I've seen forum posts this weekend with users struggling to get it right. That s what's prompted this post.
To allow the Apache web server process (httpd) to access and serve files from virtual host directories, httpd requires at least read access. However, with content management systems, httpd might also require write access to virtual host directories.
On Linux, the Apache web server process is normally started as the root user. This is to allow the process to bind to port 80 and 443. However, once the server has started up it switches the the user specified in httpd.conf. In CentOS, this is set to:
user = apache group = apache
This all works well if the server is only hosting one website, or even multiple websites but for the same user or client. However, in a shared hosting environment where multiple customers need to have read and write access to their web directories in order to upload the websites, we need to find a configuration that will allow the httpd process read/write access to all virtual host directories as well as allow each individual client/user read/write access to their own web directory. We can be daring and just give full write to everyone with a chmod 777 command, but that would be foolish. The smarter way is actually very simple and is achieved using Unix groups. Basically, for each customer that will be uploading files to his virtualhost web directory, we create a Linux user. When the user account is created, a group will also be created with the same name as the user. With the user account in place, we give full read, write and execute rights to both the user and the group and no rights to everyone else (chmod 770). We then add the apache user to the new user's group which grants full rights to the web directory to httpd.
- Written by Rynardt Spies
- Category: VMware View
- Published: 06 December 2013
- Last Updated: 15 February 2014
I've always wanted to find a cost effective way to implement 2-factor authentication. Commercial solutions are expensive, and if you are a small business, you might not want to spend a small fortune on implementing an enterprise solution with hardware tokens. I stumbled across Google Authenticator a while back and started to wonder how it can be used to implement a free 2-factor authentication solution in my lab. I also found a few posts that suggested teaming it up with Freeradius and that's really where this post started.
After several attempts, I've managed to find a quick and easy way to get it working. Well, at first glance you'll probably disagree as this is quite a lengthy post, but the steps required to implement the solution are actually very simple. In this blog post, I've tried to explain each step in order. I do not expect everyone to be a Linux expert, and I kept that in mind whilst writing this post. To be honest, this is version 0.1 of this post and I'll probably expand this post over the next few weeks to include overall solution diagrams and extra information. For now, I've managed to at least write up the steps required to implement the solution.
This solution is based on CentOS 6.3. You can use any other Linux distribution, but the instructions in this post are CentOS/RHEL specific. We will be using Freeradius, an open source Radius server as the main component. Freeradius will make use of Pluggable Authentication Modules (PAM) and PAM will call upon Google Authenticator which is basically a module that is written for PAM. Google Authenticator will verify a user's password together with a token code that changes every 30 seconds. The user will make use of the Google Authenticator mobile APP to obtain a new token code every time a new login is required.
To finish, we will configure VMware Horizon View to make use of RADIUS authentication, and to contact the Freeradius server whenever a user requests a new connection using the View Client.