Tuesday, July 14, 2009

 

UbuntuOne

UbuntuOneLogo My number finally came up, I was able to register for new revolutionary file sharing service by Ubuntu Team called UbuntuOne. The service is still in closed-beta; see some reviews here, here and here.

(There isn’t much information (currently) on the official site, other than installation instructions, mailing list and bugs database)

This is a potentially brilliant idea, because it gives people a convenient way to support financially their favorite distribution, and with solid financial support this could become a reliable backup solution. Correct, there may be cheaper options available on the market, but you never know how long they’ll last (Streamload being a good example of that)

On the other hand, as of right now the service is hardly usable.

Mailing list appears to be relatively low-volume, and I am not sure many people are actually using this – which, given the modest, at best, progress of development and plenty of competitors, does not promise a bright future for this project any time soon, in my opinion.

But, whatever this is going to turn out, the idea was really a good one.

Labels: , , ,


# posted by Kostya @ 5:18 PM 0 comments

Sunday, May 31, 2009

 

Mounting windows shares

Procedures to mount Windows shares from remote machines changed so many times during lifespan of Linux, that an attempt to do a search in Google gives a mix of solutions from using "smbmount" to "mount -t smb".

Here is the latest and greates solution. Make sure you have "smbfs" package installed and do this : 

% sudo mount -t cifs //192.168.1.102/share_name /media/my_share -o \
  username=theuser,password=thepass,iocharset=utf8,file_mode=0777,dir_mode=0777

With option "iocharset=utf8" it ought to handle international characters in all Windows NT-based systems. If you need to mount drives from Windows 95/98/Me, different translation options will be necessary.

see this page for more detailed explanations.

Labels: , , , , ,


# posted by Kostya @ 3:32 PM 0 comments

Sunday, April 26, 2009

 

WebDAV, problems all around

It seems almost incomprehensible how many problems emerge with simple WebDAV file hosting. While apache DAV server, and clients built-in into both Windows Shell and GNOME have been available fr many years, I still can't make it to work properly.

Here is a brief list of problems:

Apache 2 Server. Its problem is that it is bit difficult to make server work with both "resular" and SSL modes. This typically emerges as failure to "copy", "move" or "rename" file in non-SSL mode, while everything else seems to work.

Good explanation is available here:

The main issue was that the production system runs on https and there was a reverse proxy setup for this system. So, all the "https" requests were converted to "http" at this proxy level and forwarded to the main system. This was the main culprit.

Here is an example of HTTP request for the MOVE resource request for a WebDAV resource. For brevity I removed all unnecessary details.

MOVE contentLocation //request line, some https location, URI of webDAV resource
Destination:destinationLocation // this is the HTTP request header, should be absolute URI according to specifications.

Overwrite: "F" // this is also a HTTP request header

