I’m listing here the topics I’m interested into about Funambol so that, if someone is interested, he can join the researches

• - Funambol and Apache
• - Funambol and https
• - Funambol and file sync (teleport project?)
• - Funambol and LDAP LUPO module

Yesterday I bought the ebook Funambol Mobile Open Source written by Stefano Fornari, cofounder and CTO of Funambol Inc.

It’s well written and easy, a must for Funambol newbies.

It’s only few days that I’m dealing with Funambol and I think that its portal is kind of overwhelming and sometimes messy, especially in the third part components.
This book, easy to read, is quickly driving me in the right direction saving a LOT of time.

Definitely a +1!

This is a howto to install and configure a funambol server with LDAP support

References:

• - Funambol Mobile Open Source – ebook
• - Funambol with Mysql: how to install
• - Funambol LDAP connector official page

(more…)

I’m installing and configuring a funambol server on linux (Debian 64bit squeeze).

After some days playing with its services I decided to move funambol database from the built in Hypersonic database to Mysql, mainly because I already have backup procedures for Mysql and I find comfortable to use a well-known database.

References:

• Funambol Mobile Open Source – ebook
• Funambol and LDAP

(more…)

This is the development plan for my projects starting from the December 2011.

Contact Engine:

• - add authentication support
• - improve contact/organization association DONE
• - improve contact/location association DONE
• - improve organization/location association DONE
• - add funambol support DONE
• - add POI list generation

MCB-SB:

• - bug fixing
• - add “smart search”
• - improve the concept of reports
• - transform the present dashboard into a report page (so the dashboard page will be the contact management page)
• - everything, except the contact manager, should be a MCB module DONE
• - transform “clients” core module for MCB-SB into “contact” core module DONE
• - improve contact module UI
• - add Administration Panel DONE
• - get MCB updates by Jesse DONE
• - use Contact Engine Funambol support DONE
• - add TRS (time-reporting system) module

Some parts are probably going to be changed during the roadmap itself but I’ll try to publish constantly some “bread-crumbs” so that interested people can follow the development status.

Note: The update to CI 2.1 won’t be done until most (or all) MCB will be updated

Updates

Imminent plan

