Here is a cheat sheet on changing the timezone in a linux system (CentOS 6.8 or 7): # Remove the current timezone file rm /etc/localtime # Create a symbolic link to the new timezone you want # ls -la /usr/share/zoneinfo/ # ls -la /usr/share/zoneinfo/US/ # For GMT ln -s /usr/share/zoneinfo/GMT /etc/localtime # For EST ln -s /usr/share/zoneinfo/EST /etc/localtime # For UTC ln -s /usr/share/zoneinfo/UTC /etc/localtime # For GMT ln -s /usr/share/zoneinfo/GMT /etc/localtime # For New York (Eastern) ln -s /usr/share/zoneinfo/US/Eastern /etc/localtime # For Central ln -s /usr/share/zoneinfo/US/Central /etc/localtime # For Mountain time ln -s /usr/share/zoneinfo/US/Mountain /etc/localtime # For Pacific time ln -s /usr/share/zoneinfo/US/Pacific /etc/localtime # Set Date and Time (as needed) # MMDDHHmmYYYY date 072522172010 hwclock --systohc # If you're using NTPD Service # CentOS 6.
This article focuses on synchronizing/updating the clock in your guest linux VM after you restore a VirtualBox snapshot. When you create a VirtualBox snapshot, it’s essentially a photo taken and frozen in time. All bits including the date and time are frozen to that instant. When you restore a snapshot, the Linux guest VM system is restored back to that snapshot including the date and time. This may not be desired all the time especially if the purpose is to restore the configuration and settings to an earlier time but your want to roll forward the clock on the VM to the present instance.
When getting started on ZeroMQ (version 4.2.0 or above) can be quite challenging especially with all the prerequisites. I’ve spent a good two days to get the process ironed out. So I’m sharing this so that others can avoid the same pitfalls and can have a good head-start with setting up their environment. Pitfall #1: Develop for your platform. I’m accustomed to developing in Ubuntu 14.04.3 LTE but in this case my deployment environment happens to be CentOS 6.
Recently I decided to port some of my development using ZeroMQ onto my CentOS development machine and I ran into some challenges. I’m documenting those challenges so that if someone else runs into the same pitfalls I did, they can avoid it. In this example today, we will work with the first “HelloWorld” examples in the ZeroMQ guide found here. I added a few modifications to the sample such as a package name and a try-catch around the Thread and an exception.
If you are an avid Python developer, you may all be excited about the new features available in the Pycharm 2.5 release, especially the remote interpreters, virtualenv and setup.py support. You can read more about the new exciting features here. But as I started to tinker with the “remote interpreter” feature - I stumbled upon some challenges and I thought I’d document them for other PyCharm users who might benefit from this blog entry.
If you tried upgrading to Python 2.7 on CentOS, you will quickly find out that the RPM’s don’t exist for this in the repos. So here’s a short summary of what I did to upgrade my Python to 2.7 on CentOS. Based on a few Google searches… I discovered that a few dependent packages are required before you try upgrading to Python 2.7. [sourcecode] yum -y groupinstall ‘Development Tools’ yum -y install openssl-devel* ncurses-devel* zlib*.
Sometimes you need to see what’s installed as part of a package via yum. To see the package contents you can use a utility that’s available on the RHEL/CentOS. [sourcecode language="jscript”] $repoquery –list packagename [/sourcecode] If you do not have this utility available, you can install it by using this command [sourcecode] $yum install yum-utils [/sourcecode] Here is a sample output from looking at the package contents of Apache httpd.