SEVERE: Socket accept failed
org.apache.tomcat.jni.Error: Too many open files
        at org.apache.tomcat.jni.Socket.accept(Native Method)
        at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:1156)
        at java.lang.Thread.run(Thread.java:619)

So, I initially had a ulimit -n of 1024. No problem, changed my shell and limits.conf to have 4096 and restarted the process. The next day, same error. So increased it to 32768. Same results.

So I ran a couple cron job to see what was happening during the night:

# Monitor openfiles
* * * * *       /usr/sbin/lsof -n -u root|egrep 'java|alfresco|tomc' | wc -l >> /tmp/lsof_mon.out
* * * * *       cat /proc/sys/fs/file-nr >> /tmp/file-nr.out

Apparently, the results are OK, despite the continuing errors. The “lsof” cron job never get any higer than 1320, and the monitor on file-nr didn’t get above “2550 0 767274″.

Yes, I made sure the process was launched with the new parameter. Even after restarting the system, ulimit -n returns the correct amount of file descriptors. Even running “lsof” by itself doesn’t return more than 3000 lines.

For info, server is running CentOS 2.6.18-194.3.1.el5 #1 SMP x86_64. libtcnative is at version 1.20. Process running as root.

Any idea anyone? Thanks.

find ./contentstore -type f -exec file -inb {} \;| sort |uniq -c|sort -nr

48724 application/pdf
3022
2863 application/postscript
1909 text/plain; charset=us-ascii
1830 application/octet-stream
340 image/png
116 application/x-empty
104 text/x-c++; charset=us-ascii
93 application/msword application/msword
54 application/x-zip
40 image/jpeg
30 application/msword
29 text/x-c; charset=us-ascii
27 text/html
15 application/x-shockwave-flash
11 very short file (no magic)
9 text/PGP armored data message
8 text/plain; charset=utf-8
2 text/plain; charset=iso-8859-1
2 application/x-dosexec
1 video/x-msvideo
1 text/x-c++; charset=iso-8859-1

create procedure alfresco_doc_report ()
begin
    declare alfdoc_type varchar(50);
    declare loopdone int default 0;
    declare c1 cursor for select local_name from alf_qname where local_name in
                        ('doctype1', 'doctype2', 'doctype3');
    declare continue handler for NOT FOUND set loopdone = 1;

    open c1;

    fetch c1 into alfdoc_type;

    while not loopdone do
        SELECT alfdoc_type, count(*) FROM alfresco_rm.alf_node
        where store_id = (select id from alf_store where protocol = 'workspace' and identifier = 'SpacesStore')
        AND type_qname_id = (select id from alf_qname where local_name = alfdoc_type);

        fetch c1 into alfdoc_type;
    end while;

    close c1;

end
;

Edit: Removed the line ” inner join alfresco_rm.alf_node_properties b on a.id=b.node_id”

export GDK_NATIVE_WINDOWS=true

Then launch the application from that same terminal. Hopefully, this should make things a little better.

It is working for me, but it may not for you. Please post your questions on the Bonita forums, many eyes will look at your issue and try to help you.

Here is a dirty PDF for those who wants. However, if you do use this howto, always refer to the online version for updates and up-to-date content.
Bonita LDAP howto

It may not render well in this blog, so I’d advise in pasting the code in your favorite editor to see clearly.

My environment at this time is:

• Centos 5.4 latest updates
• Jboss 5.1 GA
• BOS 5.0.1
• Java JDK 1.6.0 update 18
• Active Directory 2003

To give a reference, here is how my base directory look like. I will refer to it when editing some files.

Under /opt:

lrwxrwxrwx  1 root root    9 Feb 23 11:39 BOS -> BOS-5.0.1
drwxr-xr-x  5 root root 4096 Feb 15 19:33 BOS-5.0.1
lrwxrwxrwx  1 root root   11 Feb 23 13:58 java-jdk-6 -> jdk1.6.0_18
lrwxrwxrwx  1 root root   14 Feb 23 16:19 jboss -> jboss-5.1.0.GA
drwxr-xr-x  9 root root 4096 Mar  4 09:57 jboss-5.1.0.GA
drwxr-xr-x 10 root root 4096 Feb 23 13:57 jdk1.6.0_18

We will use the org.jboss.security.auth.spi.LdapExtLoginModule, as it will allow us to bind to the ActiveDirectory server. If you can allow for anonymous LDAP requests, then you may also try the Sun LDAPLoginModule.

jBoss configuration and EAR generation

JAVA_OPTS

