Open Provisioning ToolKit phoenix moment

OpenPTKI’m sitting in training this week with our Solution Architects team and was talking to my long time colleague Scott Fehrman about a customer I recently met and a mention of the Open Provisioning ToolKit (OpenPTK) in one of the slides. OpenPTK is an open source project that Scott, Terry Sigle and Derrick Harcey founded at Sun Microsystems some years ago.

As we’re talking Scott realized that the website that hosted OpenPTK source code, issues and downloads (java.net) is gone. As he had a copy of the latest version, he put it back online on his github account.

If anyone is using OpenPTK and would like to get the code, or even better work on it, it has raised from the hashes and is now publicly available:

https://github.com/sfehrman/openptk

SnowCamp.io 2018

2017-sticker_peppercarrot_snowcamp2018_exportI’m one of the organisers of a developers’ conference here in Grenoble, France, the SnowCamp. The 3rd edition took place last week at Minatec. During 3 days, we hosted 10 University workshops, 40 presentations, 3 keynotes, and welcomed 375 attendees. And on the Saturday, we ran a smaller unconference with some of the speakers on the snowy slopes of Chamrousse, the closest ski resort to Grenoble.

Untitled

It has been 4 very intense days, but I’m really happy with how smooth the event went, and I’m excited to help organising it again next year (no spoiler, but it should take place end of January 2019).

My photos of the event are on my Flickr account, but they are also aggregated with other photographers’ shots on the SnowCamp Flickr Album.
SnowCamp 2018

Data Confidentiality with OpenDJ LDAP Directory Services

FR_plogo_org_FC_openDJ-300x86Directory Servers have been used and continue to be used to store and retrieve identity information, including some data that is sensitive and should be protected. OpenDJ LDAP Directory Services, like many directory servers, has an extensive set of features to protect the data, from securing network connections and communications, authenticating users, to access controls and privileges… However, in the last few years, the way LDAP directory services have been deployed and managed has changed significantly, as they are moving to the “Cloud”. Already many of ForgeRock customers are deploying OpenDJ servers on Amazon or MS Azure, and the requirements for data confidentiality are increasing, especially as the file system and disk management are no longer under their control. For that reason, we’ve recently introduced a new feature in OpenDJ, giving the ability to administrators to encrypt all or part of the directory data before writing to disk.clouddataprotection

The OpenDJ Data Confidentiality feature can be enabled on a per database backend basis to encrypt LDAP entries before being stored to disk. Optionally, indexes can also be protected, individually. An administrator may chose to protect all indexes, or only a few of them, those that contain data that should remain confidential, like cn (common name), sn (surname)… Additionally, the confidentiality of the replication logs can be enabled, and then it’s enabled for all changes of all database backends. Note that if data confidentiality is enabled on an equality index, this index can no longer be used for ordering, and thus for initial substring nor sorted requests.

Example of command to enable data confidentiality for the userRoot backend:

dsconfig set-backend-prop \
 -h opendj.example.com -p 4444 \
 -D "cn=Directory Manager" -w secret12 -n -X \
 --backend-name userRoot --set confidentiality-enabled:true

Data confidentiality is a dynamic feature, and can be enabled, disabled without stopping the server. When enabling on a backend, only the updated or created entries will be encrypted. If there is existing data that need confidentiality, it is better to export and reimport the data. With indexes data confidentiality, the behaviour is different. When changing the data confidentiality on an index, you must rebuild the index before it can be used with search requests.

Key Management - Photo adapted from https://www.flickr.com/people/ecossystems/

When enabling data confidentiality, you can select the cipher algorithm and the key length, and again this can be per database backend. The encryption key itself is generated on the server itself and securely distributed to all replicated servers through the replication of the Admin Backend (“cn=admin data”), and thus it’s never exposed to any administrator. Should a key get compromised, we provide a way to mark it so and generate a new key. Also, a backup of an encrypted database backend can be restored on any server with the same configuration, as long as the server still has its configuration and its Admin backend intact. Restoring such backend backup to fresh new server requires that it’s configured for replication first.

