file

Getting Started with Git: Creating a Git Repo

/ Christopher Paquin

NettutsFetch-1So first off let me start by saying that I know that there is a ton of information out there on how to get started with Git. Heck, when you create your repo in GitLab it spits these instructions right out in front of your nose. However, what I have found is that most instructions tell you what to do to get started with git, however they do not tell you exactly what you are doing. You end up running a few command and then sit back and try to figure out what you actually just did.

 

That being said, getting started with Git has been the hardest part of the process, as most of us traditional grey-beard sysadmins are not that familiar with code management. When I was first getting started in technology, there were developers and there were sysadmins, and those two worlds were extremely separate. Now, we as we enter the age of DEVOPS and automation these two worlds are once again colliding (like they did in the beginning, but more on that another day).

 

 In my lab I decided to build a stand alone vm for Git and Puppet. After doing some research – and asking others– on how and what to do to get Git up and running with a nice front end web interface, I decided to get started by installing the GitLab Omnibus package for Centos 6. This process was quick, easy, and painless.

 

Once I had a working webUI up and running it was time to create my first repo. Instead of trying to accomplish this from my Fedora workstaion, I just clicked on the "New Project" button on the GitLab dashboard and created an empty repo called "General_Scripts".

 

Back on my Fedora workstation I created a new directory in my home dir called git, and inside that directory I created a directory called "General_Scripts" as I had done in the webUI.

 

Now it was time to use Git.

 

First off you need to configure a few global Git options. This only needs to be done once.

#git config –global user.name "Fatmin"

#git config –global user.email "fatmin@fatmin.com"

 

Once these global configs are set you can then you can move on to seeding your repo. Here you see my change directories to the Global_Scripts directory and tell Git to initialize this directory as a repo.

#cd Global_Scripts

#git init

 

Now lets create a file and add it to the repo. Here were are going to create a simple README containing a description of my new repo. The instructions do not tell you that you have to put anything in this initial file, however what good is an empty README anyway

#vi README.md

 

Now tell git that this file needs to be added to the "General_Scripts" repo that we created a few steps ago.

#git add README.md

 

Now lets commit that file with a nice little comment. Commit comments should describe what the file we added or what we changed in an existing file

#git commit -m "Added README.md"

 

Now we need to tell our local git command what remote repo we are going to sync to. Note my git repo url is puppet.lab.localdomain, fatmin is my user's namespace, and General_Scripts is my repo.

#git remote add origin git@puppet.lab.localdomain:/fatmin/General_Scripts.git

 

Now we need to actually push the local files to the remote repo (origin) in the master branch.

#git push -u origin master

 

Now wait a bit and go check out the webUI. You should now see the README.md file in your new remote repo.

Related articles

Super Quick Git Guide
Bashit… Just a Custom Bash Prompt Setup for Git
Git and GitHub LiveLessons

SELinux – Invalid Regex in /etc/selinux/targeted/contexts/files/file_context

/ Christopher Paquin / Leave a comment

EnikSo I have been doing my best to better understand SELinux as of late, and last night when I was practicing I ran into an issue that had me banging my head against by desk.

Specifically I was playing around with the semanage command and working on defining a particular context to a directory that I had just created. However I was not exactly quite sure of the exact regex to use (or even if I needed to use a regex)

The specific command that I ran was…

#semanage fcontext -a -t httpd_sys_content_t /var/www2

Now my concern was that this was not the correct command for me to run since www2 was a directory and I wanted to make sure that appropriate SELinux contexts were applied recursively as new files/directories were created. So I ran the following command that I found in my RHEL book.

#semanage fcontext -a -t httpd_sys_content_t ‘/var/www2/html(*,/)’

which spits out this….

/etc/selinux/targeted/contexts/files/file_contexts.local:  line 13 has invalid regex /var/www2/html(*,/):  Invalid preceding regular expression

Oops, wait I entered the command wrong. Its a period and the end not a comma, so I run the command again with a period this time and get the following error.

# semanage fcontext -a -t httpd_sys_content_t ‘/var/www2/html(*./)’
/etc/selinux/targeted/contexts/files/file_contexts.local:  line 13 has invalid regex /var/www2/html(*,/):  Invalid preceding regular expression
/etc/selinux/targeted/contexts/files/file_contexts.local:  line 14 has invalid regex /var/www2/html(*./):  Invalid preceding regular expression

Well crap, its still not correct. So I enter this command and get another error.

