Thursday, June 23, 2011

Dialog from Kristinn Hrafnsson

Making my way towards the Griffith University, Queensland Conservation of Art on a very fine winter day has given me to opportunity, and many others, to partake in a public forum addressed by spokesman Kristinn Hrafnsson.

Dialog from the address, quoted and revised:

Snippet from leaked US-Army video -> Collateral Damage

Media partners: NY Times, Le Monde, El Pais, Aljazeera, Der Spiegel, SVT, 4, The Guardian

"...only about 50,000 cables are online."

"Often media companies are untrustworthy and individual journalists are consulted."

"Care is made not to make unnecessary harm to people."

"The cables have demystified other information."

"...that the cables will have a devastating effect on information connections between countries."

Zine El Abidine Ben Ali is the president of Tunisia whom is regarded as a valuable alli to certain parties in USA.

GITMO FILES (Guantanimo Bay Files) - an example of bad information being used to detain a number of people in conditions that do not fall under the Universal Declaration of Human Rights.

WikiLeaks has revolutionized journalism by partnering with media corps to better understand the importance of freedom of information.

"In a race between truth and secrecy, truth will always win." Kristinn says that he was impressed by these words, up until he discovered the creator of the saying, Rupert Murdoch.

WikiLeaks exists only due to the need for its' service - once Governments can become transient in relaying information to the public, WikiLeaks may not need to exist.

Saturday, June 11, 2011

Permissions for mounting Externals


When mounting Externals, often the default permission will be that of the user mounting the device. This can create a barrier when wanting to access the External over a network. So when mounting, it is good practice to give suitable permissions that meet your specific needs. Ubuntu Docs has a good page on permissions however, you probably just want a working example. So here you go.

For mount, the umask detemines the permissions and if you read the Ubuntu Docs page briefly, read, write and execute permissions are given by 4, 2 and 1 respectively. As you will see, 0000 will result in permissions = drwxrwxrwx. If you give umask = 0001, then the permissions = drwxrwxrw-. A simple concept, however, at first I thought that it was the other way around.

So here's how I would mount an External on my server for read/write access by guests/users in the specified group:
mount -t ntfs-3g -o uid=admin-user,gid=guest-user-group,umask=0000 /dev/sdc1 /media/OneTouch

And if I wanted to mount with permission for just the user who mounted it:
mount -t ntfs-3g -o uid=admin-user,gid=guest-user-group,umask=0027 /dev/sdc1 /media/OneTouch

Extra control can be given using uid and gid to determine who is the owner and which users of the group can access the External. This may take a little bit extra to tweak but can be a good security measure. To get started, use the following command to determine which group a users belongs to:
id username

For more information about mounting, there's a resource here.

Adios, till next time!

Tuesday, June 7, 2011

SwiFTP and LFTP to do some syncing

Well, I should be studying but instead I'm delving into some FTP stuff and how to do some syncing across particular folders. All this is due me wanting to make my Music listening a hell of a lot easier. At present, Winamp does not have a Linux version and this sucks because there is one feature of Winamp has just come out and is fricken awesome - Wireless Sync, pretty self explanatory.

So I need a work around.