The Data Confidentiality feature can be tested with the OpenDJ nightly builds. It is also available to ForgeRock customers as part of our latest update of the ForgeRock Identity Platform.

OpenDJ LDAP Directory Services update

FR_plogo_org_FC_openDJ-300x86The new version of ForgeRock Directory Services, based on OpenDJ 3.0, was released in January and I’ve already written about the new features here, here and here.

We’ve now started the development of the next releases. We’ve updated the high level roadmap on our wiki, to give you an idea of what’s coming.

The last few weeks have been very active, as you can see on our JIRA dashboard.

Screen Shot 2016-03-18 at 10.56.12

There are already a few new features and enhancements in the master branch of our GIT repository :

A Bcrypt password storage scheme. The new scheme is meant to help migration of user accounts from other systems, without requiring a password reset. Bcrypt also provide a much stronger level of security for hashing passwords, as it’s number of iteration is configurable. But since OpenDJ 2.6, we are already providing a PBKDF2 password storage scheme which is recommended over Bcrypt by OWASP, for securing passwords.

Some enhancements of our performance testing tools, part of the OpenDJ LDAP Toolkit. All xxxxrate tools have a new way of computing statistics, providing more reliable and consistent results while reducing the overhead of producing them.

Some performance enhancements in various areas, including replication, group management, overall requests processing…

If you want to see it by yourself, you can checkout the code from our GIT repository, and build it, or you can grab the latest nightly build.

Play with OpenDJ and let us know how it works for you.

What’s new in OpenDJ 3.0, Part III

FR_plogo_org_FC_openDJ-300x86In the previous posts, I talked about the new PDB Backend in OpenDJ 3.0, and the other changes with backends, replication and the changelog.

In this last article about OpenDJ 3.0, I’m presenting the most important new features and enhancements in this major release:

Certificate Matching Rules.

OpenDJ now implements the CertificateExactMatch matching rule in compliance with “Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates” (RFC 4523) and implements the schema and the syntax for certificates, certificate lists  and certificate pairs.

It’s now possible to search a directory to find an entry with a specific certificate, using a filter such as below:

(userCertificate={ serialNumber 13233831500277100508, issuer rdnSequence:"CN=Babs Jensen,OU=Product Development,L=Cupertino,C=US" })

Password Storage Schemes

The PKCS5S2 Password Storage Scheme has been added to the list of supported storage schemes. While this one is less secure and flexible than PBKDF2, it allows some of our customers to migrate from systems that use the PKCS5S2 algorithm. Other password storage schemes have been enhanced to support arbitrary salt length and thus helping with other migrations (without requiring all users to have a new password).

Disk Space Monitoring.

In previous releases, each backend had a disk space monitoring function, regardless of the filesystems or disks used. In OpenDJ 3.0, we’ve created a disk space monitoring service, and backends, replication, log services register to it. This allows the server to optimise its resource consumption to monitor, as well as ensuring that all disks that contain writable data are monitored, and alerts raised when reaching some low threshold.

Improvements

There are many improvements in many areas of the server: in the REST to LDAP services and gateway, optimisations on indexes, dsconfig batch mode, DSML Gateway supporting SOAP 1.2, native packages… For the complete details, please read the Release Notes.

As always, the best way to really see and feel the difference is by downloading and installing the OpenDJ server, and playing with it. We’re providing a Zip installation, an RPM and a Debian Package, the DSML Gateway and the REST to LDAP Gateway as war files.

Over the course of the development of OpenDJ 3.0, we’ve received many contributions, in form of code, issues raised in our JIRA, documentation… We address our deepest thanks to all the contributors and developers :