In the run.sh file of jboss /opt/jboss/bin/run.sh) , edit it to configure your JAVA_OPTS:

JAVA_OPTS="-Dorg.ow2.bonita.api-type=EJB3 -server -Xms256m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256m"

Alongside specifying the EJB3 for Bonita, I am setting reasonable settings for jBoss java memory, and possible avoid Permgen out of memory errors.

Extra: For quick and unsecure monitoring using jconsole, also add the following.

JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=10001 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"

bonita-environment.xml

… under the /opt/BOS/runtime/conf directory directly. It will be used when building the EAR file.

So, we can already specify the implementation of the AuthenticationService interface, which we will call SimpleLdapAuth.
Edit the file /opt/BOS/runtime/bonita-environment.xml. It should look like the following:

      <!-- Description: Implementation of the authentication service. -->

      <!-- <authentication-service name='authentication-service' class='org.ow2.bonita.services.impl.DbAuthentication'> -->

      <authentication-service name='authentication-service' class='com.domain.bonita.auth.SimpleLdapAuth'>

        <arg><string value='bonita-session:core' /></arg>

      </authentication-service>

Of course, your package path will vary.
A sample, simple, implementation of the interface follows later on.

Generating bonita.ear

We now need to go ahead and generate our bonita.ear file, which will then be used by jBoss.

cd/opt/BOS/runtime

Now, build your ejb3.

ant ear.ejb3

You should get something like this:

[root@bonita-test runtime]# ant ear.ejb3

Buildfile: build.xml

ear.genBonitaConfJar:

ear.ejb3:

ear:

    [mkdir] Created dir: /opt/BOS-5.0.1/runtime/ear/tmp

    [unjar] Expanding: /opt/BOS-5.0.1/runtime/lib/server/bonita-server-5.0.1.jar into /opt/BOS-5.0.1/runtime/ear/tmp

     [copy] Copying 1 file to /opt/BOS-5.0.1/runtime/ear/tmp/META-INF

ear.copyJeeDD:

     [copy] Copying 1 file to /opt/BOS-5.0.1/runtime/ear/tmp/META-INF

      [jar] Building jar: /opt/BOS-5.0.1/runtime/ear/ejb3/bonita-ejbjar.jar

   [delete] Deleting directory /opt/BOS-5.0.1/runtime/ear/tmp

      [ear] Building ear: /opt/BOS-5.0.1/runtime/ear/ejb3/bonita.ear

     [echo] EJB3 ear has been generated in ear/ejb3 directory.

     [echo] You can use it in the easybeans container, jonas 5 and jboss 5 application server.

BUILD SUCCESSFUL

Total time: 4 seconds

Now, copy the bonita.ear file into your jboss deploy directory.

cp /opt/BOS-5.0.1/runtime/ear/ejb3/bonita.ear
 /opt/jboss/server/default/deploy/

login-config.xml

Add the 2 stanzas to the end of your login-config.xml, before the end tag. It is valid for an AD server (ie: (sAMAccountName={0}) is typically AD).)

<application-policy name="BonitaAuth">

  <authentication>

        <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" 

        flag="required">

        <module-option name="java.naming.provider.url">ldap://your_ldap_server:389</module-option>

        <module-option name="java.naming.security.authentication">simple</module-option>

        <module-option name="baseCtxDN">DC=domain,DC=com</module-option>

        <module-option name="bindDN">DOMAIN\ldapbrowser</module-option>

        <module-option name="bindCredential"><![CDATA[Yourpasswd]]></module-option>

        <module-option name="baseFilter">(sAMAccountName={0})</module-option>

        <module-option name="searchScope">SUBTREE_SCOPE</module-option>

        <module-option name="allowEmptyPasswords">false</module-option>

        <module-option name="debug">true</module-option>

        <module-option name="rolesCtxDN">DC=domain,DC=com</module-option>

        <module-option name="roleFilter">(sAMAccountName={0})</module-option>

        <module-option name="roleAttributeID">memberOf</module-option>

        <module-option name="roleAttributeIsDN">true</module-option>

        <module-option name="roleNameAttributeID">cn</module-option>

        <module-option name="java.naming.referral">follow</module-option>

        </login-module>

    </authentication>

  </application-policy>

  <application-policy name="BonitaStore">

    <authentication>

       <login-module code="org.ow2.bonita.identity.auth.BonitaRemoteLoginModule" flag="required"/>

       <login-module code="org.jboss.security.ClientLoginModule" flag="required">

         <module-option name="password-stacking">useFirstPass</module-option>

      </login-module>

    </authentication>

  </application-policy>

