Feeds:
Posts
Comments

Well, no actually, you won’t find that information here.

I joined LinkedIn about four years ago because of a lost job.  Allegedly, LinkedIn was the supreme way to get noticed and locate my next job.  It worked…sort of.

I wanted to switch from the craftsman work that I had been doing all my life to a job in technology.  However, no one listened.  My last job had included a ton of new tasks learned in technology but it seemed folks just weren’t interested in either my age or lack of classroom learning.  Neither of which is my point today.

Since I found my current job, which I am happy at doing, the stream of folks looking at my LinkedIn profile and sending me requests to find someone to fill their “urgent” need continues unabated.  I get headh…I mean recruiters contacting me about once every other month.  Most jobs aren’t even in my wheelhouse.  Since I know I need to maintain my LinkedIn profile (losing a job teaches you that one), I have endured the e-mails.  Occasionally, I answer them and often just ignore them.

However, in a bit of a snarky Friday mood, I decided I would fulfill my intention of posting what I really feel about recruiters looking to fill positions.  So, the following is my idea of the way to summarize what I am looking for in the ultimate position.  And, yes, it is currently in my LinkedIn profile.

To the scanning robots and recruiters that pass by, please pay attention.

If you are interested in contacting me about a possible job opportunity, I appreciate that. However, please allow me to elaborate on what that job should look like.

I enjoy fixing things. Lots of things. I am especially good with things that have wires and things that heat or cool. However, I also dearly love being a hacker.

Notice, I did not say IT professional, desk top support, nor programmer, though these three things can be useful. I like to work with the Linux OS. I ONLY like to work with the Linux OS. I am not picky. It can be Ubuntu, Debian, Mint, or any of a dozen other flavors. I DO NOT like to work with Microsoft in any shape form or fashion. I love to build Linux servers, especially LAMP servers. I am very good with DNS and e-mail systems. I enjoy writing utilitarian programming in C, Perl, or Python. I build a mean SQL table. I do not build pretty, cool, or zoomy web pages. Please take this as an axiom: “Dave does not do pretty.”

I am well educated but I learned all my IT skills on my own and those are extensive. My first computer that I owned was a Timex Sinclair in 1980. But, I have worked on many different types of systems from DEC to embedded. I am just as qualified as your twenty-something with all the alphabet soup and worth just as much in salary. I do believe in rules and policies, Dave’s rules and policies. I deal in quality not quantity. If you want a massive database intensive GUI-interfaced application built in the next twenty minutes; I’m not your guy. If you want your stuff to work, period; I am your guy.

I believe a person should wake up early and work all day and then GO HOME!  I do not work late for meetings or spreadsheets.  I will work over if the building is actually on fire or involved in a flood that endangers lives.  But otherwise, the work will be here tomorrow.

If any of this does not fit your sensibilities or your cookie cutter mold, please pass on by, no harm, no foul. If you are serious about hiring someone that really likes his work and believes in doing it well, you know how to reach me.

We’ll see how this goes.

Advertisements

I guess you might say it’s about time I got a post up on this blog.  Well, I’ve been busy learning a lot of new technology and putting some old technology to work.  I took a new job about six months ago (OK, I had to, but whatever) and have been using something that I wished for a long time ago, but it was an infant in those days.  I am talking about the BACnet open protocol for building automation systems.  In my particular area, this mostly involves equipment related to heating, ventilating, and air conditioning (HVAC we call it).  However, BACnet can be utilized in many different areas of facility systems such as water systems, boilers, fire detection and protection, and even access control.  This blog is going to be a part of a series I am going to archive on my journey to teach myself to build an application for BACnet on the Linux OS platform.

First, let me start where the starting began.  Though I am a craftsman and work in a technical field (HVAC, remember), I have been interested in computers and programming since at least 1980.  After cutting my teeth on BASIC on the Atari, my first compiled language that I learned for the PC was C.  Despite being interested in various types of programming languages that have come (and gone) since then, I still often revert back to C.  I have gone for a long time feeling as if the programming world is getting too far ahead of me, so I have made it a goal of mine to sit down and learn as many of the new things that are out there as I can.  As such, becoming completely proficient in C, Python, Perl, and HTML/CSS is something that I am actively pursuing.  In addition, I am also working on becoming proficient in MySQL and its interrelationship with the programming languages.

