Inbound e-mail and gmail.com accounts

I’ve tested Alfresco 4.0.d inbound email (to Space with Alias) configuration with Google Mail STMP, but mails not received…

To get the solution first increase logging level for subethamail package:

log4j.logger.org.subethamail.smtp.server=debug

Let see the log events:

00:08:30,585 DEBUG [org.subethamail.smtp.server.Session] SMTP connection from mail-wg0-f45.google.com/74.125.82.45, new connection count: 1
00:08:30,586 DEBUG [org.subethamail.smtp.server.Session] Server: 220 alfresco.louise.hu ESMTP SubEthaSMTP 3.1.6
00:08:30,615 DEBUG [org.subethamail.smtp.server.Session] Client: EHLO mail-wg0-f45.google.com
00:08:30,615 DEBUG [org.subethamail.smtp.server.Session] Server: 250-alfresco.louise.hu
250-8BITMIME
250-STARTTLS
250 Ok
00:08:30,643 DEBUG [org.subethamail.smtp.server.Session] Client: STARTTLS
00:08:30,643 DEBUG [org.subethamail.smtp.server.Session] Server: 220 Ready to start TLS
00:08:30,673 DEBUG [org.subethamail.smtp.server.Session] Error reading client command: Socket closed
java.net.SocketException: Socket closed
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:129)
        at java.net.SocketInputStream.read(SocketInputStream.java:182)
        at org.subethamail.smtp.io.CRLFTerminatedReader.read(CRLFTerminatedReader.java:194)
        at org.subethamail.smtp.io.CRLFTerminatedReader.readLine(CRLFTerminatedReader.java:135)
        at org.subethamail.smtp.server.Session.runCommandLoop(Session.java:200)
        at org.subethamail.smtp.server.Session.run(Session.java:125)

As we read above, Google Mail SMTP tried to use TLS, but Alfresco was not configured with StartTLS support.

To take a quick fix to receive emails from gmail accounts, just hide TLS support in alfresco-global.properties:

email.server.hideTLS=true

Zimbra briefcase export tool

Simple shell script to retrieve all user accounts from Zimbra, and recursively download Briefcase contents into user-named subfolders.

Script requires https url of zimbra server with active admin account/password.

#!/bin/bash
#
# Zimbra Briefcases export tool by LouiSe@louise.hu
#
# Usage (run on Zimbra server):
#  ./zimbra-briefcase-export.sh "https://myzimbra.com:7071" "admin@myzimbra.com" "mypassword"
#

ZIMBRA_HOST=$1
ACCOUNT_LIST=/tmp/zimbra_accounts.txt
ACCOUNT_ADMIN=$2
ACCOUNT_PASSWORD=$3
OUTPUT_DIR=briefcases
BRIEFCASE_DIR=Briefcase
PACKAGE_EXTENSION=tgz

mkdir ${OUTPUT_DIR}

echo "Retrieving all accounts from Zimbra into file '${ACCOUNT_LIST}'..."
su - -c "zmprov -l gaa >${ACCOUNT_LIST}" zimbra

echo "Processing all accounts on Zimbra host '${ZIMBRA_HOST}'"
while read USERNAME
do
    echo "Downloading Briefcase for account '${USERNAME}' into file '${USERNAME}.zip' and uncompressing..."
    curl -k --user "${ACCOUNT_ADMIN}:${ACCOUNT_PASSWORD}" "${ZIMBRA_HOST}/home/${USERNAME}/Briefcase?fmt=${PACKAGE_EXTENSION}" -o ${OUTPUT_DIR}/${USERNAME}.${PACKAGE_EXTENSION}
    cd ${OUTPUT_DIR}
    tar xzf ${USERNAME}.${PACKAGE_EXTENSION}
    mv ${BRIEFCASE_DIR} ${USERNAME}
    rm ${USERNAME}.${PACKAGE_EXTENSION}
    cd ..
done < ${ACCOUNT_LIST}
echo "Done."

Just like a Zimbra to Alfresco (User Homes) document library migration tool...

Alfresco with Zimbra LDAP

So, i’ve done with a working LDAP configuration to sync users and groups from Zimbra (see below), but one thing missing yet…

The Alfresco synchronizer service reads from LDAP and writes all users and all groups into repository, but does not reproduce nested group hierarchy.

Retrieve Zimbra LDAP root password:

zmlocalconfig -s zimbra_ldap_password