Andrea Stani, Auke Schrijnen, Ayami Tyndal, Brad Tumy, Bruno Lavit, Bernhard Thalmayr, Carole Forel, Chris Clifton, Chris Drake, Chris Ridd, Christian Ohr, Christophe Sovant, Cyril Grosjean, Darin Perusich, David Goldsmith, Dennis Demarco, Edan Idzerda, Emidio Stani, Fabio Pistolesi, Gaétan Boismal, Gary Williams, Gene Hirayama, Hakon Steinø, Ian Packer, Jaak Pruulmann-Vengerfeldt, James Phillpotts, Jeff Blaine, Jean-Noël Rouvignac, Jens Elkner, Jonathan Thomas, Kevin Fahy, Lana Frost, Lee Trujillo, Li Run, Ludovic Poitou, Manuel Gaupp, Mark Craig, Mark De Reeper, Markus Schulz, Matthew Swift, Matt Miller, Muzzol Oliba, Nicolas Capponi, Nicolas Labrot, Ondrej Fuchsik, Patrick Diligent, Peter Major, Quentin Cassel, Richard Kolb, Robert Wapshott, Sébastien Bertholet, Shariq Faruqi, Stein Myrseth, Sunil Raju, Tomasz Jędrzejewski, Travis Papp, Tsoi Hong, Violette Roche-Montané, Wajih Ahmed, Warren Strange, Yannick Lecaillez. (I’m sorry if I missed anyone…)

OpenDJ 3.0.0 has been released…

FR_plogo_org_FC_openDJ-300x86As part of the release of the ForgeRock Identity Platform that we did last week, we’ve released a major version of our Directory Services product : OpenDJ 3.0.0.

The main and most important change in OpenDJ 3.0 is the work on the backend layer, with the introduction of a new backend database, supported by a new low level key-value store. When installing a new instance of OpenDJ, administrators now have the choice of creating a JE Backend (which is based on Berkeley DB Java Edition, as with previous releases of OpenDJ), or a PDB Backend (which is based on the new PersistIt library). When upgrading, the existing local backends will be transparently upgraded in JE Backends, but indexes will need to be rebuilt (and can be rebuilt automatically during the upgrade process).

Both backends have the same capabilities, and very similar performances. Most importantly, both backends benefit from a number of improvements compared with previous releases : the size of databases and index records are smaller, some indexes have been reworked to deliver better performances both for updates and reads. Overall, we’ve been increasing the throughput of Adding/Deleting entries in OpenDJ by more than 15 %.

But the 2 backends are different, especially in the way they deal with database compression. Because of the way it’s dealing with journals and compression, the new PDB backend may deliver better overall throughput, but may increase its disk occupancy significantly under heavy load (it favours updates over compression). Once the throughput is reduced under a certain threshold, compression will be highly effective and the overall disk occupancy will be optimised.

A question I often get is “Which backend should I use? “. And I don’t have a definitive answer. If you have an OpenDJ instance and you’re upgrading to 3.0, keep the JE Backend. This is a simple and automated upgrade. If you’re installing a new instance of OpenDJ, then I would say it’s a matter of risks. We don’t have the same wide experience with the PDB backend than we have had with the JE backend over the last 10 years. So, if you want to be really safe, chose the JE Backend. If you have time to test, stage your directory service before putting it in production, you might want to go with the PDB Backend. As, moving forward, we will focus our performance testing and improvements on the PDB backend essentially.

That’s all for now. In a followup post, I will continue to review the changes in OpenDJ 3.0…

Meanwhile, you can download OpenDJ 3.0 from ForgeRock’s BackStage and start playing with it. And check the Release Notes for more information.

PS: The followup posts have been published:

OpenDJ Nightly Builds…

For the last few months, there’s been a lot of changes in the OpenDJ project in order to prepare the next major release : OpenDJ 3.0.0. While doing so, we’ve tried to keep options opened and continued to make most of the changes in the trunk/opends part, keeping the possibility to release a 2.8 version. And we’ve made tons of work in branches as well as in trunk/opendj. As part of the move to the trunk, we’ve changed the factory to now build with Maven. Finally, at the end of last week, we’ve made the switch on the nightly builds and are now building what will be OpenDJ 3, from the trunk.

For those who are regularly checking the nightly builds, the biggest change is going to be the version number. The new build is now showing a development version of 3.0.

$ start-ds -V
OpenDJ 3.0.0-SNAPSHOT
Build 20150506012828
--
 Name Build number Revision number
Extension: snmp-mib2605 3.0.0-SNAPSHOT 12206

We are still missing the MSI package (sorry to the Windows users, we are trying to find the Maven plugin that will allow us to build the package in a similar way as previously with ant), and we are also looking at restoring the JNLP based installer, but otherwise OpenDJ 3 nightly builds are available for testing, in different forms : Zip, RPM and Debian packages.

