Navigate / search

Installing Jolicloud on an Asus T91 or T91MT

I’ve been using Jolicloud (http://www.jolicloud.com/) Linux on my T91MT for about a month now, mostly as a “coffee-table” computer. Jolicloud 1.0 is built on Ubuntu 9.04.

As it turns out, when trying to install Jolicloud 1.0 on an Asus T91MT (with the infamous GMA500), Xorg crashes due to the graphical installer.

Although Jolicloud has built-in support for the GMA500, it will not allow the T91 into the graphical installer. It will boot into the standard LiveCD options list, but when you choose “Install Jolicloud,” an error will display similar to: “X server exited with return code 1″ – not allowing you to go any further. I’ve heard of this happening on other netbooks as well.

Below is the easiest method to get Jolicloud to install:

When at the options screen to boot into a LiveCD or Install, press “F6” for boot options and type:

xforcevesa

This will allow Jolicloud to install using the graphical interface in VESA mode. When Jolicloud has been installed, you’ll need to remove “xforcevesa” from the grub configuration file to get the full resolution of your netbook.

From the terminal (shortcut: ALT-F1), type:

sudo gedit /boot/grub/menu.lst

Inside you’ll see a line similar to:

/boot/vmlinuz-2.6.32.9-1-jolicloud root=/dev/sda1 ro xforcevesa quiet splash

Remove xforcevesa from the line and save the file. There will be another line with xforcevesa in it, under the title: “recovery mode” - do not touch this line.

You will also need to go into the terminal and reconfigure Xorg to use the already installed GMA500 drivers.

From the terminal, type:

sudo dpkg-reconfigure xserver-xorg

Follow the prompts, and when finished restart your computer. Your native resolution should be in use.

Here’s a more detailed hands-on review of Jolicloud at Ars: http://arstechnica.com/open-source/reviews/2010/08/hands-on-jolicloud-10-brings-impressive-new-user-interface.ars

.CO TLD available for pre-register

I know many people are server admins for large companies that may be interested in this. The .CO TLD has been opened up for pre-registration for non-Columbians.

Godaddy and other registrars are trying to convince people this is the next big TLD – associating .CO with COmpany or COrporation or COmmerce. The sad thing is, with all of the marketing about to take place, it may just work.

Trademark holders, and current third level .co holders have first dibs, then people willing to pay $299, and finally people only willing to pay $29.

So, like .info, .mobi, etc, if your company has a presence worth protecting, you may need to shell out the $$ to protect against squatters.

Here’s a link to Godaddy’s page about .CO:

http://www.godaddy.com/tlds/co-domain.aspx?ci=19152

It also happens to be the 25th anniversary of .COM today.

http://news.bbc.co.uk/2/hi/technology/8567414.stm

Creating an IT Backup and Recovery Plan

Backups are a necessary evil in System Administration, and although most of us dislike the process, it is by far the most critical element under the IT umbrella. I like to think of the whole process as a Recovery Plan instead of a backup plan, because in the end all I care about is that the data is recovered properly and quickly. One of the biggest pitfalls new System Administrators or System Administrators new to a particular company do, is that they do not test their own backups. Not being able to recover information from a system you designed or recommended is the quickest and surest way to get fired. 

 

1. Risk Assessment

Although this sounds simple, a true risk assessment is rarely done and far out of the reach of the average business. Although hiring actuaries and combing through insurance statistics is ideal, this is far from what companies are willing to do for a data recovery plan. Many System Administrators find companies that have not experienced data loss are less willing to be thorough in their analysis and budgeting.

One of the first things in a recovery plan is to write down the possible external risks, some examples:

  1. Fire
  2. Flood
  3. Earthquake
  4. Tornado
  5. Physical Break-in / Theft
  6. Virtual Break-in (Cracker)

Ask your Insurance Company what some likely issues will be, they will be happy to tell you every possible disaster scenario.

Next, think of internal risks such as:

  1. Viruses/Malware
  2. Data Corruption
  3. Hardware Failure (Electrical or Mechanical)
  4. User Error (accidental deletion)
  5. User Malice (non-accidental deletion)

To supplement risks, look through your company’s history for any previous data loss and the reasons for it. Enlist the help of your industry colleagues for any scenarios not on the list. You’ll be amazed at some of the “once-in-a-lifetime” stories you’ll hear – some may be applicable to you.

 

2. Impact Rating

An impact analysis on each scenario listed above should be created. This involves the hardware, software and data (all systems) that are affected and how. Does the impact involve a full or partial outage? If hardware is likely damaged, how quickly can it be replaced? Etc. Suppose there is a fire in a server room and the servers are damaged. You have the LTO tapes as backups, but no server, and no LTO drive to restore it with. How many days will it take to get an LTO drive and from where? During this phase of planning a vendor and consultant list should be compiled.

 

3. Risk Rating

This can be included in the budgetary section, or done beforehand. Combine the risk assessment items and impact ratings and sort them. This is important. You should implement a recovery plan that encompasses as many items as possible. By sorting, it makes the budgetary step easier when you need to cut coverage because of costs. 

 

4. Methods

There are many methods to ensure data continuity in certain scenarios, but be careful as there is rarely a one-size-fits-all approach to backups.

Mirroring: Is designed to mitigate single-point hardware failures. If your database server fails, having a mirrored server will ensure your data is available. Mirroring at another location may also solve router, switch and connection issues for external clients. Mirroring does not protect against corruption, viruses, user error or malice. On-site mirroring does not protect against theft, fire, flood, etc.

Removable Backup Media: Backups to media protect against issues such as corruption, viruses, user error or malice. If you leave these items on-site they will not protect against theft, fire and flood. If they are taken off-site, it will take longer to retrieve your data in case of loss. With backup tapes, hard drives and cds, the backup data itself is typically a day or older. If this method of backing up is your only method, be sure your business can survive with older data. Be sure to have multiple days of backups, or a weekly backup with incremental backups per day. Often times users will not report data loss until days after the event, by which time relevant backups have already been overwritten with newer, useless backups.

Non-removable Backup Media: Items such as NAS (Network Attached Storage), DAS (Direct Attached Storage) or SAN (Storage Area Network) can be used to backup servers, virtual machines and data. The issue with these is that they are not removable. This will not protect against theft, fire, flood, etc.

Be careful of proprietary systems used to backup your data. Be sure to audit your recovery scenario regularly to ensure your backups can be recovered. Companies go out of business, and items are discontinued. Do you have any backups on jazz drives? How difficult would it be to recover if you had to find a new jazz drive? Don’t know what a jazz drive is? Exactly!

 

5. Budgetary Concerns

With your sorted list in hand, you can now plan for the items you need to mitigate any disasters. Protecting against many scenarios may prove to be prohibitive in cost. If you do not make the budgetary decisions, be sure that your list is as comprehensive as possible. It is up to IT to determine the impact of all scenarios, and it is up to the budgetary members to determine how much they want to spend. If they say no, you have at least outlined all the possibilities.

In your cost analysis, include replacement or redundancy items such as:

  1. Backup Storage (Tapes & Tape Drives, Hard Drives, CDs)
  2. Backup Servers, NAS, SAN, DAS
  3. Mirrored Servers
  4. Redundant Connections (Internet and Cabling)
  5. Backup Routers, Switches, etc

Part of your impact analysis should include what is damaged or lost. If you have the tapes, but no tape drive, you will need to replace it in order to retrieve the data. Make sure you have the ability to read your backups when you need. If it takes 3 days to ship a new tape drive, but the cost is minimal, consider having a backup tape drive in stock.

While they are numbers out there for determining how much to spend on a backup and recovery system, you should make your decisions based on the impact and risk. If your data is your business’ main asset, you should spend a larger chunk of your budget to protect it. If time is critical in retrieving your data, the solution may include keeping extra hard drives, servers, router and switches in stock. If time is not an issue and an outage can be handled for days, you can order items at the time of recovery.

Determining budget can be a mix of preventative costs and the cost of downtime to the business (lost sales, lost productivity). Ideally disaster scenarios should have a cost to the business attached to them. If a server failure results in $0 productivity for the day, the overall impact can be many thousands of dollars per day – that fact alone may convince management to have a redundant server available.

 

6. Deployment and Testing

Don’t forget this step! Backups are useless unless they can be recovered. Take a weekend to simulate a likely recovery scenario. You may be surprised at all the “gotchas” when recovering data. Common stumbling blocks include not backing up database logs that are critical to recovery (ex. Exchange Server), or recovering to dissimilar hardware (Ex. RAID5 on a different controller).

Converting MySQL tables from Latin1 to UTF8

Many content management systems and forums were originally created using the latin1 character set and the latin1_swedish_ci collation in MySQL. The problem many of these systems are facing today is the growing demand for multi-language content using special characters that cannot be accurately represented in the latin1 character set. This is where utf8 comes in.

The problem with simply converting a database from latin1 to utf8 is in the data itself. When you convert a database or table to a different character set or collation, it does not convert the content held within the tables. What happens is users end up with ‘strange’ characters in their data.

You can prevent this by taking steps to protect the data before you convert the database or tables.

An overview of the steps:

  1. Backup the database. No, really, do it.
  2. Alter the string field types to their binary equivalents in all tables. This will protect the data during conversion.
    • VARCHAR to VARBINARY
    • CHAR to BINARY
    • LONGTEXT to LONGBLOB
    • MEDIUMTEXT to MEDIUMBLOB
    • TEXT to BLOB
    • TINYTEXT to TINYBLOB
  3. Convert the database and tables from latin1 to utf8 character set and latin1_swedish_ci to utf8_general_ci collation.
  4. Convert the binary field types back to their original string field types.
  5. Backup the resulting database.
  6. Finished

Ex. Generic convert column to BLOB from TEXT

ALTER TABLE tbl_name MODIFY column_name BLOB

Ex. Generic convert table to new character set

ALTER TABLE tbl_name CHARACTER SET charset_name COLLATE collation_name

Ex. Generic convert database to new character set utf8

ALTER DATABASE database_name CHARACTER SET utf8;

Are people the weak point in IT security?

Some time ago a co-worker had mentioned someone had been rummaging through her files on her computer. She had expressed some concern over the situation as the files in question were pertaining to a terminated employee. I nodded in sympathy and asked her the following questions:

  • When did this happen?
    Her response: After she had left work for the evening, but before she came in the next day.
  • Did you log-off of your computer in the evening?
    Her response: No.
  • Did you lock your office in the evening?
    Her response: No.
  • Is there anyone currently employed that would have an interest in those files?
    Her response: Yes.
  • Did you tell the Boss?
    Her response: No.

Because the office didn’t have any form of employee tracking, we could not find out who was in the building, let alone who accessed the files. While management was trying find out who did it, I was focusing more on the measures that could have been taken to prevent it. The worker had not logged off her machine or locked her office in the evening. As with all things in IT, the typical process response is always reactive instead of proactive. If the managers had taken my concerns seriously with regards to physical and virtual security months before, the situation would not have happened. This example was the catalyst I needed to affect a change in policy regarding passwords, automatic log-off, and certain aspects of physical security.

People, Process, Technology

Everyone has seen the People, Process, Technology Venn diagrams prevalent in business literature. I believe the most effective security practices involve a balance of all three categories to succeed – the process has to be sound, the technology relevant, and the people informed. Relying on any one of these categories too much will surely result in failure. No matter how locked-down a server is, if someone writes their password on a post-it note on the monitor, it is no longer secure. If there is no process in place to direct the people or the technology on the correct actions to take to be secure, it will fail.

Social Engineering

It seems the most vulnerable aspect of security lies in people’s tendency to succumb to social engineering tricks. Medium-sized companies are especially vulnerable as they may not have the means to implement physical security and also lack the close-knit employee base to detect outsiders easily. How easy do you think it would be to walk into a medium-sized company with a Canon shirt and convince them you are there to fix the copier?

I’d like to hear your own experiences with security, including what you think are the most important factors in creating a successful security policy.