'timeconfig' Is Back For CentOS 6
This is a bash script solution. Go look elsewhere if you want to Frankenstein your system with alien or legacy rpms.
The old 'timeconfig' TUI that was present from the original Redhat 'Diaper' release all the way up through the RedHat 'EL5' release now occupies too many terabytes on the OS installation so it had to be discarded from RHEL6 (and CentOS 6). Ok, just kidding. The real reason they abandoned it is, is uh, uh, uh. Sorry. Cannot think of any justification for discarding the command line utility. "Moronic" is the first word that comes to mind. Nonetheless, I need it and its *gone*!! That's all just unacceptable to me so I wrote a 'timeconfig' bash script to replace the abandoned OS feature. Here is how you can get it back too. Please keep in mind this was created to run on CentOS 6.x (and probably higher), but in theory should also work on RHEL6 and higher. 1. Login as 'root' (or su -) to begin. I use a remote session (SecureCRT, PuTTY or similar). 2. Make sure your installation fits the bill and that you don't have 'timeconfig' on your system. You can do so by typing the following commands: Code:
cat /etc/redhat-release 3. If you place this script in an appropriate location then it can be run from the system root prompt same as the old 'timeconfig' utility. I placed it in the following path: Code:
/usr/local/bin Code:
cd /usr/local/ Code:
cd /usr/local/bin/ Code:
#!/bin/sh Code:
chmod 700 timeconfig Code:
cd / Available zone selections are not as complete as the original 'timeconfig' but should be adequate to suit most needs. More than suits mine. Also, I'm no linux bash scripting guru so some of my techniques could undoubtedly be improved upon. Feel free to use 'as is' or modify to your liking, and either way have fun. |
What's wrong with just the `date` command? They likely abandoned timeconfig as probably most just use NTP nowadays, no reason to maintain a command when there's already tools available that work just as easily.
Pick your timezone: Code:
ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime Cheers. |
Quote:
Nothing wrong with having "more than one way to skin a cat". Nothing wrong with enhancing a product and calling it "an upgrade". What is wrong is when *anyone* enhances a product, strips it of features *they* deem "unworthy to maintain" and then presume to call it an *upgrade*, which is it not -- not after stripping it of *any* features. That's just plain wrong. When something is enhanced, it is said to be upgraded. When something is lost, it is said to be *degraded*. Calling Centos 6 an upgrade over Centos 5 is just flat ignorant (if not brian dead), as it was to refer to Centos 5 an upgrade over Centos 4 after they removed the 'printconf' tui. These could legitimately be presented as a *substitute* products and that would be fine. "Upgrades", they are not. (rant rant rant :D ) Anyway, the software company I work for ships pre-configured drives to customers around the world, and you are correct. Some may not have internet access. Regardless of our reason which is nobody's business but our own (hint hint >> certainly not for Centos/RHEL to decide worthy or not), it is extremely convenient for us to have the ancient and traditional 'timeconfig' available as opposed to having to go filtering through directories manually trying to find the proper source file to suit the customer to fit into a new command syntax we never had to concern ourselves with previously. Not knocking your alternative solution, and again, very kind of you to provide sample code. Obviously less bother than setting up my script if its a one shot deal so it is indeed a worthy contribution to this thread! :) |
Both useful information for time setup. We work in a lab with an isolated network (no outside access) and currently have chrony to replace NTP. The configuration consists of a server and clients whereby the clock from the main server is used to provide accurate time. Some what-if's:
* What if the clock on the server goes bad? * What if the server goes down? * What if drift causes exponential accuracy of time to fail? Thankfully, chrony can address all of these. Check here for all the information you'll ever need on chrony: http://chrony.tuxfamily.org/ For the OP's particular scenario, if I were in his shoes, I'd definitely do something very similar to address shipping out machines that need the correct time where one can't know whether the system will go into a "connected" environment or not. |
I found that this awesome timeconfig.sh script written by RandyTech has a bug where it's not updating the /etc/sysconfig/clock file. That's a problem, because that file is used when the tzdata package is updated via yum. Basically, it reads the old time zone from the configuration file that wasn't updated, and resets the time zone back to the default value. There is a bug written up for this in the CentOS Mantis tracking system, but it was never fixed.
I was able to fix this by updating the script as follows: Code:
|
@LoadedMind -- Nice contribution to the thread, complete with reference link -- very nice!
@UltimateBob -- Excellent catch. Thanks for sharing the code adjustment! |
All times are GMT -5. The time now is 12:17 PM. |