Let see the configuration in extension/subsystems/Authentication/ldap/ldap1/ldap-authentication.properties:

...

# The URL to connect to the LDAP server 
ldap.authentication.java.naming.provider.url=ldap://zimbra.XXX.hu:389

# The authentication mechanism to use for password validation
ldap.authentication.java.naming.security.authentication=simple

...

# This flag enables use of this LDAP subsystem for user and group
# synchronization. It may be that this subsytem should only be used for 
# authentication, in which case this flag should be set to false.
ldap.synchronization.active=true

# The authentication mechanism to use for synchronization
ldap.synchronization.java.naming.security.authentication=simple

# The default principal to use (only used for LDAP sync)
ldap.synchronization.java.naming.security.principal=uid\=zimbra,cn\=admins,cn\=zimbra

# The password for the default principal (only used for LDAP sync)
ldap.synchronization.java.naming.security.credentials=ZIMBRA_LDAP_PASSWORD

# The query to select all objects that represent the groups to import.
ldap.synchronization.groupQuery=(objectclass\=zimbraDistributionList)

# The query to select objects that represent the groups to import that have changed since a certain time.
ldap.synchronization.groupDifferentialQuery=(&(objectclass\=zimbraDistributionList)(!(modifyTimestamp< \={0})))


# The query to select all objects that represent the users to import.
ldap.synchronization.personQuery=(objectClass\=organizationalPerson)

# The query to select objects that represent the users to import that have changed since a certain time.
ldap.synchronization.personDifferentialQuery=(&(objectclass\=organizationalPerson)(!(modifyTimestamp<\={0})))


# The group search base restricts the LDAP group query to a sub section of tree on the LDAP server.
ldap.synchronization.groupSearchBase=ou\=people,dc\=XXX,dc\=hu

# The user search base restricts the LDAP user query to a sub section of tree on the LDAP server.
ldap.synchronization.userSearchBase=ou\=people,dc\=XXX,dc\=hu


# The name of the operational attribute recording the last update time for a group or user.
ldap.synchronization.modifyTimestampAttributeName=modifyTimestamp

# The timestamp format. Unfortunately, this varies between directory servers.
ldap.synchronization.timestampFormat=yyyyMMddHHmmss'Z'


# The attribute name on people objects found in LDAP to use as the uid in Alfresco
ldap.synchronization.userIdAttributeName=mail

# The attribute on person objects in LDAP to map to the first name property in Alfresco
ldap.synchronization.userFirstNameAttributeName=displayName

# The attribute on person objects in LDAP to map to the last name property in Alfresco
ldap.synchronization.userLastNameAttributeName=

# The attribute on person objects in LDAP to map to the email property in Alfresco
ldap.synchronization.userEmailAttributeName=mail

# The attribute on person objects in LDAP to map to the organizational id  property in Alfresco
ldap.synchronization.userOrganizationalIdAttributeName=cn

# The default home folder provider to use for people created via LDAP import
ldap.synchronization.defaultHomeFolderProvider=userHomesHomeFolderProvider


# The attribute on LDAP group objects to map to the authority name property in Alfresco
ldap.synchronization.groupIdAttributeName=mail

# The attribute on LDAP group objects to map to the authority display name property in Alfresco (v3.3+)
ldap.synchronization.groupDisplayNameAttributeName=mail

# The group type in LDAP
ldap.synchronization.groupType=zimbraDistributionList

# The person type in LDAP
ldap.synchronization.personType=organizationalPerson

# The attribute in LDAP on group objects that defines the DN for its members
ldap.synchronization.groupMemberAttributeName=zimbraMailForwardingAddress

# If true progress estimation is enabled. When enabled, the user query has to be run twice in order to count entries.
ldap.synchronization.enableProgressEstimation=true

Hint: Zimbra and LDAP posts at wajatimur.wordpress.com blog

Midnight Commander 4.8.1.3 OSX

GNU Midnight Commander (also referred to as MC) is a user shell with text-mode full-screen interface. It can be run on the OS console, in xterm and other terminal emulators.

GNU Midnight Commander allows you to manage files while making most of you screen and giving you a clear representation of the filesystem, yet it’s simple enough to be run over a telnet or ssh session.

Midnight Commander 4.8.1.1 OSX Universal Binary

Next to official release of stable sources, this universal binary (i386, ppc) built (without source code modification) and linked with following libraries:
– gettext v0.18.1.1
– glib v2.21.6
– pkg-config v0.23

