As a System Engineer, I do occasionally have to do real field work. When that happens, having access to a TFTP and FTP server is sometimes required. Although the [lack of] UI makes the use counterintuitive, these tools are available in OSX. This post includes the commands required to enable, confirm, and disable both TFTP and FTP in the native Mac environment.
//load the TFTP daemon (typically starts automatically) sudo launchctl load -F /System/Library/LaunchDaemons/tftp.plist //confirm that TFTP is listening (netstat) netstat -atp UDP | grep tftp --output-- udp6 0 0 *.tftp *.* //IPv6 Listening udp4 0 0 *.tftp *.* //IPv4 Listening //unload the TFTP daemon sudo launchctl unload -F /System/Library/LaunchDaemons/tftp.plist //confirm that TFTP is no longer listening (netstat) netstat -atp UDP | grep tftp --no output--
//load the FTP daemon (typically starts automatically) sudo launchctl load -w /System/Library/LaunchDaemons/ftp.plist //confirm that FTP is listening (netstat) netstat Continue reading
I recently set up a free Amazon AWS server. As I experimented with it, I installed a GUI desktop. Then I encountered some issues that I eventually resolved by creating a new user with its own password and then using that user for the rest of my activities.
For my own reference, and in the hope others will find it useful, here is the procedure I followed:
I posted the details in my blog post, below.
The default ubuntu userid does not have a password. The Amazon AWS documentation on managing users recommends creating new users with password disabled. So, why set up a new user with a password?
After installing a GUI desktop, you need to a use a password to authenticate operations performed by GUI software such as Ubuntu Software Center. I did not see any problems caused by configuring a user password. I found it was best to work in a “normal” Linux user account that has a password.
FCIP is notably a part of the CCIE Data Center lab exam blueprint. It is also a sticking point for a lot of candidates who have not done a whole lot on the storage networking side. Luckily FCIP has many correlations to the modern-day Ethernet networking that we all know and love, as it’s really just another tunneling technology! After some thought, I have decided to break this down into 2 blog posts. This one will cover FCIP basics, and another that will cover some more advanced FCIP options that you might have to use during the CCIE lab examination.
FCIP is used for extending a Fibre Channel (FC) network over an IP backbone. It encapsulates FC in IP so that SCSI and non-SCSI FC frames can be sent over an IP network. Normally most organizations are not going to do this simply for the sake of extending their FC network (why extend a lossless network over a lossy medium?), but rather for backup or replication jobs that need to occur between storage systems that are across some geographical distance. A typical deployment scenario is shown below:
Here we have two SANs separated by an IP network. Now, the Continue reading
We all know that “Change is Hard.” But often we, as engineers, focus on the technical aspects of that change. How do I minimise customer impact while upgrading those routers? How can I migrate customer data safely to the new system? But we can forget about the wider implications of what we’re doing. If we do, we may struggle to get our changes implemented, or see poor take-up of new systems.
I was talking to an engineer who had planned a huge configuration management implementation. Everything had been manually configured in the past, but this was hitting scale issues. So he had worked for months on a fully automated process. It was going to be amazing. It would configure everything, across all systems and applications. Standards enforced, apps deployments done in a repeatable way, etc. It was going to be a thing of beauty. No-one would ever need to login to a server again. Total automation.
It was all tested, and was just waiting for approval to put it into production. But for some reason, no-one was willing to give the go-ahead to roll it out. Weeks were dragging by, and things were going Continue reading
SDN (Software Defined Networking) is finally becoming clearer. It is not “Still Don’t Know” nor is it a specific overlay controller. Simply put, it is an open and programmable way to build networks for customers looking at utilizing hybrid combinations of public and private cloud access.
We are witnessing a shift from multi-tier oversubscribed legacy enterprise networks to two-tier leaf-spine or single-tier Spline™ cloud networks with east- west traffic patterns scaling across thousands of servers. Arista was the first to introduce this new architectural “leaf-spine” approach for cloud-based networks and five years later others are still attempting to mimic. Lets review some practical examples.
Facebook: Take an important and familiar social networking application, Facebook. Their public information shows that they deploy a memcache architecture, which allowed them to reduce the user access time to half a millisecond by using fewer network tiers, resulting in lower application latency. As we log into Facebook, the single login request triggers thousands of look-ups on databases and memcache servers. Legacy enterprise multi-tiered networks would result in delayed look-ups and would negatively impact the user experience and interest in a significant way.
Amazon: Shopping couldn’t be easier than online on your favorite site. Have you Continue reading
“Thou Shalt Have No Chokepoints” is one of those simple scalability rules that are pretty hard to implement in real-life products. In the Distributed Data Plane part of Scaling Overlay Networks webinar I listed data plane components that can be easily distributed (layer-2 and layer-3 switching), some that are harder to implement but still doable (firewalling) and a few that are close to mission-impossible (NAT and load balancing).