how to

Working with Git — How to Clone and Fork a Git Repository

/ Christopher Paquin / Leave a comment

git_squid_catSo as I have stated before, I am still very new to Git. I know just enough to do a few basic tasks, but nothing much more advanced than that.

Thankfully, the process of cloning a remote Git repository is actually rather simple once you know what you are doing. Forking a repo is just as easy. Again, once you know what you are doing. Below I am going to walk you through the steps in a very simple and easy to understand way.

Cloning a Remote Repository

First lets change to a directory that we want to use as a landing zone when we download — or more accurately — clone a remote repo.

#cd /root && mkdir git

Now using the remote git URL, lets clone the fatmin github master repo @ https://github.com/Fatmin/general.git. Note that the destination of general.git name of our remote repo.

#git clone https://github.com/Fatmin/general.git

This creates the directory “general” which contains all the downloaded files, scripts, and code that we have previously checked in to our github repo. This command also initializes our pwd as a Git repo… no need to run Git init.

Forking a Remote Repository

Now lets say that we want to make a fork of the fatmin master repo. For example, lets say that we are working on a new puppet module and want to be able to test it out and then push to a new branch that we have decided to call testing.

First we need to create a new local branch. We accomplish this with the command below. As stated above, our branch is called testing.

#git checkout -b testing

Now lets grab our puppet module, script, file, code, what have you, and move it into our pwd of /root/git.

Note that even though our file is now located inside our cloned and branched repo, we need to tell Git to add it to the repo with the command below. This command will add any new files or directories in our newly created local repository.

#git add .

