Having packed my stuff just in case the Griffith Park Fire of ’07 drew closer to home, an opportunitity was created to rearrange my workspace. Rearranging my computers has allowed me to connect a keyboard and mouse directly to one of my principle development machines. I have been interfacing with the machine through VNC up until now, and I just noticed that the scroll wheel was not responsive when I was browsing the Internet with Mozilla Firefox. I spent a couple of hours trying to get it working, so here is my /etc/X11/xorg.conf file that allows my Logitech MX300 Wheel Mouse on CentOS 5 running X11R6 to function:
# Xorg configuration created by pyxf86config
Section "ServerLayout"
Identifier "Default Layout"
Screen 0 "Screen0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Device" "/dev/input/mice"
Option "Protocol" "IMPS/2"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection
Section "Device"
Identifier "Videocard0"
Driver "nv"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Videocard0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection
The completion of a task was scheduled for 3:30pm. We have been pretty good at estimating the time that tasks require, and we have exercised practices that helped ensure that we meet our schedule predictions. We were fairly confident that we were going to complete our task at the desired time, until the lights flickered and dimmed. The fire alarm sounded moments after. The completion of our task at our planned time was ultimately thwarted.
At 3pm on Wednesday of last week, a transformer that supplies power to our building exploded. All of our workstations and servers use backup power supplies, so the loss of a work day was prevented. I am glad that the UPS for my workstation was set up. We saved our work and performed graceful shutdowns on our servers. We would be able to continue our work where we left off when the power is restored.
Everyone in the office building exited to the parking lot. Firefighters came and immediately created a perimeter around the transformer. Many people had left to enjoy the remainder of the shortened workday, while others, like Chris and me, were still deciding on what way to spend the rest of the day. Some people were discussing their plans next to the defunct transformer. As Chris and I started toward my car, a flash of light caught the corner of my eye, and I heard a thunderous sound and turned to see a fireball rise above the transformer. The transformer, or perhaps a second transformer that shares the same housing, exploded with people around it. At that time, people felt it was unwise to stay next to the transformer and moved away from it quickly. Fortunately, no one was hurt.
A couple of lessons were learned that day. Firstly, even schedules that have a very high probability of being met may experience some slippage caused by external, uncontrollable factors. Secondly, loitering around a transformer, especially one that is known to explode, is not a great idea.
Sure, traffic between an SSH client and server is enciphered, but how can certainty that the correct server is directly processing client requests be enhanced. A man in the middle attack occurs when an SSH server poses as the desired host, and forwards messages between the desired host and the client. The fake SSH server receives an enciphered message from the client that it can decipher, because the SSH server provides its own public key for the client to use. Then, the fake SSH server acts as a client to the desired SSH server, passing along messages to the desired server from the client. Respecting the fingerprint of a server’s public key helps minimize the efficacy of man in the middle attacks.
The following command gets the ssh key fingerprint on typical Unix-like system configurations:
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
The SSH protocol was intended to use a certificate authority (CA) for ensuring that clients were connecting to the desired server. Many SSH server and client installations currently do not rely on a CA to identify each to the other. This is why the SSH server’s key fingerprint is as important as login and password information when given to remote users. Without a good certificate authority in place, users should disallow connections to servers with unrecognized keys, and manually insert the key fingerprints into applications such as Putty. When a message indicates that a connection cannot be made or that the key fingerprint has been changed, attempts to connect should be discontinued, and the server’s administrator should be notified immediately.
July 16, 2005 – Hua and I set up the company’s very first server at Broadspire LA
The introduction of another full cabinet at a new colocation site in Downtown Los Angeles is evidence of the company’s progress and sustainability. I have heard from forgotten sources that eight out of nine companies fail within their first year, and only one in nine of the companies that make it through the first year become successful. The company has enjoyed stable and controlled growth since its inception, and the company’s investment in additional resources for future products evidences our anticipation of future growth.
During the past months, the company grew its customer base to include several companies that are publicly traded and held in equities markets. Our business development team is especially exceptional at discovering client needs and suggesting company products that can meet them. The technical team has made many accomplishments to cultivate the company’s success, and the entire team’s dedication to serving clients has instilled a great deal of client loyalty.
Success in business and the development of a company is significantly determined by the ability to gather, manage, and retain a pool of resources. Our success is also based on reciprocation from our clients. We care deeply about our clients’ online businesses, and they, in turn reward us. I look forward to continuing and expanding our success through the delivery of success for our clients, and I am driven to help perfect our processes to prepare us for the next level.
[00:16]* ae (steve@liss.loosebytes.com) has joined #gamedev
[00:34] <Decept404> anyone know of any decent offline/local network issue/bug tracking solutions?
[01:05] <ae> how about bugzilla?
[01:11] <Decept404> not offline ;P
[01:12] <ae> heh, you can always install a webserver and db server for use on the local host =)
[01:12] <ae> … and it has the added benefit of making online easily at a later time