Connected with this all is my enjoyment of working on the Linux platform and my disdain for the fact that nearly everything seems to default to Windows.  Currently, I operate two laptops with Ubuntu on one and Linux Mint on the other.  I also maintain one Ubuntu Server for myself.

Can I say I really like Linux?  Yes, I can.

It is my motto that I dislike any kind of a “black box”.  A black box is something where you can do something with it, but you don’t know how it does what it does.  I dislike that with a passion.  Windows is a black box to  me.  Much software is a black box to me.  Spending my time learning the guts of Linux (which is very doable) as well as things like C or even BACnet helps me to understand how to make computers do what I want and not what they want.

Now, all that being said, when it comes to learning styles, I really prefer to “DO” things.  I can read books.  I can listen to lectures.  I can write things on paper, but if I really want to learn something, I like to do it.  In learning things about computers, not only do I want to do things, but things that are useful and practical.  While I can sit down and write and run the sample programs in a book, those really don’t teach me how to apply the knowledge I am gaining.  I prefer to DO something in the real world where I can see the program work and make my life easier.  Therefore, as I learn the knew technologies, I need a real world project.  I have been looking around for some and I thought I had a couple, but when I found out that learning BACnet programming on Linux was not only useable, but hadn’t really been done to date, I had come to the end (beginning) of my road.  Thus, this blog and the journey we are going to be on.

Before we dive off into code, let’s cover some history about BACnet.  When I first began dealing with building automation systems during the 1980’s, everyone did their own thing.  Barber-Colman that I worked for back then, had a system.  Johnson Controls had theirs.  MCC Powers had theirs.  None of these systems allowed you to shop around when you needed new controllers or software to run those controllers.  The protocols for the communication networks between all the controllers were proprietary information.  Therefore, if Johnson Controls did you, the customer, poorly; or if your new wing suddenly ended up with a different brand, you were just stuck.  If you had control of the situation, you had to choose between completely removing the entire network you had in order to choose a different provider.  In many cases, where facility managers and technicians did not have control, building A would have a Johnson system, building B would get one from Barber-Colman, and building C might have yet a third brand.  The building operator then had three different computers and terminals on his desk monitoring systems that didn’t talk to each other or share information.

In the late 1980’s, some of the newer controls companies and integrators (contractors that specialized in controls systems) starting talking about creating an Open Protocol.  Many facility managers and technicians were also getting on board with this idea. If you had an open protocol, then everyone could install what they wanted.  I might install Barber-Colman this time and Johnson Controls might be my next choice, but everything talked together on the same network.  The bigger companies (Barber-Colman, MCC Powers, Johnson Controls, Honeywell) were against this idea because it meant sharing company secrets and losing profits.  With a locked in protocol it was in your (the facility manager’s) best interest to purchase additional controllers and accessories from the same company because everything fit together.  The big players had locked in future sales with proprietary protocols. But things were about to change.

In the 1990’s, the forces behind Open Protocols for building automation gained enough traction and cohesiveness that a standard developed, BACnet.  BACnet is a protocol standard that was eventually adopted as such by ASHRAE (American Society of Heating, Refrigeration, and Air Conditioning Engineers).  The BACnet.org web site has much more history than I can put in here.  If you want it all, go there.  Suffice to say, that though it has taken a great deal of time, BACnet has caught on.  I currently work on a BACnet compliant system.  It is from Reliable Controls.  However, we have equipment on the network from ABB drives to RBI boilers that plug in and talk to the network without any additional work on our part.  The controllers and devices are self discoverable and after some upgrades to the BACnet standard can now work over regular IP networks right along with standard TCP/IP traffic.

However, just about all of the workstation software that talks to BACnet networks is Windows based.  My project will be to try and use an Open Source BACnet protocol stack written by Steve Karg and located at Sourceforge.net to create my own Linux version of a BACnet application.  I already have the stack installed on mBACnet protocol stacky Linux laptop and can see it do some work.  My intention is to integrate the little pieces of the stack into a cohesive whole.  Along the way, we’ll learn something about C programming, CGI programming, and probably some Perl and HTML/CSS as well.  So, come along and let’s see if we can get into any trouble, or not.