OpenDJ Nightly Builds at ForgeRock.org

We have also changed the minimal version of Java required to run the OpenDJ LDAP directory server. Java 7 or higher is required.

We’re looking forward to getting your feedback.

Why I love my job !

At ForgeRock, I have multiple reasons to enjoy what I do. I have the responsibility for two products: OpenDJ, the LDAP directory services and OpenIG the Identity Gateway, and I also manages the French subsidiary. But what really gets me excited in the morning is that I get to work with very smart and passionate people!

Jean-Noël, one of the engineers of the OpenDJ development team, has a passion for beautiful code and AlpesJuggyTranshe loves refactoring, cleaning existing code. On his personal time, he started to automate his process in Eclipse, and then turn it into an Eclipse plugin, and finally made the code available as an open source project: AutoRefactor. Now, in the office, most of the engineers using Eclipse are also using the AutoRefactor plugin.

So when Jean-Noël got to present his work at our local Java User Group (the AlpesJUG), the rest of the team went along and supported him. As one of the other engineers has a passion for photography (which I share), it gives this amazing picture gallery and set of souvenirs for everyone:

AutoRefactor Session at the AlpesJUG (Feb 24, 2015)
Photos by Bruno Lavit – Click to go to the picture gallery

PS: It also helps that we are working in a great environment where we can afford to do this⬇︎ (sometime to time) during our lunch break!

FondChamrousse

OpenDJ on Windows…

OpenDJ LogoOpenDJ, the LDAP directory services in Java, is supported on multiple platforms and has been for many years. We’re testing on Linux, Windows, Solaris, Mac OS X, but also different JVMs: Oracle JRE, OpenJDK, Azul Zulu, IBM JVM…

With OpenDJ 2.6, we’ve made it easier for people to install it on Linux machines by providing RPM and Debian packages.

We are now also providing a MSI package to ease the installation and removal on Windows machines. The MSI package is available for nightly builds here.

OpenDJ MSI InstallerScreen Shot 2015-01-28 at 09.14.01

About LDAP Syntaxes and backward compatibility…

In the LDAP information model, a syntax constrains the structure and format of attribute values. OpenDJ defines and implements a large number of syntaxes (you can discover them by reading the ldapSyntaxes attribute from the cn=Schema entry).

But infrequently, we receive enquiries on an obscure and non standard syntax, often in the form of “I’m having an error importing schema from this or that legacy directory server”, with an error message that ends with “No such syntax is configured for use in the Directory Server”.

As syntaxes are constraining the structure and format of attribute values, they are implemented as code, specifically Java code in OpenDJ. It’s possible to implement new syntaxes by implementing the org.opends.server.api.AttributeSyntax abstract class, and installing the classes or the JAR in OpenDJ classpath. But often, it’s easier and more convenient to define a syntax by configuration, and OpenDJ offers 3 possibilities to define new syntaxes. In term of backward compatibility, I will only focus on the 2 main ones, by substitution and by pattern (the 3rd one allows to define enumeration of values).

With OpenDJ, you can define a new syntax by configuration and delegating the contraints to an already implemented syntax. A simple example is the URI syntax (which was defined is some very old schema with the OID  1.3.6.1.4.1.4401.1.1.1). A URI is really an ASCII string, and it might be sufficient to accept attributes with URI syntax to verify that all characters are pure ASCII. The standard syntax for ASCII strings is IA5String aka 1.3.6.1.4.1.1466.115.121.1.15.

ldapSyntaxes: ( 1.3.6.1.4.1.4401.1.1.1 DESC ‘URI’ X-SUBST ‘1.3.6.1.4.1.1466.115.121.1.15’ )

Insert the above line in the schema LDIF file before the attributeTypes, and you’re done.

The other option is to define the syntax as a pattern, using regular expressions. This could be better when willing to enforce additional constraints on an URI, for example, verifying that the URI is an LDAP one.