On your Android device
At present, I'm running Gingerbread 2.3.3 on my SGS2. Download and install SwiFTP from the Android market - information here. I've found this app simple and easy to setup - thus far. Once it is fired up, put in the details that you wish to have for your FTP server (your device) - user, pass, port (anything in the 1000's usually works, but not always). Most importantly, where it says:
Stay within folder (e.g. /sdcard):
...just put a...
/
...in the box. Later on when you connect from your client, you can point LFTP to which ever folder you wish - hopefully. Some info about why you should do this here (search for 'root').

Now, I say this because there may be a SU (superuser) or root error (is you device rooted?) in which you will not be given access to the folder on your phone, even if you typed the password in correctly. There needs to be a work around for this because there are rumors that rooting your device can disallow it from using certain Provider apps, e.g. any Optus apps on my device. And frankly, once rooted, I'm not sure if factory defaults can be set.

Once this is done, save the settings and the FTP server will start automatically.

On your Linux box
With your FTP server running, open up terminal on your Linux box and type in the following:
lftp -u name -p 1234 ftp://192.168.x.xx:/
-u specifies the username
-p specifies the port which you setup earlier on the device

You should be prompted to enter a password which was the one you setup earlier. And if all goes well, you will have a line that looks like this:
lftp name@192.168.x.xx:/
And this verifies that you can make the connection. Now, if you type in 'ls', you should be given all the files and folders of that folder. Neat!

Syncing with rsync -> FAIL
Rsync is a program which appears to come pre-installed on Linux. It allows for syncing folders across FTP and on your machine. It seems to be much like creating a symlink but is only run when the user says so. There is a neat little thread here which says it all.

So...I've just finished trying to get rsync to work with my FTP server, but everywhere I go says that it cannot be done :(. Well at least I know about Rsync I guess. There is a solution however...read on.

LFTP and Mirror
So the solution, as posted here by easel (round of applause!), is to use 'mirror' to do the syncing over FTP using LFTP. So you'll want to make a script file with the code that easel has posted. I've changed mine a little for my needs:
lftp -c "set ftp:list-options -a;
open ftp://user:password@your.ftp.com:port; 
lcd ./web;
cd /web/public_html;
mirror --reverse --delete --use-cache --verbose --allow-chown --no-umask --parallel=2"
Some of the options used include:
lcd - is the local directory you want to sync,
cd - is the directory on the FTP server in which you wish to sync
and...
mirror - sync the two folders, choosing the local directory as the master (everything on cd that isn't in lcd will be deleted). Type 'man lftp' for more information on the options used here, --reverse, --delete etc.

Don't forget to change the permissions to user executable, chmod u+x.

Note: lftp uses ftp protocols to transfer data and is therefore, not secure (ssh is an example of a secure transfer protocol, need to investigate how I can use it instead). The password that was entered in earlier could easily be hacked (discovered) by anyone listening to the 'conversation' between your phone and your computer...so be careful!

Pretty neat huh! That's it. It may need to be run from the CLI, or you can create a launcher on the desktop. That should work.

Ciao and happy syncing!

Samba Server

My quick HowTo on how I setup Samba on my floor server. Methodology taken from here. Might also be useful, maybe even quicker, to look at Ubuntu Docs here.

1) Check samba and smbfs is installed
sudo apt-get install samba smbfs
It should be...

2) Edit the smb.conf file
Edit the file to your needs. Don't forget to make a copy of the original file somewhere just in case something goes terribly wrong.
sudo nano /etc/samba/smb.conf

2a) Tell Samba to allow only known accounts.
Find the following line...
#  security = user
Uncomment it and also add an extra line:
security = user
username map = /etc/samba/smbusers
Of course, you can tell Samba to point where ever you want it to, just don't forget where.

2b) Create Samba user account
Create an account that you will give access to Samba shares
sudo smbpasswd -a name
Add the user to smbuser file and link it to an account on the server
sudo nano /etc/samba/smbusers
Once the file is open, add the following line. The "name" will be linked to the name account:
name = “name”
Save and exit nano.

You have now setup a user for Samba. Now to finish it off - fatality style O_o.

3) Fine tune smb.conf

Now, if you read carefully, the smb.conf file will have a whole load of options. Some are straight forward, some are complex - in the sense that I don't know what would happen if I changed them. Everyone will have different preferences, but these should get you started:

Um...there's too many to list. See Ubuntu Docs, pretty useful.

But, to be helpful, if you want to get started quickly, just add this to the end of the smb.conf file, with your options of course.
[share]
    comment = Ubuntu File Server Share
    path = /srv/samba/share
    browsable = yes
    guest ok = no
    read only = no
    create mask = 0755

4) Restart services

I've also noticed that when doing this, there is some sort of lag in the service restart. So, you may need to wait a little longer before the changed settings will take effect.
sudo restart smbd
sudo restart nmbd

