Uncategorized

You are currently browsing the archive for the Uncategorized category.

This is one of those ‘I must be living under a rock’ things.  I’m not sure how I’ve never heard of TMUX before but it’s really pretty awesome.  I initially came across it when searching for a way to share a terminal session with another user.  It does that quite well but it’s also a great terminal session manager allowing for pane, window, and session management.  Let’s take a look at a quick example to show you what I mean.

Here we have a server called ‘tmuxtest’.  The server already has TMUX on it by default but if it’s not there you can easily install it (sudo apt-get install tmux, etc).  So let’s say I want to start a new session.  The easiest way to do this is to just type ‘tmux’..

Now we’re in TMUX.  We are in what’s called a ‘session’.  The session can contain multiple panes and multiple windows.  For instance, if I wanted to create a second pane I could do by pressing ‘Ctrl-b + %’…

Notice that the screen on the right, the new one, has a green boarder around it.  That’s my active screen.  Now if I want to split this screen horizontally I can use ‘Ctrl-b + “‘…

You might be figuring it out, but ‘Ctrl-b’ is the magic key sequence in TMUX.  Here’s a list of commands that relate to panes…

As you can see, we can select different panes pretty easily by using the arrow keys and end them as we typically end windows with ‘exit’.  So that’s all well and good, but that didnt buy us much.  What else is there?

Well before I forget, remember that we’re in a session that I can attach and detach to.  Have you ever needed to start a download on a remote server and worried about losing your connection and having the download crash?  I have!  So why not run it in a session?  Simply start a TMUX session, start the download, and then detach from the session (Cltrl-b d)…

Now I shut my laptop and go home.  When I get home, I get on VPN, log back into the server, and see that the download is still running (the size is increasing) and the TMUX session is still there which I can reconnect to…

I can reconnect to the session by using ‘tmux attach -t <session ID or name>’ which in this case is ‘3’…

Pretty cool huh?  Here are some commands that are relevant to dealing with sessions…

And before I get too far ahead of myself, I should talk about windows as well.  A session can have multiple windows.  For instance, if I start a TMUX session I can press ‘Ctrl-b c’ (I’ll do it twice)..

Notice how along the bottom I now have 3 sessions?  They’re labelled 0, 1, and 2.  I’m currently on the ‘2’ sessions which we can tell by the asterisk being next to it.  I can change between windows by pressing ‘Ctrl-b p’ or ‘Ctrl-b n’ which stand for previous and next.  Here are some other commands related to windows…

Ok – so now for the terminal sharing.  We know how to create a session and how to attach and detach from them.  Surprisingly, that’s all we need to know to share a session between two users using the same account.  For instance, let’s have two users log into the server both using the ‘user’ account. We’ll have the first user create a session called ‘watchme’ with the command ‘tmux new -s watchme’.  Now if we have another person log in to the same server, with the same user account, they can see that session by using ‘tmux ls’…

All the second user has to do is attach to that same session using the ‘tmux attach -t watchme’ command…

Pretty slick huh?  But what about if you have two different users on the same server?  Unfortunately, it’s not as easy to share sessions between multiple users, but it is still possible by creating a socket that both users can reach.  For instance, if we log into the same server with two different users we can see that by default user2 can’t see user1’s sessions…

However, we can specify a socket file for TMUX to use and make it accessible by both users like this…

Notice how we create the session under user1 as normal with the exception of passing a parameter to the ‘-S’ flag.  The ‘-S’ flag tells TMUX to create a socket at the specified location, in this case ‘/var/tmp/tmuxsocket’. Then I detach from the session, and change the permissions on the file so that all users can access it with the ‘chmod 777 /var/tmp/tmuxsocket’ command.  Now, user2 can see the session by telling TMUX where to look for the socket.  Is this secure?  Gosh no.  Is this probably something you should only do with another user that you fully trust?  Yes.  But if you fit that criteria, it’s drop dead simple to share a session.  That or you can both use the same account as we saw in the first example.

In any case – TMUX is pretty awesome.  I plan on making it a permanent addition to my toolbox.

A new adventure…