Project Update

I have been a little out of touch recently. If I have missed you I apologize. Real life is intruding a good bit right now and I am trying to keep up.

I have done some CSS work to the T.A.R.D.I.S. Server’s main page. I will admit that cool graphics are not my thing. I am a ‘hacker’ at heart, well comfortable with making code behind the scenes. So, if you are not a fan of various shades of gray, it cannot be helped.

Because I am in the midst of both a job search and trying to discern if I can just work for myself, I’m rather busy at the moment and haven’t done much with the server. I am also in the middle of trying to sharpen and add to my IT skills in the hopes of landing an IT position. It would be really cool to find the right sized organization that needs a competent Linux admin, even if it’s just for a while.

I’d like to work for myself more, but I’m rather cautious. That regular paycheck for a real job is very tempting.

In any case, stay tuned. I do hope to add some more CSS zip to the pages and possibly try and build a min-CMS while I’m at it.

Good luck and may all your bytes fall in the right places.

SSL certification final steps…

Hello all. It’s been a while again. I’ve been busy as now my job is to find a new job. I haven’t had to look for work in ages and now I am going to try and seek a job as a Linux admin or similar. That means there is extra work to be done.

However, I haven’t forgotten the process of creating our self-signed certificates. Today, we will finish everything up. Though there were several steps left as of my last installment, I am going to depend on the person that gave me most of my information. He is a blogger at langui.sh. It is his work on establishing self-signed certificates with OpenSSL that helped me a great deal. I am going to have you go and look at his posts on establishing a root certificate and creating your self-signed server certificate.

I’ll get to that in a minute, but first let’s explain the why’s of our next steps.

You will need a root certificate for two reasons.  First, and most important, since you are your own Certificate Authority, you will submit your server certificate requests to your own CA.  Without a root certificate in your stores, you wouldn’t be able to do so.  Second, When dealing with some MUA (mail clients), such as Microsoft Outlook, you will not get Outlook to properly connect to your server until you actually place that root certificate into the client PC’s certificate stores.  We will do that in a separate section below.

So, in order to proceed with creating your root certificate and self-signed certificate (what I call your server certificate) go and process through this tutorial at langui.sh here.  Once you have read through the author’s tutorial and completed setting up both the root certificate and your server certificate, come back here.  Also, do not forget to use your custom configuration file you created from our previous post, complete with the added section on alternate server names.  Without the alternate server names, Microsoft Outlook will still reject your server as trusted.

OK, hopefully, by now, you have a root.cer saved in your myCA folder in the correct location.  You should also have a server certificate and a private key created for your server certification.  The certificate folder should be world readable (able to be read by anyone, but not allowed to be written to).  The privkey folder (or whatever you named your private key folder) should NOT be readable by anyone other than root.  In addition, you will need to go to your MUA configuration (I use dovecot, yours may be different) and change the line for your SSL certificates to point to your myCA folder’s location and the new server certificate file.

As an example, in dovecot, one would go to the section of dovecot.conf like below:

# PEM encoded X.509 SSL/TLS certificate and private key. They’re opened before
# dropping root privileges, so keep the key file unreadable by anyone but
# root.
#ssl_cert_file = /etc/ssl/certs/dovecot.pem
#ssl_key_file = /etc/ssl/private/dovecot.pem

Then, you would uncomment the two ssl_xxx_file lines and change them to point to your myCA folders and files.  It would probably look something like this:

# PEM encoded X.509 SSL/TLS certificate and private key. They’re opened before
# dropping root privileges, so keep the key file unreadable by anyone but
# root.
ssl_cert_file = /home/myusername/myCA/certs/mycertname.pem
ssl_key_file = /home/myusername/myCA/private/myprivkeyname.pem

