Tag: linux

5 Linux network commands that are similar or the same as in the Windows shell – Part 1

Let us take a look at the most common network commandline utilities which exist both in Linux and in Windows. We can see that the names for the commands almost all the same. It makes sense as these tools are really part of the daily toolset any IT engineer will use, whether you are working in Linux or Windows.

traceroute (tracert in Windows)

The handy tracert that is familiar from Windows-environments has its equivalent in traceroute. You should be aware of the extra protocols that you can use for tracing routes with traceroute. Furthermore, in traceroute you can use TCP SYN or ICMP ECHO for probes. You can also select a custom port to use.

ping (ping in Windows)

Check the availability of a node with ping in both Linux and Windows. This might very well be one of the simplest tools when checking if a network endpoint is available.

netstat (netstat in Windows)

Use netstat to check all the network connections. Moreover, you can check both listening and established ports on the local node. netstatcan be used with a range of options in both Linux and Windows. For instance, you have the option to check routing tables for OSI layer 2 information and multicast memberships. Additionally it can be argued that the Linux command ss to investigate sockets almost has replaced netstat. But for the purpose of daily network tasks, netstat is still very useful in Linux distributions.

nslookup (nslookup in Windows)

Use nslookup to query Internet name servers in both Linux and Windows. Although dig was favoured over nslookup for some time, nslookup is still a very important tool in the toolchest. It is worth mentioning that dig has more options. Consequently it is great for wrapping the command in Bash scripts.

curl (curl in Windows)

curl or Client URL has been around since 1998 and was the successor to HttpGet. This is a robust tool to transfer data over networks, with its support for a number of protocols (HTTP, HTTPS, FTP, FTPS, SCP, SFTP, TFTP, DICT, TELNET, LDAP).

This completes this part one of our round-up of five common Linux network commands with their Windows equivalents. In the next part of this blog post series, we will automate these commands in Linux with Bash scripts.

Author: Paul-Christian Markovski, for NailLinuxExam.com.

What’s the scoop on DevOps and database administration?

Data and databases are at the heart of any business endeavour to work with DevOps, development and operations working closer to one another and embracing automation. Data equal business value and it has to be safeguarded against corruption as well as data loss.

When DBMaestro reached out to 244 IT professionals they learned plenty about the way of working with databases in DevOps oriented workplaces. The top three risks reported for when deploying database changes were: Downtime, Performance impact, and Database / application crash.

But this then leads us to the question: What are the top three reasons for errors when making database changes? Well, based on the survey responses it turns out that accidental overrides, invalid code and conflicts between different teams are the three major sources of errors.

Speaking with CTO and co-founder Yaniv Yehuda from DBMaestro, we get some more insight into how these errors occur.

“Overrides of database objects – such as procedures or functions etc, when multiple people are accessing and introducing changes at the same time, on a shared database. For example – a developer starts to fix a bug in a database package, while the DBA adds another piece of code to that package. The last one to introduce the change, will override the previous one.

This was a challenge for code development decades ago, and was solved by introducing a check out/in process, and revision management. The problem still persists for shared database development.” When it comes to recovery times, most errors are fixed within one hour (51%), closely followed by errors that are handled in 1-5 hours.

DBAs are still mostly in control, but the balance is shifting!

Also, DBAs are still ruling their databases and 59% report that database changes are made by the DBA, versus 20% reporting that the DevOps can do the same. This does of course not mean that you as a Linux engineer should refrain from learning about database maintenance. Especially so since DBAs may be the bottleneck in critical business workflows. I wonder whether DBAs turn out to be bottlenecks in rapid Kanban/SCRUM workflows and on this topic, Yaniv Yehuda from DB Maestro adds “The fact that the process is being done by a person – adds overhead to an automated process.”

He continues with a real life example: “In large enterprises, if a developer wants to change something in the DB, he submits a request ticket – and the DBA takes it forward. That process can take days (just because people are busy…). Whenever you get that process automated, and each developer can do what he is entitled to – he can push several changes a day, without waiting for anyone else.

DBA may be required to review changes, but that should but be at the stage that a developer is striving to be agile. Errors – they can rise from the manual nature of the process (forgot to do something before or after, connected to the wrong environment, run the wrong script etc etc)”

Automation still an ongoing effort

The survey also showed that database scripts are mostly used to make changes to databases (51%), followed by build/submit scripts using automation tools (34%). The survey was based on a group of 244 IT professionals from around the world, ranging from CTOs to DBAs.

/ P-C Markovski

So, Linux engineer, you found yourself in a DevOps “experiment”?

DevOps is a popular trend these days and many Linux engineers (and other engineers) find themselves caught up in the hype. As companies scramble to combine work efforts by Development and Operations teams, the cultural changes that are introduced are huge.

But if you hear the word “experiment” in the midst of the DevOps changes you see around you, first challenge the idea of the DevOps experiment. Let us help you as we look into what constitutes an “experiment”.

To begin, let’s see what Dictionary.com says about this word:

“A test, trial, or tentative procedure; an act or operation for the purpose of discovering something unknown or of testing a principle, supposition, etc.:

The verb goes on to describe the action to experiment: “To try or test, especially in order to discover or prove something”

Let’s not stop here! Let’s take a look at what BusinessDictionary.com says, to get a definition that is viable in a business environment:

“[An experiment is a] research method for testing different assumptions (hypotheses) by trial and error under conditions and controlled by the researcher.

So, it seems there is an assumption involved? Surely your business has presented their assumption? Also, the experiments undertaken are to check hypotheses by controlled trial and error, controlled by the researcher.

So ask yourself: Is the experiment in your outfit using controlled trial and error in order to discover or prove something? Has the experiment been described with clear premises and a conclusion that is to be tested?

If not, then.. If the DevOps experiment in your team does not meet the description of experiment above, then it is highly probably that the decision makers in your outfit has some homework to do. And furthermore that they are delegating the business research and decision-making to you as an engineer, developer or tester.

Is that okay with you? Please think about the implications of this. And ask yourself: Are you getting credit (and paid) for doing business research?

The takeaway here is: Whenever you are about to be involved in an “experiment” in a business setting, do ask for a definition of the word in the context of the business. Find out what the underlying reason is to undertake the “experiment”.

Some reasons for DevOps experiments with no clear assumption or hypothesis..

  • Companies try to squeeze many job roles into one individual. This is to save money.
  • SCRUM and agile principles are adopted by companies without doing case studies to see if they really need them.
  • The CI/CD market is constantly evolving, tied to DevOps in the immaturity and interpreted differently by different companies.

Hopefully this blog post helps you to analyse your own situation in the DevOps experiment you are currently in.