Configured with options: –disable-dependency-tracking –disable-shared –with-screen=ncurses –with-vfs –enable-vfs-mcfs –with-edit –without-x –with-subshell –enable-charset –enable-extcharset –enable-background –enable-netcode

[~/Development/porting/mc ]
$mc -V 
GNU Midnight Commander 4.8.1.3
Built with GLib 2.21.6
Using the ncurses library
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, fish
Data types: char: 8; int: 32; long: 32; void *: 32; size_t: 32; off_t: 64;

This release requires Mac OS X 10.4 or newer, and tested on 10.5 Leopard (PPC), 10.6 Snow Leopard, 10.7 Lion and 10.8 Mountain Lion.

Download installer package: mc-4.8.1.3-bin-osx-universal.zip (list of other Mac binary releases)

Original sources: www.midnight-commander.org

Major changes since 4.8.1.2

Midnight Commander 4.8.0 OSX

GNU Midnight Commander (also referred to as MC) is a user shell with text-mode full-screen interface. It can be run on the OS console, in xterm and other terminal emulators.

GNU Midnight Commander allows you to manage files while making most of you screen and giving you a clear representation of the filesystem, yet it’s simple enough to be run over a telnet or ssh session.

Midnight Commander 4.8.0 OSX Universal Binary

Next to official release of stable sources, this universal binary (i386, ppc) built (without source code modification) and linked with following libraries:
– gettext v0.18.1.1
– glib v2.21.6
– pkg-config v0.23

Configured with options: –disable-dependency-tracking –disable-shared –with-screen=ncurses –with-vfs –enable-vfs-mcfs –with-edit –without-x –with-subshell –enable-charset –enable-extcharset –enable-background –enable-netcode

[~/Development/porting/mc ]
$mc -V
GNU Midnight Commander 4.8.0
Built with GLib 2.21.6
Using the ncurses library
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, fish
Data types: char: 8; int: 32; long: 32; void *: 32; size_t: 32; off_t: 64;

This release requires Mac OS X 10.4 or newer, and tested on 10.5 Leopard (PPC), 10.6 Snow Leopard and 10.7 Lion.

Download installer package: mc-4.8.0-bin-osx-universal.zip (list of other, newer Mac binary releases)

Original sources: www.midnight-commander.org

Major changes since 4.7.5

Enable “remote” root object in Alfresco 3.4+

From the 3.3 version Alfresco is overriding the Spring Surf webscripts container bean removing the remote definition.

This modification also affects number of custom webscripts developed with previous releases. Let see, how to enable “remote” root object in current Alfresco installation;

1. Find your “web-scripts-application-context.xml” configuration file in alfresco webapp, or in shared classes.
2. Search for “webscripts.container”, and update “map” contents like this:


      Repository
      
         
           
              
           

           
           

         
      
...

3. Restart Alfresco server
4. Check custom configuration with following code:

var serviceUrl = (args.service === null) ? "/api/repository" : args.service;
var conn = remote.connect("alfresco");
var result = conn.get(stringUtils.urlEncodeComponent(serviceUrl));

Just another, non-remote solution: Nathan McMinn: Calling Web Services from the Alfresco Javascript API

NetBeans 6.8 and OpenOffice 3.3 on Snow Leopard

A quick note to setup working OpenOffice.org plugin development on Mac OS X 10.6 (64bit)…

NetBeans v6.8 (as the last OOo SDK supported version now) works with OpenOffice Extension 2.0.6 (org-openoffice-extensions-2.0.6.nbm) and OpenOffice 3.3 SDK, but NetBeans configuration should be modified to access OpenOffice by Java. You can not create new OpenOffice.org Component (UNO) without this modification, because NetBeans unable to read Service and Interface classes from OOo and results and empty list after several loads of soffice command.

Error log message looks like following, and see why here (issue 110543):

... /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/java[14982]: dlopen(/Volumes/MBP_Addons/Application.Addon/Editors/OpenOffice.org.app/Contents/basis-link/ure-link/lib/libjpipe.jnilib, 1): no suitable image found.  Did find:\n	/Volumes/MBP_Addons/Application.Addon/Editors/OpenOffice.org.app/Contents/basis-link/ure-link/lib/libjpipe.jnilib: mach-o, but wrong architecture

The solution is simple with updating value “netbeans_default_options” in “netbeans.conf” with option “-J-d32”. You can find config file in “NetBeans 6.8.app/Contents/Resources/NetBeans/etc” folder.