ldapSyntaxes: ( 999.999.999.1 DESC 'LDAP URI Syntax' X-PATTERN '^ldap://[-a-zA-Z0-9+&@#/%?=~_|!:,.;]*[-a-zA-Z0-9+&@#/%=~_|]' )

So the next time you are trying to import some legacy schema to the OpenDJ directory server, and you have an error due to missing syntaxes, you know what to do to quickly resolve the problem.

OpenDJ Contact Manager for Android

With OpenDJ 2.6.0, we’ve introduced a new way to access your directory data, using HTTP, REST and JSon. The REST to LDAP service, available either embedded in the OpenDJ server or as a standalone web application, is designed to facilitate the work of application developers. And to demonstrate the interest and the ease of use of that service, we’ve built a sample application for Android : the OpenDJ Contact Manager

OpenDJ Contact Manager Android AppAbout screen of the OpenDJ Contact Manager Android App

The OpenDJ Contact Manager is an open source Android application that was built by Violette, one of the ForgeRock engineer working in the OpenDJ team. You can get the source code from the SVN repository : https://svn.forgerock.org/commons/mobile/contact-manager/trunk. Mark wrote some quite complete documentation for the project, with details on how to get and build the application. He published it at http://commons.forgerock.org/mobile/contact-manager/.

The whole application is just about 4000 lines of code, and most of it is dealing with the display itself. But you can find code that deals with asynchronous calls to the OpenDJ rest interface, with paging through results, and parsing the resulting JSON stream to populate the Contacts, including photos. Et voila :

OpenDJ Contact Manager displaying a Contact

The application is just a sample but it clearly is usable in its current form and will allow once a contact was retrieved from the OpenDJ directory, to add it to the Contacts standard application, call the person, locate its address on maps, send the person an email, navigate through the management chain…

In future versions, we are planning to add support for OAuth 2.0, removing the need to store credentials in the application settings.

As it’s open source, feel free to play with it, hack and contribute back your changes.

Updates to opendj-utils

About a year ago, I’ve introduced a set of OpenDJ scripts and utilities that I’ve built to facilitate my work with OpenDJ.

Last week, I’ve pushed some updates to the github repository.

The first improvements are in logstat.py. I’ve added support for collecting stats about the Abandon operation, as well as some counting and reports on the errors to each operation. This allows to get a feel of how many operations failed and the error code reported.

The second update is a new utility names filterstat.py which scans through access log files and builds a sorted list of all filters used in search requests. The filters are generalized and collated together, and the result should help administrators to understand which attributes should be indexed and what kind of index are required.

Here’s a sample output of filterstat (based on an instance of OpenDJ used by OpenAM). The first value is the count and the string is the generic representation of the filter:

$ ~/opendj-utils/filterstat.py access
processing file: access
213783 (&(uid=VALUE)(objectclass=VALUE))
2080 (&(|(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE))(|(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE))(|(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE)))
807 (&(objectclass=VALUE)(uniqueMember=VALUE))
244 (&(cn=VALUE)(objectclass=VALUE))
213 (&(&(uid=VALUE)(objectclass=VALUE)))
140 (&(|(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE))(|(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE))(|(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE)))
63 (&(|(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE))(|(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE))(|(sunxmlKeyValue=VALUE)(sunxmlKeyValue=VALUE)))
39 (&(&(cn=VALUE)(objectclass=VALUE)))
6 (&(uid=*SUBSTRING*)(objectclass=VALUE))
2 (&(objectclass=VALUE)(ou=VALUE))
1 (&(&(uid=*)(objectclass=VALUE))(|(uid=VALUE)))
Base search filters only:
2487 (|(objectclass=*)(objectclass=VALUE))
Done

Please give those tools a try and let me know how useful they are for you. And if you have ideas on how to improve them, feel free to fork them and contribute.

OpenDJ is Java 8 ready…

Java 8 CompatibleA few weeks ago, I came upon the Adopt openjdk program, launched by the London Java User Group. I’ve decided to give it a try and for that to leverage the Dev@Cloud and FOSS program from CloudBees.

While building OpenDJ I hit a roadblock : XJC is defective with OpenJDK 8 and prevents us from building the DSML gateway that is part of the OpenDJ project. It’s only recently when the openjdk bug database was made publicly available that I found it was a known P1 issue, yet still not resolved.