As the title says, I’ll soon be starting off on a new adventure.  After almost 6 years working in various networking roles at United Health Group I’ve decided to move on.  The decision to leave wasn’t an easy one for me to make.  I’ve built lots of great relationships and had the opportunity to work with some truly gifted individuals.  Many of the people I worked with have had a profound impact on my development as a network engineer and architect.  While I can’t possibly list all of the names, I want to sincerely thank all the people that have motivated and supported me during my tenure with UHG.  There are countless people that gave me opportunities I couldn’t have had anywhere else and for that I am truly grateful. 

So while it’s hard for me to close out this chapter of my career, I’m anxiously looking forward to starting the next one.  In late August I’ll be starting in my new role as a network engineer at IBM within the Watson business unit.  I’m excited about the opportunity and literally can’t wait to dig in!

In other news, some of you may have noticed that there hasn’t been a lot of new blog content lately.  The reasons for that mostly fall under the ‘usual suspect’ category.  Work has been extremely busy and the bulk of my free time has been dedicated to a new project I’m working on (more to come on that soon!).  Needless to say, once that project is completed, and I’ve settled into my new role, I look forward to getting back to a more normal cadence of content creation here on the blog.

Thanks for hanging in there with me, it’s been a busy summer!

Saying ‘open networking’ is a little like saying ‘SDN’.  Without context, it can mean almost anything.  Some argue it’s more around options on platforms while others believe it’s more to do with software.  When I think about open networking, I think about these main points…

Generic Platforms – White box switches are all the rage these days and for good reason.  A white box switch gives you the option to run a variety of different software platforms on generic hardware.  This means you don’t need to buy a piece of proprietary hardware to run your proprietary software on. The net result here is that vendor lock in goes away.  It also means that you don’t need to wait years and years to buy new hardware to get new software.  

Linux – Linux is used EVERYWHERE.  As it turns out, it’s already used quite extensively in networking platforms, but not how you might imagine.  Most networking vendors use a highly customized version of Linux and the Linux kernel.  The reason for this is simple – Linux wasn’t built for networking.  Long story short, traditional network vendors had to modify the Linux kernel to get it to perform fancy network functions.  So while we’re starting to see a much larger emphasis on networking in Linux, we aren’t to a point where native Linux has feature parity with all network functions.  That being said, some vendors believe they can soon deliver feature parity and build their products with a native Linux operating system.  This is a win for numerous reasons.  First off, stability just went through the roof.  You’re now working off of a base that’s not just used by your company and your platform, its used everywhere.  Secondly, if the platform is based off of native Linux that means that all of my other native Linux software will just work.  Again – this comes back to giving us more options which is hugely significant here. 

Open source software – While I’m not (yet) a huge contributor to open source software, I see tons of value in the concept.  Look at it this way, a vendor open sourcing code just went from tens or hundreds of programmers working on their platform code to millions.  This opens the door for all sort of possibilities.  Improved testing, quick resolution of defects, quicker implementation of new features, and greater flexibility to name just a few.  However, open sourcing code does not guarantee any of this.  It’s very important for successful projects to have a strong community around them. Without a community interested in the project’s success, you haven’t changed anything besides where you store your code. 

So while I agree that open networking is a win, I also think we’re at the very beginning of a long journey. Vendors are just starting to see the value in this model and not all of them are going to jump all the way in. And while we as end users see extreme value in many aspects of what open networking promises, most vendors have spent years making their money off of proprietary closed systems.

On a closing note – I think it’s also fair to mention the topic of support.  Our primary opponent in network design and operation used to be complexity.  Building a network that was too complex likely meant you’d have issues down the road with supportability.  While this should still be a guiding principle, I’m going to argue that complexity is now our secondary opponent.  Our primary challenge in modern networking is change.  As networking systems become more open, your skill set as a network engineer will need to change with it.  As more of the platforms move towards native Linux your skill set should plan on following right along with.  Matt Oswalt wrote a great post on this last year that you should check out if you haven’t.  He also talks about other skills that we should all be focusing on or looking to learn in the near future. 

I’m excited about what the next few years will bring to the network space.  The trend certainly seems to be going in the right direction and I’m hoping to see more and more vendors take this approach. 

What do you think?  Is your definition of open networking different?  The same?

« Older entries