I'm very much enjoying using my Mini 5101. It performs much better than I expected, and now that I have my corporate VPNs and SSH tunnels set up in Ubuntu I have a fully portable support platform, for just such an emergency. I even have a 3G USB modem working (more on that some other time as there is a new model coming out I want to try as well).
Just to clean up some loose ends, I think the ACPI issue has to do with a strange BIOS setting. Intel Atom processors are all single-core as far as I am aware, and yet the dual-core option int he BIOS was enabled by default. Once I disabled this I haven't had any other boot problems since.
The webcam was easy enough to set up simply by making sure the camera was enabled in the BIOS and installing the luvcview and uvccapture packages.
Why would I bother with Windows?
12.9.09
1.9.09
The miracle of DomainKeys
Labels:
encryption,
messaging,
security
I work for a company that has in-house software for sending email bulletins to registered customers. The largest problem has been fighting off the major email providers — Rogers, Sympatico, MSN/Hotmail and Google — from flagging these messages as spam.
For some, just making sure that you have a correctly configured MX entry in your DNS along with a proper reverse lookup on the IP is enough. Of course, you usually have to talk to your ISP about reverse lookups, even if you have your own DNS server. If you're a big enough company that you own your own block of IPs, then make your cheques payable to me at...
SPF is a step forward -- it works sort of like a "call-display" for email servers. Your mail server knows what IP is connecting to send the message and can look up the SPF record to see if this IP is allowed to send messages for that domain. However, for some ISPs and mail providers, this still isn't strong enough.
DomainKeys was first introduced by Yahoo! and was then developed further by other major messaging providers to become an open standard. It works on the principle that if you're a spammer, you won't have your own domain necessarily, or a DNS server under your control that you can post public encryption keys to, or be willing to invest the computational time required to digitally sign some of your email headers. (In the last case, the time really is only fractions of a second, but when you need to send out millions of messages quickly before you get caught, every millisecond counts.)
There are plenty of good tutorials on how to set up DomainKeys, so I won't go through step-by-step here. However, I can give you the general picture of what needs to be done. You will need:
After this is configured, you need to publish your DomainKeys public key so that other mail servers are able to verify the digital signatures on those message headers. This is accomplished by two DNS TXT records. The first is a policy record published as _domainkey.yourdomain and simply states whether or not all messages are signed and how seriously you are using DomainKeys. A good way to start is to set the text to "t=y o=~". this tells everyone you're in testing mode and that some messages may not be signed. You can tighten this up after you've confirmed everything is working.
The second is the selector record which contains the actual public key. This is published to your DNS as selectorname._domainkey.domain and in its simplest form contains "p=" followed by the long garbled string of characters that is your DomainKeys public key. There are other options available, such as being able to explicitly declare cipher type, length, etc. but this information is enough to get things started. Your mail server software also needs to be told the name of your selector record as that information is included in the message headers.
That's it.
The biggest protection this provides is proof that a message really did come from your domain. As many spammers try to spoof the message sender's address in order to bypass more simplistic email filters, this is a way of proving whether or not a message really was delivered from your mail server or not. At least for now.
For some, just making sure that you have a correctly configured MX entry in your DNS along with a proper reverse lookup on the IP is enough. Of course, you usually have to talk to your ISP about reverse lookups, even if you have your own DNS server. If you're a big enough company that you own your own block of IPs, then make your cheques payable to me at...
SPF is a step forward -- it works sort of like a "call-display" for email servers. Your mail server knows what IP is connecting to send the message and can look up the SPF record to see if this IP is allowed to send messages for that domain. However, for some ISPs and mail providers, this still isn't strong enough.
DomainKeys was first introduced by Yahoo! and was then developed further by other major messaging providers to become an open standard. It works on the principle that if you're a spammer, you won't have your own domain necessarily, or a DNS server under your control that you can post public encryption keys to, or be willing to invest the computational time required to digitally sign some of your email headers. (In the last case, the time really is only fractions of a second, but when you need to send out millions of messages quickly before you get caught, every millisecond counts.)
There are plenty of good tutorials on how to set up DomainKeys, so I won't go through step-by-step here. However, I can give you the general picture of what needs to be done. You will need:
- a mail server that supports DomainKeys
- a public/private key pair
- the ability to post a text record to the DNS server for your domain
After this is configured, you need to publish your DomainKeys public key so that other mail servers are able to verify the digital signatures on those message headers. This is accomplished by two DNS TXT records. The first is a policy record published as _domainkey.yourdomain and simply states whether or not all messages are signed and how seriously you are using DomainKeys. A good way to start is to set the text to "t=y o=~". this tells everyone you're in testing mode and that some messages may not be signed. You can tighten this up after you've confirmed everything is working.
The second is the selector record which contains the actual public key. This is published to your DNS as selectorname._domainkey.domain and in its simplest form contains "p=" followed by the long garbled string of characters that is your DomainKeys public key. There are other options available, such as being able to explicitly declare cipher type, length, etc. but this information is enough to get things started. Your mail server software also needs to be told the name of your selector record as that information is included in the message headers.
That's it.
The biggest protection this provides is proof that a message really did come from your domain. As many spammers try to spoof the message sender's address in order to bypass more simplistic email filters, this is a way of proving whether or not a message really was delivered from your mail server or not. At least for now.
27.8.09
Ubuntu and the HP Mini 5101
Labels:
hardware,
HP Mini 5101,
Linux
I just got a new HP Mini 5101 netbook and the first thing I had to do was rip out Windows and install Ubuntu. I'm just more productive that way.
Unfortunately, not all of the hardware works "out of the box". After two days of Google research, I've got two important things working.
Bluetooth and wired networking work fine with the default installation of Ubuntu 9.04. The trouble spots come from ACPI, WiFi and sound.
Getting the WiFi interface up and working was easy. Just install the linux-restricted-modules package and reboot. Everything comes up on its own then.
Sound was a little more tricky. You need to do two things:
I wrote this entry on my new HP Mini and I have to say the best thing about this netbook is the keyboard. It's almost full sized so I don't feel cramped or like I need a special keyboard wand.
More as I find other things that don't quite work as expected. I haven't tried the webcam yet, but I'm not sure that I even care about it at this point.
Unfortunately, not all of the hardware works "out of the box". After two days of Google research, I've got two important things working.
Bluetooth and wired networking work fine with the default installation of Ubuntu 9.04. The trouble spots come from ACPI, WiFi and sound.
Getting the WiFi interface up and working was easy. Just install the linux-restricted-modules package and reboot. Everything comes up on its own then.
Sound was a little more tricky. You need to do two things:
- Install the linux-backports-modules package for your kernel version (sudo apt-get install linux-backports-modules-`uname -r`)
- Add the line options snd-hda-intel model=laptop to the file /etc/modprobe.d/alsa-base.conf then reboot.
I wrote this entry on my new HP Mini and I have to say the best thing about this netbook is the keyboard. It's almost full sized so I don't feel cramped or like I need a special keyboard wand.
More as I find other things that don't quite work as expected. I haven't tried the webcam yet, but I'm not sure that I even care about it at this point.
13.8.09
VMware Server and Multi-Core CPUs
It's always been confusing to me as to what to do with VMware Server guests running on a host that has a multi-core processor.
First, just to clarify, from the information I have gathered VMware will assign a single physical processor to each virtual processor on a guest machine. If you have a multi-core processor, and your host operating system recognises each core as a separate CPU, then each virtual CPU on a guest will be assigned to a single core on your host.
You can get really fancy with assigning specific cores by tinkering with the VMX configuration file.
I've noticed that once I change my guest machine to use multiple CPUs, the CPU usage on my host shoots up to almost 100% and seems to stay there. Curiously though, this doesn't seem to affect any of the other processes running on the host. The answer, as stated in the VMware Knowledge Base, is that the host is executing the "system idle" process on the guest.
On Windows, when your processor isn't doing anything, Windows will execute a sort of 'do nothing' command that shows up in Task Manager as the "System Idle" process. It literally does nothing, and any unused CPU cycles go to this process. (Don't ask me why, I'm just the messenger here.) Unfortunately, VMware seems to translate this as an actual process and executes it on the host, but there it also does nothing. However, the host doesn't recognise this translation as an idle process and shows the VMware process itself as using those CPU cycles. So, even though it looks like your host is doing a lot while your guest is doing nothing, neither are really doing anything.
That still doesn't make me feel comfortable when I first see high CPU usage on my systems, but as long as it isn't causing any problems then I'll just leave things be.
First, just to clarify, from the information I have gathered VMware will assign a single physical processor to each virtual processor on a guest machine. If you have a multi-core processor, and your host operating system recognises each core as a separate CPU, then each virtual CPU on a guest will be assigned to a single core on your host.
You can get really fancy with assigning specific cores by tinkering with the VMX configuration file.
I've noticed that once I change my guest machine to use multiple CPUs, the CPU usage on my host shoots up to almost 100% and seems to stay there. Curiously though, this doesn't seem to affect any of the other processes running on the host. The answer, as stated in the VMware Knowledge Base, is that the host is executing the "system idle" process on the guest.
On Windows, when your processor isn't doing anything, Windows will execute a sort of 'do nothing' command that shows up in Task Manager as the "System Idle" process. It literally does nothing, and any unused CPU cycles go to this process. (Don't ask me why, I'm just the messenger here.) Unfortunately, VMware seems to translate this as an actual process and executes it on the host, but there it also does nothing. However, the host doesn't recognise this translation as an idle process and shows the VMware process itself as using those CPU cycles. So, even though it looks like your host is doing a lot while your guest is doing nothing, neither are really doing anything.
That still doesn't make me feel comfortable when I first see high CPU usage on my systems, but as long as it isn't causing any problems then I'll just leave things be.
13.7.09
64 bits: Check and Double-check
"I am not accustomed to saying anything with certainty after only one or two observations." -- Andreas VesaliusIn my last post I described how to determine if a processor is 64-bit in Linux using the information in 'cpuinfo'. Of course, if you really want to know for sure then you have to get the same answer from multiple sources looking at the same information.
Enter cpuid, a cross-platform utility that is a little more transparent than the information displayed from your OS. The bad news is that it appears the Linux version of this utility hasn't been updated since 2002, but the good news is that it shows the raw output from the queries to your processor and with a little research you can pretty much decipher it yourself, if the information you're looking for isn't already displayed in human underneath.
To focus on checking whether or not your process is 64-bit, you need to look at the raw output from the processor. Again, from my handy-dandy Pentium 4 desktop:
Doesn't make much sense to me either. But the important line is the one highlighted. Don't ask me anything about assembly language. I couldn't even figure out how to do this on my Commodore 64.eax in eax ebx ecx edx
00000000 00000005 756e6547 6c65746e 49656e69
00000001 00000f49 00020800 0000641d bfebfbff
00000002 605b5001 00000000 00000000 007c7040
00000003 00000000 00000000 00000000 00000000
00000004 00004121 01c0003f 0000001f 00000000
00000005 00000040 00000040 00000000 00000000
80000000 80000008 00000000 00000000 00000000
80000001 00000000 00000000 00000001 20000000
80000002 20202020 20202020 20202020 6e492020
80000003 286c6574 50202952 69746e65 52286d75
80000004 20342029 20555043 30302e33 007a4847
80000005 00000000 00000000 00000000 00000000
80000006 00000000 00000000 04006040 00000000
80000007 00000000 00000000 00000000 00000000
80000008 00003024 00000000 00000000 00000000
According to the CPU ID specification, an EAX input of 0x80000001 will set bit 29 of the EDX output if long mode is available -- in other words, if your processor is 64-bit capable. The EDX output is 0x20000000, which in binary is [ 0010 0000 0000 0000 0000 0000 0000 0000 ]. Counting from zero at the right towards the left, yup, that's bit 29 all right.
8.7.09
Am I 64-bit ready?
"You will never come up against a greater adversary than your own potential." -- Star Trek: The Next Generation 'Evolution'
I recently had to determine if a server running SUSE Linux had 64-bit processors or not. I did the usual stuff -- check the machine specs, which just said Xeon processor without explicitly stating 64-bit, then checked the kernel version, which listed itself as running on i686 rather than x86_64.
There had to be some way of either getting the specific processor model or some information about the hardware that would tell me for sure. After much Googling and gnashing of teeth, I found it.
At your command line enter cat /proc/cpuinfo and this will dump information for each core of each physical processor. The line to look at is "flags". As an example, the flags for my desktop Intel Pentium 4 list these:
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr lahf_lm
The "lm" flag I've highlighted stands for "long mode" as basically means that the processor is 64-bit. The complete set of flags is included in the cpufeature.h file in the Linux kernel headers.
6.7.09
A few things to get started
Labels:
About this blog
"The beautiful thing about learning is nobody can take it away from you." -- B. B. King
I am hopefully going to use this blog to share the occasional golden nuggets of information I come across during my IT escapades. May times I find that I have to do an awful lot of research for a particular issue, and then think to myself, Wouldn't it be nice to have this all compiled neatly together so that it's easy to find again? Not to mention someone else might need it...
Let's be honest. One thing the IT world isn't necessarily good at is documentation, unless you have a large department with loads of resources at your disposal. Granted there are good resources out there, but sometimes you either have an obscure problem or you have to get things from multiple sources and put them together to get all of the information you need. Hopefully I can put all of this in one place as I go, but we'll see how things work out. Sometimes the vision you start with isn't as clear as you think.
As I work in a very heterogeneous environment I come across some unique problems, particularly getting Windows and Linux to play nicely together. I won't tip my hand as to who my favourite is yet, suffice to say that one of them is more work but makes a lot more sense, whereas the other wants you to trust that they'll do things for you.
We'll see what is to come.
Subscribe to:
Posts (Atom)
Posts