After saving the changes, then reload dovecot and you are ready for the next step.  By the way, I have included the comments from dovecot’s config file for a reason.  Make sure than when you create your server certificate that it matches the type (x.509 or whatever) that your MUA needs.  Langui.sh’s instructions do create x509 certificates, but your MUA may or may not use this form.  I do know that when you install the root certificate into Microsoft certificate stores, you will need to change the root certificate to, I think, a PK12 form.

At this point, you should be able to connect to your MUA (Mail User Agent) through your client of choice (Outlook, Thunderbird, etc.).  If you use Thunderbird, you’ll get a pop-up window warning you of the untrusted server.  It should show you the certificate’s origin and there is a button so you can view the certificate’s values.  Once you have done this, there is a button on the pop-up so that you can tell Thunderbird to trust this certificate.  You’ll have to do it all over again when you try to send your first e-mail with the new server certificate in place, but usually only if you also used the same certificate for your MTA (SMTP server).  As a side note, you will have to do this similar procedure on Mac Mail.  I’ve done it, but I forget how.  You should be able to Google the instructions.

However, if you are using or supporting Microsoft Outlook clients, you have a second step.  You will have to import the root.cer file into Microsoft’s certificate stores.  Microsoft does not allow a button to just override the normal method.  In that case, you will have to install the root certificate you created using the instructions above into Microsoft’s Trust Center or Trust Stores.

To install a root certificate in Windows 7 (Vista also, probably) go here.

To install a root certificate in Windows XP go here.

Yes, both of these are daunting to say the least.  In my own opinion, Microsoft intentionally makes it very difficult to use anything other than commercial third-party certificates in order to keep folks happy about security.  No matter how diligent that is, it defeats the purpose of being able to do one’s work.  Read these tutorials (the Microsoft ones) carefully when using.  I do know from experience that the XP trust stores won’t allow it to accept a certificate that has a problem.  I don’t know about Windows Vista or Windows 7 because I didn’t support any clients on those machines, but they are probably similar.

The best way to test and see if your certificate is installed correctly on your server is to use something like SSL Shopper’s SSL checker.  This is a page where you place your domain name in the box and click the button.  It tests your web server’s https//: settings to see if your certificate is valid.  However, that is a whole different set of tutorials.  Check your web server’s documentation to see how to set up a minimal https:// site using the certificates you generated.  On Apache it is not difficult.  That is the only caveat of using the SSL checker.  However, using the checker will help you find any faults you may have made in generating your certificate.  These are pretty simple to fix just by generating a new certificate and correcting any deficient values.  I used the SSL checker as a way to see if I had set my alternative domain names correctly.  When you have quite a few PC’s to load root certificates in, it helps.

One final thing, after you have correctly installed all certificates etc., you need to make sure that the appropriate encryption ports are open on your firewall to allow your MTA or MUA to receive or send via SSL.  You will also need to make sure that your MUA and MTA can use pops or imaps to send and receive mail.

If you have remained this long, you deserve a medal or a raise.  Your patience is to be commended.  Setting up SSL certificates using your own CA authority is tedious.  There are a lot of steps to go through and many places that you might make a small mistake.  However, considering the alternative costs of third-party certificates when you may not really need one is worth the effort.  At the very least, you will know what is involved in SSL encryption and you will have a decently secure setup for your server.  Thanks for reading and I hope yours works as well as ours has.

 

Hello readers.  Yes, I am still a bit behind in keeping up with my tutorial on SSL certification.  I will be catching up on that soon as I have another server in need of certificates and it will allow me to double check my work.  There will be more sections coming soon.

Recently, my job ended and now I am in the search for another.  Though I have some time to do that, looking for work is hard work.  In addition, I have been sharpening some of my coding and web skills as well.  I recently spent a good deal of time on Codeacademy.com learning about CSS.  Why did someone not tell me this was so easy earlier?  I’ve also recently began sharpening my skills on MySQL and learning PHP.  These technologies have made me see what the underlying methods are in many sites like Facebook and Twitter.

So, I ask for your patience as I get things going and see if I can a) locate an actual job doing something related to Unix/Linux and web design/coding or whatever you wish to call it these days.  and b) get my own server project looking and working better.  By the way, if I haven’t pointed you all to it just yet, I finally ponied up the money for a domain name.  The server is at http://www.tardisgallifrey.com.  Come and  have a look see.  I also have it set up as an MTA (mail server).

