Sun Microsystems asked me to fill a survey for them and as a reward I would download Virtualization for Dummies e-book. They didn't mention, that it's publically available on their website, I'm not sure if they mentioned that it's a part of the Sun+AMD marketing campaign (if they had done that I'd like to see the results of the survey). Anyway, might be an interesting read and it's only 50 pages long (of which you should and will skip the first 9 pages full of marketing crap). Help yourselves:
2009/05/30
2009/05/27
Thoughts on troubleshooting methodology...
I never thought I could have any problems troubleshooting IT stuff, especially since it's been my day-to-day job for the last 3 years. However, not so long ago I was asked a couple of troubleshooting scenario questions in an interview and while I had the right feeling about the solution I still failed to break the problem down theoretically and when the time was up the interviewer didn't seem impressed with me (this is probably a nice way of putting it). I said to myself 'no big deal', as having my hands on the actual problem in the real world I would probably have had it solved in no time.
Or would I? Maybe yeah, but certainly without the 'no time' factor.
It got me thinking about how intuitively I have been doing my job sofar and that it's actually not the right approach for a troubleshoot professional. I decided I needed some structure, and here it is. I'd like to share my thoughts with you:
Or would I? Maybe yeah, but certainly without the 'no time' factor.
It got me thinking about how intuitively I have been doing my job sofar and that it's actually not the right approach for a troubleshoot professional. I decided I needed some structure, and here it is. I'd like to share my thoughts with you:
- Problem identification and data collection.
- If someone reported the problem, ask the reporter precise questions:
- What's wrong?
- When did it happen for the 1st time? (If relevant, where?)
- Did you change something just before the occurence? If so, what?
- Is the problem persistent or intermittent?
- Are you aware about other people experiencing the same issue?
- Have you tried any workarounds?
- What's wrong?
- What does an Internet search return? Maybe a fairly common issue globally?
What does your internal knowledge base return? Maybe a fairly common local issue? - What is the scope of the problem. Local? Global?
- If someone reported the problem, ask the reporter precise questions:
- Reproducing a problem.
- Where possible, create a test environment.
- Try to reproduce the bug. If succesfully reproduced, on Unix-like systems truss and strace are irreplaceable for runtime executable analysis. Similar tools for Windows are available too.
- Analysis.
- Visualize. Draw all the components and try to figure out visually where the problem might be hidden.
- Try to understand the potential dangers.
- Make a thorough research and refer to technical documentation.
- It is crucial that you understand the terminology.
- Visualize. Draw all the components and try to figure out visually where the problem might be hidden.
- Isolating the issue.
- Rule out factors that have nothing to do with the problem, but don't just assume - make sure they don't.
- Test the problem under many different conditions. Change one or two conditions at a time.
- Suggest and apply fixes.
- Always make a backup of any important data that can be lost.
- Escalate where appropriate.
- Understanding and verifying the solution.
- Make sure you understand what's going on before moving on to conclusions.
- Make sure you understand what's going on before moving on to conclusions.
- Creating Documentation!
- Document your findings in order to avoid effort duplication. Describe the symptoms, error messages and the solution and publish them somewhere. Try to organize your knowledge base so that finding information is easy after you get the same problem in after 6 months time...
- Document your findings in order to avoid effort duplication. Describe the symptoms, error messages and the solution and publish them somewhere. Try to organize your knowledge base so that finding information is easy after you get the same problem in after 6 months time...
2009/05/24
IPv6 on Gentoo.
If you've got IPv6 connectivity on Gentoo Linux, you may want to set some applications to prefer IPv6 over IPv4 addresses. This way, if both IPv4 and IPv6 addresses are returned from the DNS server, the application will go with the latter.
- Add ipv6 to the default USE flags in /etc/make.conf. Otherwise the applications built by emerge, will not necessarily be IPv6 aware.
- wget
Edit /etc/wget/wgetrc file and uncomment the following setting:#/etc/wget/wgetrc
Consequently, /usr/bin/emerge which uses wget as download engine, will try to pull the traffic via IPv6 first if only the DNS server of your mirror returns an IPv6 address.
# [...]
prefer-family = IPv6
# [...] - rsync
Edit /etc/conf.d/rsyncd and add --ipv6 to the RSYNC_OPTS variable.
2009/05/03
IPv6 Google Search Firefox Plugin
If you already have IPv6 connectivity you should consider pointing your Firefox to http://IPv6.Google.com instead of www.google.com as your default Search Engine.
Google provides IPv6 Google search as of 5/13/2008, as we read from the official blog:
You can do it with this OpenSearch compliant Firefox Search Plugin
Search is performed over IPv6, but the search suggestions go over IPv4 network.
It's issued under GPLv3.
THERE IS NO WARRANTY FOR THE PLUGIN. IT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PLUGIN IS WITH YOU. SHOULD THE PLUGIN PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
Troubleshooting tips:
Google provides IPv6 Google search as of 5/13/2008, as we read from the official blog:
You can do it with this OpenSearch compliant Firefox Search Plugin
Search is performed over IPv6, but the search suggestions go over IPv4 network.
It's issued under GPLv3.
THERE IS NO WARRANTY FOR THE PLUGIN. IT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PLUGIN IS WITH YOU. SHOULD THE PLUGIN PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
Troubleshooting tips:
- "Failed to Connect" in Firefox - your computer can resolve ipv6.google.com DNS address but can't find the route to the host.
Solution: - "Address Not Found" in Firefox - your computer can't resolve the ipv6.google.com DNS address.
Solution:- Go to about:config in the address bar of Firefox and make sure that network.dns.disableIPv6 is set to False
- Check your DNS settings.
A simple javascript test for IPv6 connectivity.
JavaScript test for IPv6 connectivity to IPv6.google.com.
/*
* http://blog.ooz.ie/2009/05/test-for-ipv6-connectivity.html
*
* A simple test for IPv6 connectivity to http://ipv6.google.com/
*
*/
function loadOK() {
// Image loaded OK.
alert('Success. IPv6 connectivity to Google detected.');
}
function loadError() {
// There was an error loading an image.
alert('Error. No IPv6 connectivity to Google.');
}
var GoogleV6Logo = new Image();
GoogleV6Logo.onload = loadOK;
GoogleV6Logo.onerror = loadError;
GoogleV6Logo.src = "http://ipv6.google.com/intl/en_ALL/images/logo.gif";
Subscribe to:
Posts (Atom)