Your jaas-standard.cfg will then not be used anymore. You can comment everything out.

Implementation of AuthentionService interface

Java Code

Here you need to develop a little piece of java. Here is an example that will get you through for starters.

package com.domain.bonita.auth;

/**
 * @author chapeaurouge
 * @date 04/03/2010
 * @version 0.1
 */

import org.ow2.bonita.facade.exception.UserNotFoundException;
import org.ow2.bonita.services.AuthenticationService;

public class SimpleLdapAuth implements AuthenticationService {

	private String persistenceServiceName;

	public SimpleLdapAuth(String persistenceServiceName) {
		super();
		this.persistenceServiceName = persistenceServiceName;
	}

	/**
	 * Determines if the user should have amdin accesses to the bonita interface
	 * Let's say that Domain Admins have that privilege
	 */
	public boolean isUserAdmin(String username) throws UserNotFoundException {
		if (username.equals("MyAdmin")) {
			return true;
		} else {
			return false;
		}
	}

	/**
	 * @return always true. If the LDAP request failed before, it doesn't matter (?)
	 * Necessary to implement interface
	 */
	public boolean checkUserCredentials(String username, String password) {
		return true;
	}
}

Compiling

Compile the java code into a .class. Make sure the bonita jars are in your classpath.

javac -cp ~/BOS-5.0.1/runtime/lib/server/bonita* SimpleLdapAuth.java

You should then have your .class file. If you did it locally, you can then upload it to your server.

Deploying

A manual way would be to do the following.
Go to your /opt/jboss/server/default/lib, create the directory hierarchy for your package name. So with our example, you could type

mkdir -p com/domain/bonita/auth

Then copy, your .class in it. Now, still in your jboss lib directory, create a .jar file, as:

jar -cvf domainLdapAuth.jar com/domain/bonita/auth/SimpleLdapAuth.class

Your jar will now be deployed on the next server startup.

Getting more verbose output

Edit /opt/jboss/server/default/conf/jboss-log4j.xml, and uncomment the following block:

 <category name="org.jboss.security">

 <priority value="TRACE"/>

 <appender-ref ref="CONSOLE.SECURITY"/>

 </category>

Conclusion

This should be it. I may have forgotten some things, or overlooked some steps. Hopefully, this was of some help for some of you.
You can now (re)start your jBoss server for the changes to take effect. Don’t forget to tail -f server.log to see how it looks like.
Your feedback and comments are welcome.
Thanks to rlg and abirembaut for their help in the forums.

sudo zypper ar http://download.opensuse.org/repositories/OpenOffice.org:/STABLE/openSUSE_11.2 OOo_STABLE

Update using zypper, with following commands. Since the regular OpenOffice doesn’t come from this repository, you have to use the –from parameter

sudo zypper dup --from OOo_STABLE

Note: It is a double-dash in front of the “from” parameter. Thanks for the comments.

The device is powered by the open-source Android operating system.

Can’t wait to get it

Here is a story which caught our attention at work. This is an article that brings down the reputation of all MSCE’s out there. Moreover, by not checking his facts, the author is also taking a high risk, in slandering a well established bank.

http://www.itcreme.com/2009/07/04/what-is-the-best-way-to-stay-safe-online/

Obviously, the allegations held by this consultant against Banque Invik and PayZone about not being secure are wrong, misleading, and slandering. We see here why.

This MSCE, with over 10 years experience, apparently doesn’t understand what a frame is, nor does he know how to get to its information. In the screenshot shown in his article, he refers to the page where you can actually login. Obviously, that page must be made secure. That page, as shown by the browser (IE or FF) doesn’t indeed start with “https://” which can be somewhat misleading for a non-professional. However, simply displaying the page source shows:

That should be sufficient to think about performing a right-click on the login box, going to “This Frame > View Frame info” (in Firefox), would show the following (there is more details in IE if you want to try), thereby showing the login is actually secured with SSL (actually a valid Globalsign 128bits certificate).

Such unverified information (nevertheless one that can be easily accessed), slandering a well established bank, can lead to potential customer loss; Furthermore, coming from a “(MCSE: Security, MCT, MCTS) [...] senior technical consultant” (Quote from his site), this kind of article can only harm the reputation of all MSCE’s out there… As for the author himself, I guess he will be more cautious in verifying his facts next time. If he’s clever enough, we can expect him to acknowledge his errors, and make public excuses on his website. This might mitigate the loss of potential or existing clients of the Payzone product.

So the advice of the day: Never trust an MSCE

Fred, UNcertified Microsoft engineer