Until later then.  Keep coding!

We have been working on the steps necessary to properly build a self-signed certificate system so that a server owner can engage the SSL encryption features for his or her server.  In our case, we are working primarily on doing so for a mail server, but many of the same steps work for other SSL certificate needs.  I began this lesson under the post “Ubuntu SSL, and how to overcome Microsoft Problems.”  This is the third step on the list in that post and will cover how to create a local config file for OpenSSL so that you can generate certificates.

Before we take off on writing our local config file, let’s review our steps to this point: 1. we have ensured that OpenSSL and all necessary libraries are installed, 2. we have created and set up our folders and files to create our Certificate Authority.

Now, down to business.  Many of the tutorials begin by have you generate your public/private encrypted key pairs.  However, as some of that work depends upon what is found in the OpenSSL configuration files, we will begin there.  When you (or your distribution) installed OpenSSL on your system, it placed a configuration file in /etc/ssl.  This is a generic, one size fits all, configuration file with lots of stuff and settings you might not even need.  Its name is openssl.conf, and you should examine it and check it out.  I would not recommend deleting or modifying it as you might need features of it at another time.

However, we do not have to depend upon this config file for our business.  OpenSSL allows us to specify a local .conf file to be used in our certificate generating commands, so let’s build one that is important to us.

This is how mine looks, but the names have been changed.  I placed it in my /myCA folder so that it is available when I generate server certificates.

[ ca ]
default_ca = myca

[ crl_ext ]
authorityKeyIdentifier=keyid:always

[ myca ]
new_certs_dir = ./newcerts
unique_subject = no
certificate = ./certs/root.pem
database = ./index.txt
private_key = ./private/privkey.pem
serial = ./serialfile
default_days = 365
default_md = sha1
policy = myca_policy
x509_extensions = myca_extensions

[ myca_policy ]
commonName = supplied
stateOrProvinceName = supplied
countryName = supplied
emailAddress = optional
organizationName = supplied
organizationalUnitName = optional

[ myca_extensions ]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
keyUsage = digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth
crlDistributionPoints = URI:http://path.to.crl/myca.crl
subjectAltName          = @alt_names

[alt_names]
DNS.1   = server1.example.com
DNS.2   = server2.example.com
DNS.3   = mail.example.com

I saved this file as myca.conf, but you can use any name that is meaningful to you.  You could need one of these for each server’s primary domain names.  However, I am going to show you how to use this as a generic config file.  Now, let’s examine some of the pertinent features.

The first line:

[ ca ]
default_ca = myca

–is required and simply tells us which section of our config file is the default “ca” or certification authority.  There are probably commands and methods to have a multi-talented config file, but I haven’t studied this past my own needs.  Feel free to do so.  When you look further down in the config file, you will find a section that starts with [myca].  That is where our certificate generation command jumps to upon starting this file.  We’ll get there in a moment.

The next section and line–

[ crl_ext ]
authorityKeyIdentifier=keyid:always

–are items that I copied over from the tutorials I used.  Though I could look up what they mean and probably find out whether or not I need them, I choose not to at this time.  These two lines are examples of those.  Copy them into yours as I have into mine.  If there are lines that I do not explain, refer back here for why I don’t.  Short answer, do as I do.

Now, we get to an important section–

[ myca ]
new_certs_dir = ./newcerts
unique_subject = no
certificate = ./certs/root.pem
database = ./index.txt
private_key = ./private/privkey.pem
serial = ./serialfile
default_days = 365
default_md = sha1
policy = myca_policy
x509_extensions = myca_extensions

–Each of these lines are here because we said our [ default_ca ] section is the one named “myca”.  Most of them should be almost self explanatory as they are paths to files that we will use to make and sign certificates.  The paths are all started with “./” because we will run our certificate generations from inside the “myCA” folder we created.  The line “default_days” lists the default time that certificates will last once generated.  The line “default_md” sets the encryption type we will use, by default.