So, when the reverse proxy sees the request line, it knows that it has to convert this to HTTP request but the header Destination also contains an HTTPS request which would be ignored by the proxy. So, when the request reached the server, we are moving the resource from an URI which begins with a http to a URI which begins with an https. Server treats this request as a request to move a WebDAV resource from one server location to another server location.(Refer RFC: http://greenbytes.de/tech/webdav/rfc2518.html#METHOD_MOVE). This was the source of the main problem.

Linux/GNOME GVFS driver: Seems to work most of the time,but

Windows (old driver). This is "old" Windows-2000 implementation, which identifies itself as "Microsoft Data Access Internet Publishing Provider DAV". This seems almost the most reliable implementation, and it worked for me for a while, but now it shows directory "Temp" as "temp" (all other directories similarly named are OK), and obviously fails to chdir to it. Reason unknown.

Windows (new driver, XP and newer). Identifies itself as  "Microsoft-WebDAV-MiniRedir/5.2.3790". Apparently only intended to work with Microsoft IIS, not compatible with Apache. This pages gives a consice overview:

For implementation of WebDAV on Windows XP and later , MSFT made it's own interpretation of the standard to work best with the Windows IIS servers. The problem due to this is three fold:

    1. Windows XP authenticates users using the format "domain\username" by the mechanism of "Microsoft-WebDAV-MiniRedir/5.1.2600". Whereas Windows 98SE/2000 authenticates users as "username" using the mechanism of "Microsoft Data Access Internet Publishing Provider DAV 1.1".
    2. The problem lies with the implementation of "Microsoft-WebDAV-MiniRedir/5.1.2600". If authentication is sent as "domain\username" then it would be received as "usernamedomain" or "usernamehostname" by the Web server and not as "username".
    3. Also as per "Microsoft Knowledge Base, Article ID: 841215" Windows XP disables "Basic Auth" in its "Microsoft-WebDAV-MiniRedir/5.1.2600" mechanism by default for security reasons. But WebDAV expects "Basic Auth".

There are hundreds pages how to trick it to invoke "old" implementation, including some on the same page mentioned above; there is also a separate discussion regarding Windows Vista, where "old" implementation has to be separately installed. Windows 7 status is unknown.

Platform-independent clients.

  1. SkunkDAV Java-based client is simple and reliable, but unfortunately I could not make it support SSL-based access;
  2. Cadaver is CLI-based tool. It seems to work fine. 

Update (12-May-09). "Official" subversion book has a list of DAV clients. Among some known clients, some of them mentioned above, there is another Jaba-based client "DAV Explorer", it has been last updated in 2005 and looks a bit better than SkunkDAV, though I can't say there is a big difference.

Also, its help file says that in order to enable SSL in Java one has to run Java with -Dssl=true, and only from version 1.4 on; for earlier versions, one has to download special Java Secure Socket Extensions. It is likely with if run with these options, SkunkDAV will work ok with SSL DAV.

Labels: , , , , ,


# posted by Kostya @ 10:42 PM 0 comments

Wednesday, October 01, 2008

 

Mounting USB devices under Linux

For some reason, Ubuntu/Gnome often fails to mount properly USB drives when plugged-in. It is not hard to mount them manually, as long as user has super-user access and remembers necessary commands and options.

To mount anything, one has to know name of corresponding "device" file in "/dev"; under modern Linux, these are typically "/dev/sdc1", "/dev/sdd1", etc.

For some peculiar reason, there is no single utility which would print simple map "Name/manufacturer of USB disk => device file". Rather, there are four utilities which together allow user to accomplish this task:

  1. "lshw" is the only utility I know of which can print device names. To do that, run it like that: 
    sudo lshw -businfo | fgrep volume
  2. "lsusb" can print information about all USB devices (a lot of information with "-v"), including enough hints to identify specific device. It could be used both in "super user" mode and "regular user" mode;

  3. "fdisk -l" (super-user mode only) can print information about a device (if you have guessed its name).
  4. Finally, when you have figured out device name and file system type (FAT or NTFS), you run mount in super-user mode like that: 
    mount -t [vfat|ntfs] <device name, e.g. /dev/sdc1> <empty directory, e.g. /media/mydisk> -o \
     rw,nosuid,nodev,uhelper=hal,shortname=mixed,uid=1000,utf8,umask=077,flush

    Options can be adjusted, I believe above is what Gnome uses by default when mount is successful

[sudo] lsusb [-v] sudo fdisk -l /dev/sdc1 sudo lshw -businfo sudo mount -t [vfat|ntfs] /dev/sdc1 /lacie -o rw,nosuid,nodev,uhelper=hal,shortname=mixed,uid=1000,utf8,umask=077,flush

Labels: , , ,


# posted by Kostya @ 6:10 AM 0 comments

Monday, September 29, 2008

 

Samba installation under Ubuntu

In one of the recent posts, I listed some basic steps to configure Samba server under Debian  4; when I tried recently to similarly activate Samba under Ubuntu 8.04, it appeared that due to consistent improvement of Linux distributions, some steps needed to be corrected in some minor ways. Here I list the most important changes for future reference:

  1. Ubuntu is distributed by default with xinit as opposed to init (xinit has a "compatibility mode" which makes it to read and interpret "init" configuration file, but by default it is not created or updated since "init" is not installed). To enable Samba server under xinit, create file "samba" in directory "/etc/xinetd.d" with this (or similar) content (taking a hint from here):
service netbios-ssn
{
# "port" by default is taken from /etc/services
# port  = 139
 socket_type = stream
 wait  = no
 only_from = 192.168.0.0
 user  = root
 server  = /usr/sbin/smbd
 log_on_failure += HOST
 disable  = no
 mdns  = yes
 instances = 2
}
  1.  There is now option "passdb backend = tdbsam", which is very similar to using "smb passwd file", except that there is no need to use specific file; other than that, you can (and should) use smbpasswd to setup encrypted passwords;

  2. "Home directory" special share "[homes]" is commented out by default. Uncomment it and make changes as described.

Labels: , , , ,


# posted by Kostya @ 10:46 PM 0 comments

Tuesday, August 12, 2008

 

The mystery of a plus

Well, today I noticed that "long" listing in one of my directories appends "+" sign to each permissions string, like that: 

drwxrwxr-x+ 13 user      500 4096 2008-05-10 02:07 DivX
drwxrwxr-x+ 34 user      500 4096 2008-05-10 08:44 Raw

I was used to seeing this extra plus a lot under Cygwin, and never really gave it much thought always attributing this to some Cygwin peculiarities. But this time around this wasn't Cygwin at all - this was pristine Ubuntu 8.04. Given the specific path where this pluses were present, it was apparent that this is somehow related to Samba - these directories were originally uploaded with Samba daemon. So, I did understand from the get-go that in all likelihood Samba server is assigning some special flag to these files and "ls" is trying to notify me of the existence of this flag. I only need to figure out which specific flag it is (and how to remove it). This should be easy. Or so I thought.

The first page I stumbled upon in Google search had this to say:

The character after permissions is an ACL or extended attributes indicator. This character is an @ if extended attributes are associated with the file and the -@ option is in effect. Otherwise, this character is a plus sign (+) character if a nontrivial ACL is associated with the file or a space character if not.

ACL stands for "Access Control Lists" and allows for some fine-tuning of users' access permission on the level of individual user.

Ok, so what now? Same page listed some ACL-related command line options to ls, like '-v'; none of them was recognized by my ls. Well, that was to be expected since these were options for Solaris ls. How about Linux? No problem, said Google, you can use commands getfacl/setfacl to get/set ACL for a given file.

getfacl does indeed generate some output, but it turned out it does so even in absence of any ACLs, simply interpreting default Unix behavior based on file ownership and permissions. Attempts to set and/or clean ACLs for a file failed, and for a good reason: apparently, in order for ACL to be in effect for a mounted file system, mount option 'acl' must be included, as explained in some details e.g. here.

Fine, so if this is not ACL to blame, how about extended attributes? (Actually, extended attributes is not something parallel to ACLs; ACL implementation is based on extended attributes, which merely allows to attach more or less arbitrary "extended" info to each file in a supported file system; ACL is about how its attributes are to be interpreted by file system and kernel; attributes themselves bear no such interpretation). For one thing, this seemed as unlikely, since to use extended attributes one needs another mount option, "user_xattr". In fact, I didn't even have a package "attr" installed, which provided utilities getfattr/setfattr very similar to getfacl/setfacl.

Nevertheless, I installed the package and tried running getfattr on my files. None, as expected.

At this point in time I decided that the fastest way to get to the bottom of this puzzle was to look at the source of "ls" to see what kind of test makes it decide to append this extra "plus".

This was surprisingly simple enough to do; though this is somewhat off-topic, here is a brief overview what I did to compile my own debuggable "ls", for future references:

Anyway, it quickly turned out "ls" is calling function getfilecon() and upon receiving some non-trivial output appends "+" markup.

So, what is getfilecon()? It is part of SELinux toolkit; SELinux is, of course, a special security-enhancement system for Linux, which is totally separate from traditional Linux access restriction tools, including ACL; it works by assigning special "roles" to files, processes and users and then keeping a (potentially) huge policy database of who-can-do-what; it was originally developed by NSA and open-sourced in 2000.

On a practical level, SELinux-enabled system (Ubuntu Hardy being one of them) have special CLI switch "-Z" for many file and process-management utilities to report/take into account SELinux "context". Indeed, this finally allowed me to solve first piece of the mystery - force "ls" to tell me what it means my "+", by using "-Z": 

% ls -1Z
user_u:object_r:file_t DivX
user_u:object_r:file_t Raw

The only trouble is, of course, that SELinux was never enabled on my system! This could be seen with e.g. "id -Z" 

% id -Z
id: --context (-Z) works only on an SELinux-enabled kernel

Anyway, enough suspence, here is what (I think) is going on. Not unlike ACL, SELinux keeps its "context" in extended attributes. Whether kernel has SELinux enabled or not, utilities which are told to assign certain SELinux "types" to files, are free to do so using e.g. setfattr. These attributes, of course, will have no impact whatsoever on security of the system, but will be reported by utilities like "ls" which, again, simply looks at the specific attribute.

In fact, the name of this attribute is "security.selinux"; indeed, I can verify this with "getfattr" : 

% getfattr -n security.selinux -d Raw
# file: Raw
security.selinux="user_u:object_r:file_t\000"

So why woudn't "getfattr -d" report this? Isn't it in the absence of "-n" supposed to return all attributes?

Well, yes and no. By default, it reports all user attributes, that is, attributes with names which begin with "user.". To truly report all attributes, add "-m -" : 

% getfattr -m - -d Raw
# file: Raw
security.selinux="user_u:object_r:file_t\000"

You can, of course, assign this attribute with command "setfattr -n security.selinux -v <value> <file name>" or remove it altogether with "setfattr -x security.selinux <file name>".

This, finally, answers the question we asked in the beginning - how to remove this "plus" from "ls -l" output - and thus concluded our investigation.

Bonus track. Some SELinux-related references:

Labels: , , , , ,


# posted by Kostya @ 7:31 PM 0 comments

This page is powered by Blogger. Isn't yours?