I'm in the process of working out a few kinks of setting up Ubuntu services for a small business network. We have successfully used a web server running mediawiki, and some basic NFS services so far. A special type of network share that I need provided by my file server is one in which users are free to read and write each others' files. I'm not sure if NFS is best suited to the task, or if this is something that's more suited to Samba.
The default umask set in /etc/profile of an Ubuntu workstation is 022. This lets users read and write their own files, and allow other users in any group to read their files. This is perfectly fine in most situations; however, we need a shared workspace where users can edit each others' files. I could set the umask to 002, or even 000, but I doubt that's a good practice. This means that on each local system, other users could edit files in each others' home directories. Actually, I'm not even sure if this is true, if the proper permissions are set on users' top-level home directories, but files under those directories would have too-loose permissions set on them.
In general, I want to keep the default umask of 022, but I want a specific share (whether it's NFS, Samba, or something else entirely) to behave like umask 000. I know I could do this in Samba, but my instincts tell me that there is probably a better way.
Could you please share how you provide this service on your networks? What are some good practices to follow? Are there any risks to providing this type of service that aren't immediately apparent?
Friday, August 27, 2010
Monday, August 16, 2010
NFS On Lucid Lynx
Ubuntu Docs: Setting Up NFS
The above Ubuntu guide is pretty thorough. The following is a summary of the parts that were relative to me.
Firstly, servers must install the package nfs-kernel-server and clients must install nfs-client.
Some best practices to follow are to export nfs shares from /export, and shares in here are mounted bound to other file systems, like so:
The above Ubuntu guide is pretty thorough. The following is a summary of the parts that were relative to me.
Firstly, servers must install the package nfs-kernel-server and clients must install nfs-client.
Some best practices to follow are to export nfs shares from /export, and shares in here are mounted bound to other file systems, like so:
# mount --bind /home/users /export/usersor, in fstab:
/media/maxtor/apt-mirror /export/apt-mirror none bind 0 0Also, a line has to be added to /etc/exports corresponding to the export path, like so:
/export/apt-mirror 10.1.10.0/24(rw,nohide,insecure,no_subtree_check,async)Restart the nfs service, and the server is all set up. To set up the client, add a line to /etc/fstab like so:
10.1.10.94:/export/apt-mirror /var/spool/apt-mirror/mirror nfs rw 0 0
Thursday, July 29, 2010
Learning RT from scratch
RT is a self-proclaimed hairy beast. The documentation doesn't provide a concise introduction to the concepts, so here is my attempt at providing the most concise, but all-encompassing description of RT. It's pretty directly ripped from the RT wiki, with some fluff cut out.
The wiki home page
it's big, and learning how to set it up can take some time.
please plan to spend some quality time with the UserManual before you try to go live; RT is big and hairy, and you probably can't get your head around all of it in one sitting.
manual introduction
A Ticket is the central object in RT, the thing that needs to get done. Tickets have metadata attached to them such as an owner, status, and queue - we'll get to all that in a minute.
A Queue is the central administrative domain of RT; it keeps things organized. As the name implies, it's a line of tickets waiting to be worked on, but it's also, to some extent, the ticket's category. For instance, you might have the right to create, delete, and comment on tickets in the Foo queue, but only the right to comment on tickets in the Bar queue.
A ticket's history is what it sounds like: everything that's happened to a ticket. Facets of ticket history could include when the ticket was created, how it has changed, and any comments about it or replies to it. Like real history, ticket history cannot be changed (at least not without messing up the space-time continuum), so be aware that any comments you make about a ticket are permanent.
Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff not visible to the requestor. This is useful when you want to be tactful but still convey important information, like, "This requestor is an investor, so be nice" or "This user's request mentioned his 'PC' but he really has a Mac."
Priority, how important a ticket is, is represented as numerical scale from 0-99, with 99 being the highest priority. ManualAdministration contains a useful model for setting organizational policy for priority.
The status drop-down menu offers several choices for classifying each ticket. Here's what they mean:
Scrips are custom notifications that will automatically take Action X in response to Condition Y. You could have RT notify the Requestor when a ticket is resolved, for instance, or have RT page you when your boss submits a request. RT comes with many standard scrips, and you can define your own. For details, see the Scrips section in ManualAdministration. And no, we didn't misspell "scripts." We made up a new word. Try it, it's fun.
The wiki home page
it's big, and learning how to set it up can take some time.
please plan to spend some quality time with the UserManual before you try to go live; RT is big and hairy, and you probably can't get your head around all of it in one sitting.
manual introduction
A Ticket is the central object in RT, the thing that needs to get done. Tickets have metadata attached to them such as an owner, status, and queue - we'll get to all that in a minute.
A Queue is the central administrative domain of RT; it keeps things organized. As the name implies, it's a line of tickets waiting to be worked on, but it's also, to some extent, the ticket's category. For instance, you might have the right to create, delete, and comment on tickets in the Foo queue, but only the right to comment on tickets in the Bar queue.
A ticket's history is what it sounds like: everything that's happened to a ticket. Facets of ticket history could include when the ticket was created, how it has changed, and any comments about it or replies to it. Like real history, ticket history cannot be changed (at least not without messing up the space-time continuum), so be aware that any comments you make about a ticket are permanent.
Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff not visible to the requestor. This is useful when you want to be tactful but still convey important information, like, "This requestor is an investor, so be nice" or "This user's request mentioned his 'PC' but he really has a Mac."
Priority, how important a ticket is, is represented as numerical scale from 0-99, with 99 being the highest priority. ManualAdministration contains a useful model for setting organizational policy for priority.
The status drop-down menu offers several choices for classifying each ticket. Here's what they mean:
- NEW: the ticket has just been created and hasn't been touched yet.
- OPEN: the ticket is getting worked on
- STALLED: due to circumstances beyond your control (waiting for the requestor to respond, waiting for the owner to return from Sri Lanka), the ticket isn't getting worked on right now. It will open again when someone adds a comment or reply.
- RESOLVED: hooray! Work on the ticket has been completed and is out of everyone's hair.
- REJECTED: the ticket is not the staff's problem and is not going to be resolved, but is, for some reason, worth recording in the system. For instance, if an employee asks approval for something ridiculous, you can reject the ticket, but it will stay in the database as evidence that the employee makes silly requests.
- DELETED: the ticket never should have been in the system (maybe it was spam, a list of passwords, etc) -- and is now being zapped for good.
- OWNER: the person responsible for the ticket and its resolution. Each ticket can have only one owner. As a ticket it worked on, it may be passed from one owner to another.
- REQUESTOR: the person or people who asked for something to get done; the ticket's reason for being. The Requestor normally gets copies of all replies to the ticket, but no comments.
- CC: someone (or someones) who should get copies of any replies that go to the requestor. This might be the requestor's boss, sales rep, etc. This person will see the emails but doesn't necessarily have the right to work on the ticket.
- ADMINCC: a Cc or Ccs that also gets copies of comments and generally are allowed to work on the ticket.
- DEPENDS ON: the ticket can't be resolved unless another ticket is also resolved. The converse is depended on by.
- REFERS TO: the ticket doesn't need the other ticket, but it would sure be useful for you to look at it. The converse is referred to by.
- PARENT: a big, general ticket ("Move house.")
- CHILD: a subproject of a parent ("Hire movers." "Pack." "Eat pizza.")
Scrips are custom notifications that will automatically take Action X in response to Condition Y. You could have RT notify the Requestor when a ticket is resolved, for instance, or have RT page you when your boss submits a request. RT comes with many standard scrips, and you can define your own. For details, see the Scrips section in ManualAdministration. And no, we didn't misspell "scripts." We made up a new word. Try it, it's fun.
Tuesday, June 15, 2010
Book review: Beginning Ubuntu Linux, Fourth Edition
This is a book review of Beginning Ubuntu Linux: From Novice to Professional, Fourth Edition. The print ISBN is 978-1-4302-1999-6 and the web ISBN is 1-4302-1999-8.
I read the contents of this book almost cover to cover; I only skipped the multimedia section. I read this because I was interested in reading Automating Linux and Unix System Administration, which apparently is last in a sequence that starts with this book, Beginning Ubuntu Linux.
In short, Beginning Ubuntu is an above average introduction to the world of Linux. Anybody who's a windows power user can probably poke around and figure out most things on there own, but parts 4 and 7, The Shell and Beyond and Keeping Your System Running, should be mandatory reading for new Linux users. Part 3, The No Nonsense Starting Guide has some parts which only apply in specific situation, but it's worth reading once.
Part 4, The Shell and Beyond, is a concise and clear introduction to the BASH shell, the Filesystem Hierarchy Standard, and in general, the UNIX way of doing things.
It's not the kind of book I would want to keep around as a reference, at least not for very long. It's not thorough enough on any one subject to make it a good reference. The tone is easy and almost conversational. If you are savvy enough to keep a Windows installation running virus free, and perhaps if you feel comfortable re-installing windows from scratch, then you could probably digest this book pretty easily.
There are two things I think are missing from this book. One is a procedure for surviving a major upgrade. Every ubuntu user is going to do this sooner or later. A novice could use some advice interpreting the various dialogs that will pop up during a distribution upgrade.
The second missing piece is a guide about compiling programs from source. Even if it didn't get a full chapter, novices deserve an overview of how programs are built.
I read the contents of this book almost cover to cover; I only skipped the multimedia section. I read this because I was interested in reading Automating Linux and Unix System Administration, which apparently is last in a sequence that starts with this book, Beginning Ubuntu Linux.
In short, Beginning Ubuntu is an above average introduction to the world of Linux. Anybody who's a windows power user can probably poke around and figure out most things on there own, but parts 4 and 7, The Shell and Beyond and Keeping Your System Running, should be mandatory reading for new Linux users. Part 3, The No Nonsense Starting Guide has some parts which only apply in specific situation, but it's worth reading once.
Part 4, The Shell and Beyond, is a concise and clear introduction to the BASH shell, the Filesystem Hierarchy Standard, and in general, the UNIX way of doing things.
It's not the kind of book I would want to keep around as a reference, at least not for very long. It's not thorough enough on any one subject to make it a good reference. The tone is easy and almost conversational. If you are savvy enough to keep a Windows installation running virus free, and perhaps if you feel comfortable re-installing windows from scratch, then you could probably digest this book pretty easily.
There are two things I think are missing from this book. One is a procedure for surviving a major upgrade. Every ubuntu user is going to do this sooner or later. A novice could use some advice interpreting the various dialogs that will pop up during a distribution upgrade.
The second missing piece is a guide about compiling programs from source. Even if it didn't get a full chapter, novices deserve an overview of how programs are built.
Monday, June 7, 2010
Sneakernet Ubuntu Server Updates
After initially deploying an ubuntu server high side of an air gap (wikipedia), there will come a time when packages need to be added and/or updated. This article attempts to outline a process to build and keep up-to-date a private local repository.
In short, I will configure the packages on an internet-facing staging server, and copy the downloaded packages to the private server. The packages themselves contain enough data to build the private repository. I've adapted the procedure from Odzangba's How To. The main requirement for this to work is that you have access to a staging server on the low side, which will maintain an identical package configuration. This requirement wasn't bad for me, because a staging server is useful for a million other reasons. I run it in a virtual machine on my internet-facing development workstation. Either the low and high servers have to start in an identical configuration, or you have to be assured that /var/cache/apt/archives hasn't been cleared since they may have diverged. For the following procedure we'll assume the two servers are identical. You also need some medium of transferring data between the two hosts. This is where the term "sneakernet" originated. I'm lucky that I don't have to run floppies between two server rooms; thanks to the wonders of modern technology, all i have to do is shift a thumb drive from one USB hub to another. If you are going to be doing this frequently, I would suggest making the sneakernet step as quick and easy as possible.
Lastly, you will also need to get build-essentials. It is required to have this on the private server before you get started.
Just so there is no ambiguity, I'll refer to the private host as high and the internet-facing host as low. lowadmin is the user on the low side, and highadmin is the user on the high side. /home/highadmin/localrepo is the path to the repository on the high side, and this must be added to /etc/apt/sources.list. The only line the the sources.list file on my high server is
In short, I will configure the packages on an internet-facing staging server, and copy the downloaded packages to the private server. The packages themselves contain enough data to build the private repository. I've adapted the procedure from Odzangba's How To. The main requirement for this to work is that you have access to a staging server on the low side, which will maintain an identical package configuration. This requirement wasn't bad for me, because a staging server is useful for a million other reasons. I run it in a virtual machine on my internet-facing development workstation. Either the low and high servers have to start in an identical configuration, or you have to be assured that /var/cache/apt/archives hasn't been cleared since they may have diverged. For the following procedure we'll assume the two servers are identical. You also need some medium of transferring data between the two hosts. This is where the term "sneakernet" originated. I'm lucky that I don't have to run floppies between two server rooms; thanks to the wonders of modern technology, all i have to do is shift a thumb drive from one USB hub to another. If you are going to be doing this frequently, I would suggest making the sneakernet step as quick and easy as possible.
Lastly, you will also need to get build-essentials. It is required to have this on the private server before you get started.
Just so there is no ambiguity, I'll refer to the private host as high and the internet-facing host as low. lowadmin is the user on the low side, and highadmin is the user on the high side. /home/highadmin/localrepo is the path to the repository on the high side, and this must be added to /etc/apt/sources.list. The only line the the sources.list file on my high server is
deb file:/home/highadmin/localrepo/ /OK! So, assuming low and high have matching package configurations, this is how to add and/or update packages to the low side and sync those changes to the high side.
- The low and high servers are identical. I want to add and/or update packages, so I'll execute the following commands on the low host...
sudo apt-get update
sudo apt-get upgrade
and maybe...
sudo apt-get install foobar spam
- Again, on the low host...
rsync /var/cache/apt/archives/*.deb /media/thumbdrive
I also like to add -vh (verbose, human-readable). Maybe rsync isn't necessary here, but I'm just in the habit of using it all the time. Also, my thumbdrive isn't usually passed directly to the virtual staging server, so my command looks more like this...
rsync -vh /var/cache/apt/archives/*.deb lowadmin@devbox:/media/thumbdrive
- Sneakernet step. I move the thumbdrive two inches into another hub, and mount it on the high side server, then...
rsync -vh /media/thumbdrive/*.deb /home/highadmin/localrepo/
sudo dpkg-scanpackages /home/highadmin/localrepo/ /dev/null | gzip -9c > Packages.gz
sudo apt-get update
sudo apt-get upgrade
This is where the magic happens. The second command uses dpkg-scanpackges to create the crucial Packages file. For further reference, see the man page.
That's it; the high side is now up-to-date.
Saturday, March 27, 2010
Ubuntu, vim and python
Until now, I had never used vi or vim as anything more than an emergency configuration file editor. The following two posts helped me leverage some of the more advanced features and plugins of vim to make it a nice python, fully-featured python editor. All credit goes to the following two posts. Most of the content below is copy-pasted directly from them. It's not my intention to plagiarize; this is just a spot for me to take notes, so that I could repeat the vim configuration process as painlessly as possible.
http://dancingpenguinsoflight.com/2009/02/python-and-vim-make-your-own-ide/
http://henry.precheur.org/2008/4/18/Indenting_Python_with_VIM.html
Create the directory ~/.vim/ftplugin; create a file named ~/.vim/ftplugin/python.vim containing:
setlocal tabstop=4
setlocal softtabstop=4
setlocal shiftwidth=4
setlocal textwidth=80
setlocal smarttab
setlocal expandtab
To get this working, simply add:
syntax on
set number
filetype plugin indent on
to your ~/.vimrc file
Additionally, you need to download the latest version of this script, placing it in ~/.vim/indent/python.vim. This will make indentation much less of a chore, and more of a pleasure. Be sure to also check out this blog post, wherein Henry Prêcheur explains how to improve indentation for comments as well.
To improve the formatting and display of improper indentation, as well as special highlighting for things like string formatting, download the latest version of this script, and place it in ~/.vim/syntax/python.vim.
http://dancingpenguinsoflight.com/2009/02/python-and-vim-make-your-own-ide/
http://henry.precheur.org/2008/4/18/Indenting_Python_with_VIM.html
Create the directory ~/.vim/ftplugin; create a file named ~/.vim/ftplugin/python.vim containing:
setlocal tabstop=4
setlocal softtabstop=4
setlocal shiftwidth=4
setlocal textwidth=80
setlocal smarttab
setlocal expandtab
To get this working, simply add:
syntax on
set number
filetype plugin indent on
to your ~/.vimrc file
Additionally, you need to download the latest version of this script, placing it in ~/.vim/indent/python.vim. This will make indentation much less of a chore, and more of a pleasure. Be sure to also check out this blog post, wherein Henry Prêcheur explains how to improve indentation for comments as well.
To improve the formatting and display of improper indentation, as well as special highlighting for things like string formatting, download the latest version of this script, and place it in ~/.vim/syntax/python.vim.
Sunday, December 13, 2009
Philosophy of Managing Programmers
http://it.toolbox.com/blogs/irm-blog/theory-p-the-philosophy-of-managing-programmers-4993
This article gave me some insight in to my own behavior.
Some of the commenters on his site have pointed out that he portrays programmers in a negative light; I disagree and think that this article contains advice that would effectively help protect a business from making the wrong decision about projects.
It also contains advice for programmers explaining how to avoid making some bad business mistakes.
This article gave me some insight in to my own behavior.
Some of the commenters on his site have pointed out that he portrays programmers in a negative light; I disagree and think that this article contains advice that would effectively help protect a business from making the wrong decision about projects.
It also contains advice for programmers explaining how to avoid making some bad business mistakes.
Subscribe to:
Posts (Atom)
