For the impatient or TLDR ... Put: export LOCKPRG='/bin/true' in your .bashrc. Kill all screen sessions and start a new one. Ctrl-a x should now do nothing. Also, a nice fellow named Brian suggested I just unbind the x key. I thought it was a good idea. Just put "bind ^x" and "bind x" in your .screenrc. Lot's of different ways to do the same thing. Re-binding is the better way though.
I have been using GNU Screen for a while now. I usually create multiple new windows (Ctrl-a c) every day. Then I flip back and forth between the multiple screens (Ctrl-a n) or just toggle between the last 2 windows used (Ctrl-a a). Sometimes my finger slips and I hit Ctrl-a x which provides you with a password prompt. This is GNU Screen's lockscreen function.
Normally you just enter your user password and the screen will unlock. Screen is using /local/bin/lck or /usr/bin/lock by default. This is all fine and dandy if you have a user account password to enter. If you have servers that only use SSH keys and don't use passwords you will have no valid password to enter. In other words you are stuck at this lock screen. One way around it is to login to the same machine and re-attach to the same screen session (normally "screen -r" if you have only 1 session open). Then kill the session with the lock screen. This is annoying to have to do.
I wanted to be able to just disable the lockscreen setting and be done with this. Looking at the man page it shows there is no option to turn this off. So you have to go around it in a way. The way I found to do this on machines without user passwords is to disable the terminal lock program by setting the environment variable LOCKPRG to "/bin/true". For BASH put export LOCKPRG='/bin/true' in your .bashrc. Kill all screen sessions and start a new one. Ctrl-a x should now do nothing.
For security sake be careful about disabling your LOCKPRG. /bin/true disables all terminal screen locking, so if you use some program that uses whatever is in the LOCKPRG variable it essentially disables it.
It is my pleasure to announce that Pantz.org can now be accessed in a more secure manner. Why add this now? What needed to happen to make this a viable option? Why can't some users access the secure site? Read on to find out.
The major reason I did not switch over to https sooner was that Google needed to support secure connections to their Ad servers. Late last year Google finally added the ability to serve up their Ads via SSL/TLS. I was not going to offer access to my site while the Ads could only be served up via standard http.
If you try to serve up external content (Ads) from your secure site, and that content is unencrypted you get nasty messages from browsers about the site having mixed content. The messages are very intrusive and ugly. By Google switching Adsense to https that ugliness goes away. All connections from the site could now go out securely via SSL/TLS.
The second reason I decided to do it was Google starting to use HTTPS as a ranking signal. I know these reasons are very Google centric, but the Ads pay for the site.
I wanted to choose one of the most secure types of certs I could for use on Pantz.org. This lead me to choose a ECDSA (Elliptic Curve Digital Signature Algorithm) with a SHA-256 certificate signing request. I got the cert from Comodo. Comodo offers ECDSA certificates signed by the Elliptical Curve DSA all the way up to the built in, browser trusted, Comodo ECC Root Certificate. This makes Comodo one the only CA's to offer a pure ECC certificate chain.
https has evolved over the years. SSL v2 came out in 1995. V3 came out in 1996. The successor to SSL is TLS. TLS 1.0 was defined in RFC 2246 in January 1999. TLS 1.1 was defined in 2006. TLS 1.2 was defined in 2008. Over the years weakness have shown up in the early SSL v2-3 protocols. These weaknesses make attacks more viable. Because of these weaknesses I have decided to disable SSL connections to Pantz.org.
Ciphers have also had attacks levied against them over the years. Some of cipher types have shown up with weaknesses are RC4 and DES. Because of these weaknesses I have disabled the use of DES and RC4 on Pantz.org.
By turning off SSL connections and not using RC4 or DES as an encryption type there are some people that will not be able to get to the secure Pantz.org site. The majority of people that will have this issue are people are using old Operating Systems and old browsers. Mainly this will likely be people trying to use Internet Explorer 6 to access the secure site or people trying to access the site with Windows XP on certain configurations. There are a few combinations of Windows XP and some browsers that work with TLS 1.0 (IE 8 and WinXP SP3), but many combos just don't. Even MS does not support XP anymore so upgrade.
There is nothing on Pantz.org needs a secure connection, so if you have issues connecting to the secure site just use the http version. It's as simple as that.
After installing the new Ubuntu (Xubuntu) 14.04, I rebooted the machine to the desktop. I noticed that the hard drive was being accessed every second consistently. Just pulse...pulse...pulse. It was driving me nuts, as I had no clue what could be causing it. Since this issue was IO related the easiest way to solve this was to install and run iotop.
# Install iotop sudo apt-get install iotop # Run IOTop with -o so we only see processes doing IO iotop -o # Output looked similar to this Total DISK READ: 0.00 B/s | Total DISK WRITE: 2.00 M/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 1 be/4 root 0.00 B/s 2.00 M/s 0.00 % 3.00 % [ext4lazyinit]
Now I know anything in brackets is a kernel thread, and ext4 is the file system I used (Ubuntu uses) to format the partitions. Time to go see what this kernel thread does. After some digging I found the Git commit log for this ext4 file system feature.
In the old (or not so old) days of ext2 and 3 when you formatted the file system you would have to wait while it was created. Usually most of the waiting was because you had to wait for the inode tables to be created. Make a ext3 file system and watch how long it takes to make the inode tables. The bigger the drive the longer it takes to make these tables. We are talking 10 or more mins on 2TB drives and above. Ted Tso the creator of ext4 helped cut this time down by allocating some of the inode tables during creation and then allowed the rest of them to be made on first mount. When the file system is mounted the first time it sees this was marked to be done and creates a background kernel thread to finish creating the inode tables. This way your install time is cut down dramatically because you don't need to wait for the file system inode tables to be created. The are just happily created in the background as you work.
So how long will this take to finish? I'm not to sure as I left my machine on all night so it could finish. It was done by the morning so I can say less than 12hrs on a 1TB drive. Don't fret though it will eventually finish and rest assured there is nothing wrong with your hard drive or the install. This likely happens on older Ubuntu installs and any other distros that use ext4 as well.