The two lines, “policy=myca_policy” and “X509_extensions=myca_extensions” refers us to two other sections of instructions for building our certificates.  You should also notice that these references refer to sections that begin with a title in the format [my_new_section].

The next section is our [ myca_policy ] section and it is like this:

[ myca_policy ]
commonName = supplied
stateOrProvinceName = supplied
countryName = supplied
emailAddress = optional
organizationName = supplied
organizationalUnitName = optional

–This is where the real ‘guts’ of our certificate generation takes place; at least as far as it makes it OUR certificate.  This section is literally the fields for the certificate that personalize it to our needs.  Most of the fields are self-explanatory, but I’ll explain a few because they are not.  When you run the certificate request command, these will be asked to you as questions and you’ll supply the appropriate answers.  Those answers will then become field values.

The most important field value for you to supply is the one for “commonName”.  It is not your name, it is the SERVER’s common name such as example.com.  This will be more important later on for some folks.

There are two ways (probably more than two, but I see two) to use this section.  The way I have set it up, many of the current field values are “supplied”.  This means you will have to supply the appropriate field value when the certificate request is made.  This is what makes this a fairly generic certificate config file.  Each time you run it, you can put in new data for a new certificate.  However, you can also supply default values.  You do that with an extra config setting in the [myca_policy] section like this: distinguished_name = [req_distinguished_name].  Where “req_distinguished_name” is a label to a section where you’ll define defaults (or prompts) for your fields.

That section would look something like this:

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = AU
countryName_min                 = 2
countryName_max                 = 2

–Each field would be defined like countryName is above.  The value after countryName is a user prompt to help the certificate operator come up with the right answers for the field.  The rest of the values list the default and the minimum and maximum character values of the field.  When the certificate generator encounters this section, it will display to the user:

Country Name (2 letter code) [AU]?_

–where the operator can know he or she is expected to enter a 2 letter country code or he or she can choose to hit ENTER and take the default of AU for Australia.  If you’ll look up the documentation for the openssl.conf file you can find lots of ways to customize your configuration.  There are lots of fields with various options that can populate a certificate. But, if you are like me and you’ll only be generating a few certificates, simpler is probably better.

The [ myca_extensions ] section contains several needed fields.  Most of them you just enter as they are listed.  However, for those that will have servers interfacing with Microsoft products, the last line “subjectAltName = @alt_names”  points your config file to this very important section:

[alt_names]
DNS.1   = server1.example.com
DNS.2   = server2.example.com
DNS.3   = mail.example.com

–These fields will be added to your certificate generation process.  They are only useful in products like Internet Explorer and in my case, Outlook.  Allow me to digress a little and you’ll see why it’s important.

In our facility, the majority of folks use Microsoft’s Outlook as their mail client of choice.  I on the other hand, use Thunderbird.  When I connected to our mail server using SSL encryption, Thunderbird did squawk about the “untrusted” certificate from the mail server.  No problem.  Thunderbird gives me a button that overrides normal procedure and allows me to “trust” this certificate. End of problem.

However, on Outlook, instead of just an “untrusted” certificate error, I cannot choose to override normal procedure because the server names do not match the certificate.  That is because you entered your regular domain name for “commonName” above, but  you named your e-mail server something like  smtp.example.com or mail.example.com.  Outlook does not strip out the subdomains.  It matches the server name it is talking to and compares it literally with the commonName field.  No exceptions allowed.  The alternate names section allows you to supply the alternate names of the servers you use (subdomains) so that Microsoft’s trust engine can accept these other names as being valid.  In a later post on Microsoft, you’ll have to still take another step, but we’ll save that for later.

Alrighty then!  We have sufficiently written a local config file that matches with our uses of certificate generation.  We have included the proper sections and fields needed for a basic certificate and we have ensured that all our possible server names have been included so that our users (hopefully) will have less trouble using the SSL encryption features provided by OpenSSL.  Now we are ready to move forward with generating our own self-signed certificates by creating the root certificate’s public and private key values.

To my readers, what stalwart few they are, I have been remiss in not finishing out my tutorials on how to set up your SSL certificates.  However, I am about to have some more free time, not by choice, so I intend to catch up.  Please be patient and we will finish this lesson together.