[Ref: http://www.squadrainformatica.com/en/development]

[note: this guide could be not complete or not updated]

Requirements

• LAMP
• OpenLdap (installed somewhere, even another server)

(more…)

[Ref: http://www.squadrainformatica.com/en/development]

Contact Engine is one of my public projects.

Who is wondering why I’m developing it should (learn italian and) read the old posts tagged “contact-engine” on this blog. It’s a long time since when I started worrying about how to properly handle people, users and organization. I think it was august 2005.

What’s pushing me to write CE is this:

my sys-admin side can’t stand anymore to see application to handle users, people and organizations in its own way. This represents a barrier in inter-communication and starts the need of synchronization (which is probably the most scaring activity in the whole IT world).

I mean, once an entity like a person is well represented in one place, I don’t see any need to replicate/synchronize this information somewhere else. Ideally I’d more than happy if every application in the world would connect to FB to authenticate users because once Damiano Venturin is on FB … I see no other need to write it down somewhere else or to synchronize it with something else. Careful! I said ideally! With FB and probably with any other application the problem is all about the concept of “well represented person”.

With CE the aim is to represent persons, organizations and contacts at best as possible and to reuse the information for the larger number of application present in the organization/environment.

Presumibilmente vorreste usare l’utente admin per entrambi i progetti e non sarebbe male avere un’unica interfaccia di log-in.
In seguito all’autenticazione sareste l’admin di entrambi i progetti.
Ok i sogni sono finiti. Ve lo potete scordare. Perchè?

Ovvio.. Mambo fa il login in un modo, OWL in un altro.

Ora la domanda è: non esiste uno standard (che eviterebbe anche ad entrambi i progetti di mantenere tutta la sezione di sicurezza e login) oppure sono io che non ho cercato abbastanza bene?

E ancora .. cosa si cerca in questi casi? “standard login php” “login platform php” “user authentication php”

Ogni aiuto è gradito.

feed-rss

questo ldap è interessante. e nemmeno cosi difficile nella forma. l’uso invece … non è cosi semplice. forse perchè si utilizzano logiche e strumenti lontani anni luce dai normali database.

references:
glossario ldap
archivio di objectclass e attributi comuni
data types

tools:
ottimo ldap editor

stralci interessanti:

When you create an entry in a DIT its data contents are contained in attributes which are grouped into objectclasses which are packaged into schemasEverything in LDAP is hierarchical

All objectclasses and all attributes are defined inside schemas

objectclasses are the means for including attributes

objectclasses may be STRUCTURAL in which case they are used to create entries (data objects) or AUXILIARY in which case they may be added into any convenient entry

objectclasses define whether an attribute is mandatory (MUST be present) or optional (MAY be present)

To use an attribute in an entry its objectclass must be included in the entry definition and its objectclass must be included in a schema which must be identified to the LDAP server.

An attribute definition may be part of a hierarchy in which case it inherits all the properties of its parents e.g. commonName (cn), givenName (gn), surname (sn) are all children of the name attribute.

An attribute definition includes its form e.g. string, number etc.

questo esempio mostra come si definisce un attributo:

attributetype ( 2.5.4.46 NAME 'dnQualifier'EQUALITY caseIgnoreMatchORDERING caseIgnoreOrderingMatchSUBSTR caseIgnoreSubstringsMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

EQUALITY, ORDERING,SUBSTR vengono definite come matcing rules: descrivono alcune carattestiche dell’attributo in oggetto. le matching rules sono in genere built-in ldap

questo comando offre una (interminabile) lista delle matching rules built-in ldap:
ldapsearch -H ldap://localhost -x -s base -b “cn=subschema” “(objectclass=*)” matchingrules

questo comando offre la lista degli objectclass riconosciuti dall’ldap server
ldapsearch -H ldap://localhost -x -s base -b “cn=subschema” objectclasses

feed-rss

CAMPI “LOCKATI” DI EVOLUTION

con l’objectclass evolutionPerson definito nello schema standard di evolution alcuni campi non sono editabili.

includendo lo schema calentry.schema in slapd.conf ecco che i campi Calendar: e Free/Busy: diventano editabili

questo è il calentry.schema


#RFC2739 calEntry schema for OpenLDAP 2.x

# Version of RFC 2739 schema translated by Terrelle Shaw (xytek@xxxxxxxxx)
# Nov. 7, 2002
# Modifications by Peter Marschall
# Nov. 9, 2002

# Notes:
# * RFC2739 seems to be a bit sloppy about attribute type and
# objectclass definitions syntax and also about attribute syntax
# and matching rules.
# (It even counts the attributes in the calEntry objectclass wrong
# * The following changes have been applied to correct the schema
# – added description to each attributetype definition
# – changed SYNTAX from ‘IA5String’ to corresponding OID
# to make matching rules and syntax consistent
# – replaced illegal keyword SUBSTRING by SUBSTR
# – changed SUBSTR from caseIgnoreIA5Match to caseIgnoreIA5SubstringsMatch
# – removed illegal keyword MULTI-VALUE
# – added keyword SINGLE-VALUE where appropriate
# – removed USAGE since cwuserApplications is the default
# – added description to the objectclass defintion
# – corrected typo in objectclass definition
# – added the attributetypes defined but not used to the objectclass

# 2.4.4.1 calCalURI
attributetype ( 1.2.840.113556.1.4.478
NAME ‘calCalURI’
DESC ‘URI to a snapshot of the users entire default calendar’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )

# 2.4.4.2 calFBURL
attributetype ( 1.2.840.113556.1.4.479
NAME ‘calFBURL’
DESC ‘URI to the users default free/busy time data’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )

# 2.4.4.3 calCAPURI
attributetype ( 1.2.840.113556.1.4.480
NAME ‘calCAPURI’
DESC ‘URI used to communicate with the users calendar’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )

# 2.4.4.4 calCalAdrURI
attributetype ( 1.2.840.113556.1.4.481
NAME ‘calCalAdrURI’
DESC ‘URI to which event requests should be sent for the user’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )

# 2.4.4.5 calOtherCalURIs
attributetype ( 1.2.840.113556.1.4.482
NAME ‘calOtherCalURIs’
DESC ‘URIs to snapshots of non-default calendars belonging to the user’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 2.4.4.6 calOtherFBURLs
attributetype ( 1.2.840.113556.1.4.483
NAME ‘calOtherFBURLs’
DESC ‘URIs to non-default free/busy data belonging to the user’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 2.4.4.7 calOtherCAPURIs
attributetype ( 1.2.840.113556.1.4.484
NAME ‘calOtherCAPURIs’
DESC ‘URIs to non-default calendars belonging to the user’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 2.4.4.8 calOtherCalAdrURIs
attributetype ( 1.2.840.113556.1.4.485
NAME ‘calOtherCalAdrURIs’
DESC ‘URIs of destinations for event requests to non-default calendars’
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 2.4.3.1 calEntry
objectclass ( 1.2.840.113556.1.5.87
NAME ‘calEntry’
DESC ‘Calendering and free/busy information’
SUP top AUXILIARY
MAY ( calCalURI $ calFBURL $ calCAPURI $ calCalAdrURI $
calOtherCAPURIs $ calOtherCalURIs $ calOtherFBURLs $
calOtherCalAdrURIs ) )

# EOF

stessa sorte per i campi dedicati all’instant messaging. ma in questo caso non so che schema usare. se qualcuno ne sa posti un commento per favore.
ad ogni modo i campi di istant messaging non sono cosi importanti almeno fino a quando non ci sarà una migliore integrazione tra gaim ed evolution

——
CAMPI CODICE FISCALE E PARTITA IVA
non ho trovato alcuno schema che possa descrivere i campi codice fiscale e partita iva perciò ne
ho scritto uno semplice ma non ancora definitivo. lo schema descrive un nuovo oggetto che ho chiamato juridicPersonIT. A giorni Iana mi dovrebbe rilasciare un PEN e a quel punto potrò riscrivere correttamente gli OID che per ora mi sono inventato. (sempre che non mi capiti di trovare uno schema bello e pronto)

ecco il risultato:

l’esperimento funziona. i campi aggiuntivi sono disponibili aggiungendo l’objectclass juridicPersonIT a ciascun contatto della rubrica di evolution. quindi questa sarà una delle attività che dovrà fare il modulo per la scrittura contatti dell’erp.

——
EKIGA
voglio ora osservare se la rubrica condivisa di evolution puo essere utilizzata anche da altre applicazioni, in virtu di quanto detto nella Parte 1.

provo con Ekiga:
ekiga supporta più rubrica remote su ldap ma il manuale di Ekiga non è molto chiaro. ci ho messo un po a farlo funzionare ma questo è il risultato

uno dei limiti della rubrica di ldap è che prevede un solo campo telefonico, pertanto sono costretto a definire la rubrica “cellulari”, “fisso” etc.
inoltre il campo sensibile viene sempre inteso come numero VOIP e viene ignorata la possibilità di elencare anche normali numeri telefonici, quindi il “+” che precede i prefissi internazionali viene troncato; non è un gran problema perchè si puo correggere manualmente dopo aver cliccato sul contatto.
sarebbe interessante se il gruppo di lavoro di ekiga lavorasse su questi dettagli. proverò a fare una richiesta.

——
CONTACT LOOKUP APPLET
questa magnifica applet per gnome si appoggia all’evolution data server e consente di reperire velocemente le informazioni legate ad un contatto. anche questo software funziona con la rubrica di ldap

ecco uno screenshot

——
THUNDERBIRD
ho trovato un’interessante howto che spiega come rendere compatibili una rubrica ldap per thunderbird ed outlook. quindi penso che si possa estendere il concetto anche ad una rubrica di evolution…..
gli skill necessari per raggiungere questo obiettivo vanno ben oltre un howto. è quindi ora di dedicarsi a un whyto.

quindi mi cimento nello studio vero e proprio di ldap con questa guida. ritornerò su questo punto quando avrò sufficienti competenze

ULTIME SCOPERTE
altre persona alla ricerca dello schema perduto:
Christian Weiske
Creating a well defined LDAP directory query interface for email clients
e ancora

feed-rss