Now, this introduces some issues, as the Fortran/C program can be runned in many ways:

1. Absolute path (/home/asbjorn/test1/main)
2. Standing in the directory and run ./main
3. Having the /home/asbjorn/test1/ in your $PATH variable (Linux/UNIX), and type ‘main’.

Now, the simplest approach is to use the “int argc, char *argv[]” variables inside your ‘int main()’ method. Then the “argv[0]” would contain the binary file name, including any absolute path if that what being used. But, if your application is in your $PATH variable, it wont work.

A ‘dirty’ trick could be to use:

char path[255];
path = system("which main");

but, its not recommended using this approach. Another very hackish and cool solution is the following:

#include <stdlib.h>
#include <stdio.h>
#include <sys/param.h>
int main(int argc, char* argv[])
{
   char path[MAXPATHLEN];
   int length;
   length = readlink("/proc/self/exe", path, sizeof(path));
   if(length<0) {
      fprintf(stderr,"error resolving /proc/self/exe!\n");
      exit(1);
   }
   path[length] = '\0';
   printf("The absolute path to this running binary is: %s\n", path);
 
   return 0;
}

Another approach which is often used is to include some kind of configuration file that contains this path. Or, in my case, I could specify another folder which should hold my Python files. This approach would probably make more sense in the long run, as it is more flexible.

So, in case you find yourself in this situation, then feel free to copy-paste the code and save the day Have a good summer people!

Lately I’ve been working on securing some web accessible resource, especially Subversion access to repositories through the Apache webserver. One aspect we found very difficult was to secure subversion access through our apache server, when we had a Active Directory server to authenticate against (I know..).

Apache have some directives such as “Require valid-user” which signals that a user has to be authenticated against some authentication provider. This is in most cases a standard “.htaccess” and “.htpasswd” combination which provides this. For small projects, this may be a working approach. However, in a large-scale organization where you want a dynamic handling of users and their access, then using groups to reflect the users access to resources may be a better working solution.

For one of our projects, we wanted all LDAP (AD) users to have read access, while members of certain groups have read and write access. We solved this with the following Apache config:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<Location /wicked_project>
   DAV svn
   SVNParentPath /var/svn/wicked_project
   AuthzLDAPAuthoritative off
   AuthType basic
   AuthBasicProvider ldap
   AuthName "Need to authenticate here"
   AuthLDAPBindDN "ldap_user@domain.net"
   AuthLDAPBindPassword secretPassword
   AuthLDAPURL "ldap://ad.domain.net/dc=domain,dc=net?sAMAccountName?sub?(objectClass=*)"
 
   <Limit GET PROPFIND OPTIONS CHECKOUT>
      Require valid-user
   </Limit>
   <Limit REPORT MKACTIVITY PROPPATCH PUT MKCOL MOVE COPY DELETE LOCK UNLOCK MERGE>
   Require ldap-filter |(memberOf=CN=Staff,OU=GROUPS,DC=DOMAIN,DC=NET) \
                (memberOf=CN=Wicked_project_rw,OU=GROUPS,DC=DOMAIN,DC=NET)
   </Limit>
</Location>

Another LDAP directive which can work if you only need one group to have read and write access is the “ldap-group” directive. However, in our case we needed multiple groups, which is not supported by the “ldap-group” directive.

To solve this problem we used “ldap-filter” with multiple group filters inside the same filter, and divide them with the boolean OR. I don’t know if there are any more elegant ways of achieving the same result, but this solved our problems.

Having a second look at this “ldap-fiter” directive, I see that it have a significant strength in terms of flexibility. However, one aspect I have not considered is the performance of this approach. Without looking in-depth into the mod_ldap apache module, I can guess that for each filter inside the ldap-filter directive, it have to make a query to the LDAP (AD) server to retrieve the wanted resource. So, for each group filter inside the ldap-filter, you need a call. In our approach, we need two LDAP queries. As you now may see, the more groups to filter, the more LDAP queries, hence the performance will degrade the more complex the ldap-filter is.

Every now and then I get somewhat annoyed by the fact that I add temporary or “unwanted” files to a subversion repository. These files may be just temporary files, like *.tmp, which has no value of being kept in a repository, or compiled python files *.pyc, etc.

The common characteristics is that they are generally unwanted, and that they can easily be removed from the SVN repository. A common approach towards this issue is to set a property named “svn:ignore” on a directory, or the whole directory structure. This can be achieved with this command:

$# svn propset svn:ignore "*.tmp" .

where the single-dot at the end signalize the standing directory. However, this must be performed for each subversion project, which can get annoying in time. I’ve recently discovered the possibility of setting global subversion settings for my own user. The per-user subversion settings file is located on $HOME/.subversion/config. In that file there is a section named “[miscellany]“, which holds a variable named “global-ignores”. This variable can hold multiple ignore statements which will apply for all the svn checkouts you may work on (given you are using this user).

This subversion setting file also contains many more exciting options, such as automatic properties which apply to certain files. Have a look at the end for the $HOME/.subversion/config file and notice some of the predefined settings.

A tip based on personal experience is to hook the current files to the global-ignores variable:

*.pyc # python byte compiled code
*.swp # vim swap file
*.tmp # general temp files

• A simple webpage for my topdomain (fellinghaug.com)
• My very simple, yet (hopefully) powerfull Python search engine (codename “Wallace”)
• Contribute more to the open-source community (register myself as a python developer, solve bugs and translate projects on launchpad.net)

Let’s now get ahead of ourselves here, and just stop the list there. Adding more would simply make it overwhelming and unrealistic. If I surprise myself in terms of the timeframe (a year) for these goals, then I would allow myself to add more stuff on this list.

I would point to fellow developers out there to also make yourselves goal lists, as these lists tend to improve the developers efficiency. It certainly feels so in my case.

Jeg tenkte å ta for meg et voksende problem innen utveksling av dokumenter rundt omkring i Norge (og resten av verdenen). Etter at MS Office 2007 kom ut, og med det innførte et nytt filformat (docx, pptx, xlsx, ..), så har folk som tidligere har benyttet MS Office 2003/XP (og eldre) ikke vært istand til å lese dokumentene lagret i disse formatene. Enda verre er det for de som benytter OpenOffice (et gratis verktøy av tilsvarende funksjonalitet som MS Office).

Så, problemet ligger i at MS Office 2007 lagrer som default alle dokumenter i disse nye formatene. Og som kjent så tenker ikke folk flest over dette, og derfor vil mesteparten av produserte dokumenter bli lagret i slike obskure formater. Det skal nevnes at formatet er svært lik OOXML (dog oppfyller den ikke helt spesifikasjonene). Uansett, dette innebærer problemer for folk som benytter andre tilsvarende programmer.

Jeg har selv erfart å få e-post med slike dokumenter, da jeg konsekvent svarer at formatet er ukjent for meg og at de enten skal lagre i det (gamle) “doc” formatet eller ODT (OpenDocument format for tekstbehandling), eventuelt PDF. Sistnevnte byr på problemer dersom du er avhengig av å redigere dokumentet dog.

Hovedpoenget er at folk må slutte å benytte formater som er svært dårlig utbredt, da de innsnevrer mulighetene for andre å lese dokumentene. Inntil det faktisk er mulig for andre enn MS Office å lese og skrive i de respektive formatene, så anbefales det sterkt å unngå dem.