Recently someone filed a bug against OpenDJ for failing with openjdk 8, so we paid more attention, found the cause of the failure and fixed it. And now OpenDJ directory server is working fine on openjdk 8. We are keeping an automatic build and test with openjdk8 (*) to make sure things will work when Java 8 is released.

Next steps will be to verify that OpenDJ still works with the beta version of jdk8 of IBM Java virtual machine.


* If you’re not familiar with OpenDJ nightly tests, do not try to interpret the results out there. Some of those complex replication tests are unfortunately sensitive to processor speed, thread timing and synchronization.So they tend to fail often on single CPU virtual machines where resources are unknown. They are fully passing on 2 or more CPU machines.

OpenDJ : Visualizing the Replication Topology

My coworker Chris Ridd has spent a little bit of spare time writing a small utility that can parse the output of OpenDJ monitoring information to extract the details of the replication topology. Give the output to some graphical tool and here’s the result (based on one of our biggest customer -anonymized- data) :

ReplTopo

This is a worldwide deployment with many directory services in 4 regions and 8 replication services fully connected. Each directory service is connected to a single replication server, but can failover in matter of seconds, by priority in the same region.

If you want to give it a try on your own replication topology, it’s simple. The tool is open source and part of the OpenDJ utilities that Chris has pushed to GitHub. Just feed it with the output of ldapsearch on cn=monitor.

OpenDJ 2.6.0 is now available

OpenDJ-300x100I am really happy to announce the general availability of OpenDJ 2.6.0, a major update of ForgeRock  directory service product, built from the tag 2.6.0 (revision 9086 in our SVN repository).

OpenDJ 2.6.0 brings a lot of added value, including :

– A REST to LDAP service, allowing an easy access to directory data using HTTP/JSON. The service can be run either embedded in the server or as a standalone web application.

– A new upgrade process to ease transition from OpenDJ 2.4.5 or newer to 2.6.

– New Linux native packages (RPM and Debian) to facilitate the automatic deployment of OpenDJ in the private and public cloud.

– OpenDJ can be configured to delegate authentication to a Microsoft Active Directory service, providing tighter integration with Microsoft environment without the burden of synchronizing passwords.

– An optional extension to remove specific attributes from updates, making it more flexible and easier to deal with legacy applications and migration tasks.

– A way to synchronize SAMBA password attributes with the user’s password.

– Some improvements on the integrity of references, that is now enforced at creation or on update.

– More flexible and efficient audit logs.

– A Java based LDAP software development kit.

– An official stable documentation.

For the complete list of new features, enhancements and fixed defects, please read the release notes.

The binaries can be downloaded from ForgeRock Downloads.

Over the course of the development of OpenDJ, we’ve received many contributions, in form of code, issues raised in our JIRA, documentation… We address our deepest thanks to all the contributors and developers :

Aiman Tahboub, Alan Evans, Arturo V Sanchez, Auke Schrijnen, Bernhard Thalmayr, Brent Palmer, Bruno Vernay, Chris Dowey, Chris Ridd, Christophe Sovant, Dan Gardner, Danny Turner, Darin Perusich, Donal Duane, Elliot Kendall, Eswar Moorthy, Fred Voss, Gael Allioux, Gary Williams, German Parente, Göran Odmyr, Ian McGlothlin, Jamie Nelson, Jean-Noël Rouvignac, Jeff Blaine, Jeffrey Crawford, Jens Elkner, Lana Frost, Laurent Bristiel, Ludovic Poitou, Manuel Gaupp, Manuel Schallar, Mark Craig, Mark Gibson, Marko Harjula, Martin Sperle, Matthew Stevenson, Matthew Swift, Miroslav Fadrhonc, Mitch Silverstein, Nemanja Lukić, Nicholas Sushkin , Nikolay Belaevski, Per-Olov Sjoholm, Peter Major, Rauli Ikonen, Sachiko Wallace, Slavomir Katuscak, Tomas Forsman, Vanessa Richie, Violette Roche, Willi Burmeister

Happy 4th of July everyone !