Now we need to commit the changes in our local repo. Here we are adding a comment along with our commit. Then we are pushing our changes back up to the remote origin (https://github.com/Fatmin/general.git) into a new branch called testing.

#git commit -m “pushing scripts to testing branch” && git push origin testing

Once we are happy with our changes, or whatever, we can then log into github and approve the merge between our master branch and our testing branch.

How to Add and Delete Persistant Routes in AIX

/ Christopher Paquin

Chatter-phone-300x234Wow, AIX does not like to make anything easy. Nor do they like to make things intuitive. Need to remove a route from AIX, well get ready to have one command to temporariliy remove a route and another command to remove the route for good. Same goes with adding a route. "Quit your bitching, and use Smitty", you say? Well smitty does not make anything any easier, especially since the UI likes to show you fields that you does not necessarily need you to use. Oh, plus they let you type in them. Asking me for a netmask when adding a static route does not seem like a crazy request to me? But jokes on you, you were not supposed to type anything there.

Anyway, I was tasked with cleaning up a few bad routes that were added to a handful of servers. Note that I was not interested in adding the routes temporarily before I added them as persistent routes. These were simple one liners that I felt very comfortable adding to the ODM right out the gate.

So first we need to check the ODM for the routes that we need to remove. In this example we want to delete the route fro 10.11.1.56, so lets find just that route. Note all of these are host routes.

# lsattr -El inet0 | grep 10.11.1.56
route host,-hopcount,0,,-if,en1,,,,-static,10.11.1.56,10.22.13.1 Route True

 

Now lets delete the route above

# chdev -l inet0 -a delroute=10.11.1.56,10.22.13.1

 

We have a second route to delete so lets kill that one too

# chdev -l inet0 -a delroute=10.11.1.57,10.22.13.1

 

Now lets add the correct routes – the format is as shown below

chdev -l inet0 -a route=host,-hopcount,1,-netmask,netmask,network,gateway

 

Now on a few of the servers I was working on I had to remove network routes as well as host routes. You need to know that the syntax is anoyingly different adding network routes. In the example below I first need to remove the network route.

chdev -l inet0 -a delroute="net,-hopcount,0,,,,,,-static,10.11.1.56,10.11.1.254"

 

Now lets add our new and correct route

chdev -l inet0 -a route="host,-hopcount,0,,,,,,-static,10.11.1.56,172.30.150.190"

Related articles

Basic AIX Performance Troubleshooting Commands
How to Add Multiple Routes in Linux Using ip Command Examples
PowerPath, AIX 5.3, and LTG: Solutions

HomeLab: Basic Syslog Configuration on Cisco Catalyst Devices

/ Christopher Paquin / Leave a comment

FrontiervilleblueoxIn my homelab setup I am dumping syslog on all my devices to my Linux desktop. Have not figure out what I am going to do with it yet, but I see myself either setting up Splunk or Greylog in the near future. Note, a while back I wrote a post on how to configure rsyslog on RHEL 6 – s0 if you are interested you can find that post here.

So lets get down to brass tacks and configure some freaking syslog.

In this instance we are configuring syslog redirection on a Cisco 3548xl switch. Note we are in configure terminal mode.

First we must tell our device to insert timestamps on

s-3550-1(config)#service timestamps log datetime

Now we tell the device where to send the syslog messages

s-3550-1(config)#logging 192.168.0.195

Now we tell the device which log levels to send to the syslog server. In this instance I am sending warning level messages and above. This is pretty verbose, but its a home lab so I am not worried about a slew of log messages pounding my syslog server.

s-3550-1(config)#logging trap warning

For reference I am including the logging levels below.

Emergency: 0

Alert: 1

Critical: 2

Error: 3

Warning: 4

Notice: 5

Informational: 6

Debug: 7

Now lets review what we have done with the show logging command

s-3550-1#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
    Console logging: level debugging, 13 messages logged
    Monitor logging: level debugging, 0 messages logged
    Buffer logging: level debugging, 13 messages logged
    File logging: disabled
    Trap logging: level warnings, 13 message lines logged
        Logging to 192.168.0.195, 0 message lines logged

 

Note that this procedure is exactly the same on my Cisco 2621 switch.

 

Related articles

HomeLab: The Cisco 3560G
HomeLab: Simple SSH Setup on a Cisco Router
HomeLab: Cisco 3550 Switch Software Configuration Guide
Using Good Old Syslog When Troubleshooting (by Tony Fortunato)
HomeLab: Configuring the NTP Client on a Cisco Catalyst Switches
[PATCH 1/9] syslog_ns: add syslog_namespace and put/get_syslog_ns

HomeLab: The Cisco 3560G

/ Christopher Paquin / Leave a comment

WS-C3560G-24TSThe Cisco Catalyst 3506G is a layer 3 switch which went end-of-life in 2009. For the home lab its a pretty nice switch to have due to its layer 3 support and gigabit speed. Mine is the model seen to the left, 24 gigabit ports and 4x1gb SFP uplinks.

 

The Cisco Catalyst 3560 is available with one of two software images:

  • IP Base software includes advanced quality of service (QoS),
    rate limiting, access control lists (ACLs), Open Shortest Path First
    (OSPF) for routed access, and IPv6 functionality.
  • IP Services software provides a broader set of
    enterprise-class features, including advanced hardware-based IP Unicast
    and IP Multicast routing, as well as policy-based routing (PBR).

Anyway, gathered here are a few manadatory resources for the Cisco Catalyst 3560G.

Related articles

Vlan Configuration between Cisco & sonicwall help
Cisco WS C3560X 24T L 3560X Catalyst Switch

RHEL6 – RTFM Apache Web Server

/ Christopher Paquin / Leave a comment

King-James-BibleThere is a lot to know and remember about configuring Apache as you may or may not have seen from the numerous posts I have written on the subject, and the reality is that no one is going to be able to memorize each and every settings, configuration, and directive. Sure you can bing it or google it , you can even alta-vista it, but only if you have internet access at the time, however there is always a chance that you might get some bad information. So why not refer to the official httpd documentation. You know RTFM and what not.

By and large the best bet for HTTP documentation is the http-manual package that can be installed via yum. It installs to /var/www/manual

# yum -y install httpd-manual

Now one bit of information to note. The documentation installed via the httpd-manual package are in html format, so it not advised that you try to view it with an editor like vim or emacs.  You are going to need an text based web browser like lynx or elinks. I prefer lynx in this situtation, so lets install it.

# yum -y install lynx

Now you can peruse the documentation  as you see fit using lynx.

# lynx /var/www/manual/howto/auth.html

Below are some of the better and more often useful docs that I think that could be found useful in a crunch. Note our base directory is /var/www/manual

  • vhosts/named-based.html – which outlines configuring named-based virtual hosts
  • ssl/ssl_howto.html – which outlines has a nice section on HTTP Basic Authentication.
  • howto/cgi.html – which nicely documents creating a custom cgi directory
  • howt0/auth.html – more on HTTP Auth using htpasswd

Yup thats a lot of very good documentation right there, and its actually written by the people who wrote apache, not some 13 year old kid taking his first shot running apache on Ubuntu.

ProLiant System Management Homepage

/ Christopher Paquin / Leave a comment

Prod-shot-170x190 The HP Systems management homepage is a web based utility for managing and monitoring Proliant Servers. It can be installed via the ProLiant Support Pack DVD (on linux its just an rpm). Once installed you can modify the default settings via the perl script, hpSMHSetup.pl located in /usr/local/hp.

To access your server's homepage navigate to https://<yourhostname&gt;:2381 in your browser. You must include the https:// part of the url. Use your root user and password to access.

From the homepage you can monitor system, subsystems and status views of your server. Any critical, major, minor, or warning alerts will appear in the Overall Status Summary.