kennywest

I have an old Pentium II running Debian Testing to protect my internal network from the Internet. Yesterday, I decided to test this firewall using a site that performs a portscan. I came accross http://www.testmyfirewall.com/ that did exactly what I wanted. This site claimed my internal address (the address of the computer sitting behind the firewall) was exposed to the outside. Yeah, right. After some digging I came accross this post from a guy having the same "problem". It seems that testmyfirewall starts an applet displaying the address of the computer running the applet, which is indeed the one sitting behind the firewall. So this site does not test your firewall, it only tests your browser which is a different thing. Just be aware of sites that claim to test your firewall, they're not allways right.

According to the documentation you can add locations/jars to your classpath using the CLASSPATH system variable in windows. I have discovered another way to do this. Just open the catalina.properties file in the conf directory. This should read: shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar Changing the line to: shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar,c:/test/foo.jar Will extend the shared classpath with foo.jar .

So I decided to split a project that contained 4 orchestration. I now have - 1 project containing a receive pipeline - 4 other projects containing the orchestrations, referencing the above project Apart from splitting the project, I decided to clean up the namespaces for the schema’s and property schema files. “Easy enough”, I thought, “Edit the schemas and property schemas using notepad or some other XML editor and we’re done”. Better think again. When deploying the “split” DLLs I encountered the following error in our test environment: errors: Property "ns0:Something" (msgType="http://foo#bar ") not found in Configuration database. The solution for this problem is not to edit your property schema files, but generate them again, if you’re refactoring namespaces or types. Reason for this is the fact that properties have their GUIDs and these have to be unique. Should you change the namespace and not the GUID for this property, uniqueness is not maintained. So, in sh

In my setup, users on my Ubuntu box are authenticated against an LDAP running on Debian. This is working very nicely, but since I upgraded from Hoary to Breezy, my icons for auto-mounted removable devices were not showing any more. This is, of course, very annoying. After googling a bit, I came accross this bug. But none of the suggestions worked for me. So I decided to create a real local user (i.e. a user not available in the LDAP) and see if this one still had the icons showing when auto-mounting happens. It did ;) So I guessed the local user was member of some local groups, my LDAP user wasn't member of. My guess was correct. Seems that the LDAP users have to be member of the local “users” group as well, which was the one I missed out. Below is the output of the id command for an LDAP user: uid=1002(ldapuser) gid=513(Domain Users) groups=24(cdrom),25(floppy),29(audio),46(plugdev),100(users),109(admin),513(Domain Users)