Conclusion
So I think that's it really. I've found that Samba just gives a UI for when accessing server files. It seems to be the same as using SSH and scp to move files to an fro. However, scp can be much faster if you know where you want to put something on the server and you have already set the right permissions. Which brings me to my next point: permissions. Are very important here. Permissions, users and groups. I almost gave myself a headache but I guess so long as you remember what users are in what groups, and which groups can do what. As a general rule, I've written it on stone-tablets in my mind that the user you create when you do a clean install, has admin/root permissions. Therefore, don't use that user name for this kind of stuff. So...if you are having troubles writing to shares once you have mounted them, then my advice is to look up some docs on permissions. Running this:
sudo chmod a+w directory
...may be all that is needed to allow you to do so.

Have just re-read this post and...it's longer than Ubuntu Docs :(. Oh well, enjoy!

Extra Places
http://us1.samba.org/samba/docs/man/manpages-3/smb.conf.5.html

How should a server be setup?

After recently acquiring a $75 tower, with reasonable specs, it has come to my attention that setting up a home server should have several steps that are a must. The last box died, in most part due to the age of the 15GB HDD. But Ubuntu was able to run and for a time, there was a nice little server running on it - 1 GHz, 256MB RAM (the 512 I put in wasn't detected...). After wiping the Windoze system and doing a clean install of Ubuntu 11.04 via network, I was able to get a LAMP installation running (but not utilising MySQL or PHP as these are both foreign to me), a Samba file sharing thingo, as well as installed and shared my Canon printer :).

Now, the guy I bought the $75 box from (3 GHz, 1GB RAM, 80GB HDD) suggested to use a USB stick to store important files. And while I do agree to some extent, I really just wanted to learn how to get a server going...hehehe. There may well be some extra benefits in the long run from having a file system that is accessible over the internet, however one does need to be weary of security issues and also the possibility that things might not do what you want them do - it's a learning process. With that in mind, I think Ubuntu Linux makes a very good distribution to get a server working.

Below, is a short list which is MY recommendations (and what I have done just recently) for what you should do/install after you have put an awesome distro of Linux on your box that has been sitting in the corner doing nothing for the last 4 years. My final message is as above: security is paramount. I'm not talking about physical security, although that may be important depending on which neighborhood you live in, but rather internet security. Call me paranoid, call me what you will, but there's no point setting up a server if other people are going to be able to get at it...unless you want them to of course.

Here's my list:
1) Configure sshd_config on the server so you can access it safely (in progress)
2) Setup printer
3) Move your web files to /var/www
4) Setup Samba

Here's my list - the detailed version
1) Configure sshd_config on the server so you can access it safely (in progress)
* Change the port in which SSH will listen. 22 is the default port so if you change it, unwanted guests will take longer to find your server.
* Disable root access. Allow only specific user/s, but never an account with root access.
* Setup SSH access via a public/private key. See Ubuntu Docs for more details and how to make one. Note: if after using this method and transferring the key to the server computer, you may find that the key fails to authenticate. This may be because you may not have added the ssh-server-address-thing (?) to your system. Run this command on the client computer (the computer in which you are accessing the server from), for some reason it is not mentioned in Ubuntu Docs:
ssh-add

2) Setup printer
* Make sure CUPS is up to date and all package dependencies have been met
* For my Canon PIXMA, see older posts
* If something isn't working, try turning the printer off and then on again, seems to do the trick

3) Move your web files to /var/www
* Maybe it's bad practise, but I've been getting into the habit of using /var/www as my LAMP root directory - it's the default directory anyway and I think it's safe
* If you wish to make directories that are accessible via internet, then you have to give the folder guest access. Just use chmod and chown to do this.
* I guess this is essentially how I set up my webserver. Not very flash bang and yes, update my website is one thing I need to do...

4) Setup Samba
* Only useful if you want to access your files over different OSes
* Or, if you don't like using SSH - which I kinda like...
* See next post for details

Things worth looking into:
* Logging break-in attempts: not sure how to do this but need an easier way than reading the /var/log/auth.log manually...