#semanage fcontext -a -t httpd_sys_content_t “/var/www2/html(/.*)?“

So at this point I start running all sorts of variations of the command with minor syntax changes each time, each time getting an error and each time getting more and more frustrated thinking that I am still not running the command correctly.

However this is not actually the case.

After I take a step back and cool off I actually take the time to read the error message which is pointing me t the file, file_contexts.local. Which upon further inspection actually contains each and every regex that I just ran regardless of the fact that the regex was correct.

# cat /etc/selinux/targeted/contexts/files/file_contexts.local | grep www2
/var/www2    system_u:object_r:httpd_sys_content_t:s0
/var/www2/html(/,*)?    system_u:object_r:httpd_sys_content_t:s0
/var/www2/html(/,*)    system_u:object_r:httpd_sys_content_t:s0
/var/www2/html    system_u:object_r:httpd_sys_content_t:s0
/var/www2(/.*)?    system_u:object_r:httpd_sys_content_t:s0
/var/www2/html(*,/)    system_u:object_r:httpd_sys_content_t:s0
/var/www2/html(*./)    system_u:object_r:httpd_sys_content_t:s0
/var/www2/html(/.*)?    system_u:object_r:httpd_sys_content_t:s0

In a nutshell.. the semanage command added each and context to file/directory mapping despite the fact that my regex was not correct, and then it gave me an error. So each time I ran the command with the an invalid regex, another entry was added and the error message grew. One would think that it would detect the regex error first and not add it to the file.

Anwyway the fix was to identify all the bad lines in the file from the error message and run the following command against each entry.

#semanage fcontext -d “/var/www2/html(*,/)?”

Once I cleaned out the file of the offending entries I was able to run the command one last time, this time using the correct syntax and was error free

RHEL6 – Using ACLs to Grant and Restrict FIle Access.

/ Christopher Paquin / Leave a comment

RangerRick

Access Control Lists or ACLs provide more controll over file permissions than standard linux file permissions (UGO — user, group, other). For example lets say that you want all members of the group "students" to have the ability to read a file, however you want to allow one user in that group the ability to write to the file, well ACLs can help you do this.

First thing that you need to know is that you cannot just start using ACLs right away, first you have to make sure that your filesystem is mounted so that ACLs are availible. This means adding ACL to the mount options in /etc/fstab.

UUID=3fa4603e-9874-4f47-ae1c-3f7715a54238 /                       ext4    defaults,user_xattr

So in my fstab, I change the line above to the line below. I know, exciting right?

UUID=3fa4603e-9874-4f47-ae1c-3f7715a54238 /                       ext4    defaults,user_xattr.acl

Now to view the permissions and ACLs on a file use the getfacl command, below i am checking the file RangerRick.jpg in /root/Pictures.  In the example below there are no ACLs assigned, btw.

[root@fedora15 Pictures]# getfacl RangerRick.jpg
# file: RangerRick.jpg
# owner: root
# group: root
user::rw-
group::r–
other::r–

So lets allow the user "chris" to write to the file, just just read it.

[root@fedora15 Pictures] setfacl -m u:chris:w RangerRick.jpg

Now run getfacl again and check out the difference

[root@fedora15 Pictures]# getfacl RangerRick.jpg
# file: RangerRick.jpg
# owner: root
# group: root
user::rw-
user:chris:-w-
group::r–
mask::rw-
other::r–

Additonal Examples:

Lets give all users in the group "students" the ability to write to the file, since they may want to modify it and add a photochop their faces over the dear old racoon's face.

[root@fedora15 Pictures] setfactl -m g:students:w RangerRick.jpg

But oh no, user "bert" in the group "students", has decided to modify the file RangerRick.jpg in an in appropriate way, so lets remove his permissions altogether.

[root@fedora15 Pictures] setfacl -x u:bert

Lets say that we want to allow the user "chris" to be able to modify all existing and newly created files in the Pictures directory where the Ranger Rick picture lives.

[root@fedora15 Pictures] setfacl -m d:u:chris:rw /root/Pictures

Note that when a file has ACLs assigned to it, a plus "+" sign will appear in the output of an 'ls-l'

-rw-rw-r–+ 1 root root 148011 Oct 12 15:06 RangerRick.jpg

Honestly you will probably never need to use ACLs, but they are handy to have availible if you run into some sort of situation where you need to grant very particular permissions to files and directories.