Nasqueron Agora - User contributions [en]

User:MoustaphaAs

2024-11-29T11:21:38Z

MoustaphaAs: /* Useful Links */

= Keycloak =
Keycloak is an open-source identity and access management solution designed for modern applications and services. It provides centralized authentication and authorization, enabling Single Sign-On (SSO), identity brokering, and social login integration. With support for both OAuth2.0 and OpenID Connect protocols, Keycloak simplifies security management by handling user authentication, session management, and access control. Whether you're building cloud-native applications or integrating legacy systems, Keycloak offers a scalable, flexible, and secure solution for managing user identities and permissions across a wide range of platforms.

== Keycloak Puzzle Pieces ==

Keycloak is built on several key components, each playing a crucial role in identity and access management. Below is a breakdown of these "puzzle pieces" and their functions:

'''Realm'''
is an isolated space used to manage a group of users, applications, and security configurations. Realms allow you to separate data and configurations, making them ideal for multi-tenant environments.

'''Clients'''
are applications or services that use Keycloak for authentication and authorization. Each client can have its own security settings, such as authentication types and specific roles.

'''Users'''
are entities who log in to your applications. Keycloak manages user information, including credentials, roles, and groups.
What properties are available for users? (e.g., first name, last name, email, etc.)

'''Roles'''
are sets of permissions assigned to users or groups. They help control access to resources in a granular way.
How to authenticate users on servers? (e.g., using username/password, multi-factor authentication, etc.)

'''Groups'''
are a way to organize users. Groups can have associated roles, simplifying the management of permissions for a set of users.

'''Authentication Protocols,'''
Keycloak supports various authentication protocols, including OpenID Connect and SAML. This allows integration with a wide range of services and applications.
What should be the multi-factor authentication policy? (e.g., SMS, authenticator apps, etc.)

'''Authentication and Flows,'''
Keycloak allows you to define custom authentication flows, including steps like password validation, multi-factor authentication, and more.

'''Identity Brokering,'''
This feature allows Keycloak to act as an intermediary for other identity providers, enabling users to log in with third-party accounts (e.g., Google, Facebook, etc.).

'''Admin Console'''
is a web interface used to manage users, clients, roles, and security configurations in Keycloak. It is the primary tool for administrators.

'''REST API,'''
Keycloak provides a REST API to interact with the server, allowing integration with other systems and automation of administrative tasks.

'''Extensions and SPI (Service Provider Interfaces),'''
Keycloak allows customizations via extensions and service provider interfaces (SPIs), enabling the development of additional functionality tailored to specific needs.

== Keycloak Deployment Methods ==

Below are different methods for deploying Keycloak, along with their advantages, disadvantages, and ideal use cases:

{| class="wikitable"
! Deployment Method !! Description !! Advantages !! Disadvantages !! Ideal For
|-
| OpenJDK || This method involves installing Keycloak directly on bare metal using OpenJDK. It requires manual installation and dependency management. || Full control over configuration, optimized performance. || More complex setup, requires manual updates and security management. || Environments where full control is necessary or for specific deployments.
|-
| Docker || Uses Docker containers to deploy Keycloak. This simplifies the installation process and isolates the application. || Easy deployment, portability, simplified dependency management. || May require knowledge of containerization and Docker management. || Developers or teams looking for a fast, portable solution.
|-
| Podman || Similar to Docker, but Podman allows managing containers without a daemon. It is an alternative to Docker with a daemon-less architecture. || Daemon-less container management, better default security. || Less documentation and community support compared to Docker. || Users who prioritize security and wish to avoid using a daemon.
|-
| Kubernetes || Deploys Keycloak in a Kubernetes cluster, enabling advanced container orchestration. || Scalability, high availability, automated container management. || Increased complexity, requires in-depth Kubernetes knowledge. || Enterprises with high availability and scalability needs.
|-
| OpenShift || An enterprise-level Kubernetes platform that simplifies deployment and management of containerized applications. || Integrated tools for application management, enhanced security, CI/CD support. || Requires a license, more complex for novice users. || Enterprises already using OpenShift or looking for a robust, integrated solution.
|-
| Scaling || Focuses on optimizing Keycloak for scalability and performance tuning. || Improved performance, ability to handle large numbers of users. || Requires understanding of scalability best practices. || Large-scale deployments or environments with high performance needs.
|}

== Keycloak Database Types ==

Below are different types of databases that can be used with Keycloak, including their advantages, disadvantages, and ideal use cases:

{| class="wikitable"
! Database Type !! Description !! Advantages !! Disadvantages !! Ideal For
|-
| Relational Database (PostgreSQL, MySQL) || Keycloak is designed to work with relational databases, making configuration easier. || Native support, excellent transaction management, data integrity through constraints and relationships. || Vertical scalability, requires hardware upgrades for increased load, active administrative management required. || Environments that require strong data integrity and security, with manageable scalability.
|-
| NoSQL Database (MongoDB, Cassandra) || NoSQL databases provide flexible data models and are ideal for large, evolving data sets. || Horizontal scalability, flexible data models, great for large-scale data. || Limited native support in Keycloak, integration may require additional work. || Projects with large, dynamic datasets, where scalability is a priority.
|-
| Hosted Database (Amazon RDS, Azure Database) || Cloud providers manage the infrastructure, backups, and updates. || Simplified management, high availability, disaster recovery options. || Higher long-term costs, dependency on cloud service provider availability and performance. || Businesses seeking ease of management with high availability and disaster recovery capabilities.
|-
| Containerized Database (PostgreSQL in Docker) || Running the database in a container (e.g., Docker) for easy deployment and movement. || Portability, isolation from host system for improved security. || Persistent data management, requires proper volume configuration to avoid data loss when containers are removed. || Teams that need portability and isolation with containerized environments.
|-
| On-Premises Database || Managing the database directly on-site. || Full control over configuration and security, optimized performance. || Intensive management required, including maintenance, updates, and backups, fixed infrastructure costs. || Organizations with technical expertise, and those needing full control over their database.
|-
| Distributed Database (Cassandra) || A distributed database system designed for massive, scalable workloads. || High availability, designed to operate without interruptions, suitable for critical applications. || Difficult integration with Keycloak, lacks native support, fewer transaction features. || Large-scale deployments requiring high availability and scalability.
|-
| In-Memory Database (Redis) || A fast, in-memory database for applications needing low-latency data access. || Extremely fast data access, ideal for low-latency requirements. || Data persistence is not guaranteed, not suitable for critical data, limited support for Keycloak. || Applications that require very fast access to data and can tolerate the lack of persistence.
|}

== How to Build an LDAP Schema ==

Here are the steps to construct an LDAP schema:

'''1. Understand Basic Concepts'''
Familiarize yourself with **ObjectClasses** and **Attributes**. Each entry in an LDAP directory must be associated with at least one ObjectClass, which defines the type of entry (e.g., user, group).

'''2. Define ObjectClasses'''
Create ObjectClasses that represent the types of entries you wish to store. For example, an ObjectClass for users might include attributes such as `cn` (common name) and `mail` (email address).

'''3. Define Attributes'''
Define the attributes that each ObjectClass can have. Each attribute must have a name, a syntax, and can be marked as required (`MUST`) or optional (`MAY`).

'''4. Create the Schema File'''
Gather all the definitions of ObjectClasses and attributes into an LDIF file. This file will contain all the information necessary to add your schema to an LDAP server.

'''5. Add the Schema to OpenLDAP'''
Use the `ldapadd` command to add the schema to your OpenLDAP server. Make sure to use the correct options for authentication and the path to the LDIF file.

'''6. Test the Schema'''
After adding the schema, test it by adding entries that use the new ObjectClasses and attributes. Verify that the LDAP server accepts the new entries and that the validations are working properly.

'''7. Maintain and Evolve the Schema'''
As your needs change, you may need to update your schema. This may include adding new attributes or ObjectClasses.

== Useful Links ==

* [Create a new LDAP client schema - NetApp](https://docs.netapp.com/fr-fr/ontap/nfs-config/create-new-ldap-client-schema-task.html) - Guide on how to create a new LDAP client schema for NetApp.
* [LDAP Tutorial - INRIA](https://www-sop.inria.fr/members/Laurent.Mirtain/ldap-livre.html) - Comprehensive LDAP tutorial from INRIA.
* [Add a specific schema - Vincent Liefooghe](https://www.vincentliefooghe.net/content/ajouter-un-sch%C3%A9ma-sp%C3%A9fique) - Instructions for adding a specific LDAP schema by Vincent Liefooghe.
* [Keycloak Documentation](https://www.keycloak.org/documentation) - Official Keycloak documentation, providing extensive resources on setup, configuration, and usage.
* [Keycloak GitHub Repository](https://github.com/keycloak/keycloak) - Keycloak's official GitHub repository, with the source code, release notes, and community contributions.
* [Keycloak Community Forum](https://www.keycloak.org/community) - Join discussions, ask questions, and find support from the Keycloak community.
* [Keycloak Quickstarts](https://www.keycloak.org/guides) - Keycloak's official quickstart guides to help you get up and running quickly with different deployment scenarios.

User:MoustaphaAs

2024-11-29T11:20:24Z

MoustaphaAs:

= Keycloak =
Keycloak is an open-source identity and access management solution designed for modern applications and services. It provides centralized authentication and authorization, enabling Single Sign-On (SSO), identity brokering, and social login integration. With support for both OAuth2.0 and OpenID Connect protocols, Keycloak simplifies security management by handling user authentication, session management, and access control. Whether you're building cloud-native applications or integrating legacy systems, Keycloak offers a scalable, flexible, and secure solution for managing user identities and permissions across a wide range of platforms.

== Keycloak Puzzle Pieces ==

Keycloak is built on several key components, each playing a crucial role in identity and access management. Below is a breakdown of these "puzzle pieces" and their functions:

'''Realm'''
is an isolated space used to manage a group of users, applications, and security configurations. Realms allow you to separate data and configurations, making them ideal for multi-tenant environments.

'''Clients'''
are applications or services that use Keycloak for authentication and authorization. Each client can have its own security settings, such as authentication types and specific roles.

'''Users'''
are entities who log in to your applications. Keycloak manages user information, including credentials, roles, and groups.
What properties are available for users? (e.g., first name, last name, email, etc.)

'''Roles'''
are sets of permissions assigned to users or groups. They help control access to resources in a granular way.
How to authenticate users on servers? (e.g., using username/password, multi-factor authentication, etc.)

'''Groups'''
are a way to organize users. Groups can have associated roles, simplifying the management of permissions for a set of users.

'''Authentication Protocols,'''
Keycloak supports various authentication protocols, including OpenID Connect and SAML. This allows integration with a wide range of services and applications.
What should be the multi-factor authentication policy? (e.g., SMS, authenticator apps, etc.)

'''Authentication and Flows,'''
Keycloak allows you to define custom authentication flows, including steps like password validation, multi-factor authentication, and more.

'''Identity Brokering,'''
This feature allows Keycloak to act as an intermediary for other identity providers, enabling users to log in with third-party accounts (e.g., Google, Facebook, etc.).

'''Admin Console'''
is a web interface used to manage users, clients, roles, and security configurations in Keycloak. It is the primary tool for administrators.

'''REST API,'''
Keycloak provides a REST API to interact with the server, allowing integration with other systems and automation of administrative tasks.

'''Extensions and SPI (Service Provider Interfaces),'''
Keycloak allows customizations via extensions and service provider interfaces (SPIs), enabling the development of additional functionality tailored to specific needs.

== Keycloak Deployment Methods ==

Below are different methods for deploying Keycloak, along with their advantages, disadvantages, and ideal use cases:

{| class="wikitable"
! Deployment Method !! Description !! Advantages !! Disadvantages !! Ideal For
|-
| OpenJDK || This method involves installing Keycloak directly on bare metal using OpenJDK. It requires manual installation and dependency management. || Full control over configuration, optimized performance. || More complex setup, requires manual updates and security management. || Environments where full control is necessary or for specific deployments.
|-
| Docker || Uses Docker containers to deploy Keycloak. This simplifies the installation process and isolates the application. || Easy deployment, portability, simplified dependency management. || May require knowledge of containerization and Docker management. || Developers or teams looking for a fast, portable solution.
|-
| Podman || Similar to Docker, but Podman allows managing containers without a daemon. It is an alternative to Docker with a daemon-less architecture. || Daemon-less container management, better default security. || Less documentation and community support compared to Docker. || Users who prioritize security and wish to avoid using a daemon.
|-
| Kubernetes || Deploys Keycloak in a Kubernetes cluster, enabling advanced container orchestration. || Scalability, high availability, automated container management. || Increased complexity, requires in-depth Kubernetes knowledge. || Enterprises with high availability and scalability needs.
|-
| OpenShift || An enterprise-level Kubernetes platform that simplifies deployment and management of containerized applications. || Integrated tools for application management, enhanced security, CI/CD support. || Requires a license, more complex for novice users. || Enterprises already using OpenShift or looking for a robust, integrated solution.
|-
| Scaling || Focuses on optimizing Keycloak for scalability and performance tuning. || Improved performance, ability to handle large numbers of users. || Requires understanding of scalability best practices. || Large-scale deployments or environments with high performance needs.
|}

== Keycloak Database Types ==

Below are different types of databases that can be used with Keycloak, including their advantages, disadvantages, and ideal use cases:

{| class="wikitable"
! Database Type !! Description !! Advantages !! Disadvantages !! Ideal For
|-
| Relational Database (PostgreSQL, MySQL) || Keycloak is designed to work with relational databases, making configuration easier. || Native support, excellent transaction management, data integrity through constraints and relationships. || Vertical scalability, requires hardware upgrades for increased load, active administrative management required. || Environments that require strong data integrity and security, with manageable scalability.
|-
| NoSQL Database (MongoDB, Cassandra) || NoSQL databases provide flexible data models and are ideal for large, evolving data sets. || Horizontal scalability, flexible data models, great for large-scale data. || Limited native support in Keycloak, integration may require additional work. || Projects with large, dynamic datasets, where scalability is a priority.
|-
| Hosted Database (Amazon RDS, Azure Database) || Cloud providers manage the infrastructure, backups, and updates. || Simplified management, high availability, disaster recovery options. || Higher long-term costs, dependency on cloud service provider availability and performance. || Businesses seeking ease of management with high availability and disaster recovery capabilities.
|-
| Containerized Database (PostgreSQL in Docker) || Running the database in a container (e.g., Docker) for easy deployment and movement. || Portability, isolation from host system for improved security. || Persistent data management, requires proper volume configuration to avoid data loss when containers are removed. || Teams that need portability and isolation with containerized environments.
|-
| On-Premises Database || Managing the database directly on-site. || Full control over configuration and security, optimized performance. || Intensive management required, including maintenance, updates, and backups, fixed infrastructure costs. || Organizations with technical expertise, and those needing full control over their database.
|-
| Distributed Database (Cassandra) || A distributed database system designed for massive, scalable workloads. || High availability, designed to operate without interruptions, suitable for critical applications. || Difficult integration with Keycloak, lacks native support, fewer transaction features. || Large-scale deployments requiring high availability and scalability.
|-
| In-Memory Database (Redis) || A fast, in-memory database for applications needing low-latency data access. || Extremely fast data access, ideal for low-latency requirements. || Data persistence is not guaranteed, not suitable for critical data, limited support for Keycloak. || Applications that require very fast access to data and can tolerate the lack of persistence.
|}

== How to Build an LDAP Schema ==

Here are the steps to construct an LDAP schema:

'''1. Understand Basic Concepts'''
Familiarize yourself with **ObjectClasses** and **Attributes**. Each entry in an LDAP directory must be associated with at least one ObjectClass, which defines the type of entry (e.g., user, group).

'''2. Define ObjectClasses'''
Create ObjectClasses that represent the types of entries you wish to store. For example, an ObjectClass for users might include attributes such as `cn` (common name) and `mail` (email address).

'''3. Define Attributes'''
Define the attributes that each ObjectClass can have. Each attribute must have a name, a syntax, and can be marked as required (`MUST`) or optional (`MAY`).

'''4. Create the Schema File'''
Gather all the definitions of ObjectClasses and attributes into an LDIF file. This file will contain all the information necessary to add your schema to an LDAP server.

'''5. Add the Schema to OpenLDAP'''
Use the `ldapadd` command to add the schema to your OpenLDAP server. Make sure to use the correct options for authentication and the path to the LDIF file.

'''6. Test the Schema'''
After adding the schema, test it by adding entries that use the new ObjectClasses and attributes. Verify that the LDAP server accepts the new entries and that the validations are working properly.

'''7. Maintain and Evolve the Schema'''
As your needs change, you may need to update your schema. This may include adding new attributes or ObjectClasses.

== Useful Links ==

* [Create a new LDAP client schema - NetApp](https://docs.netapp.com/fr-fr/ontap/nfs-config/create-new-ldap-client-schema-task.html) - Guide on how to create a new LDAP client schema for NetApp.
* [LDAP Tutorial - INRIA](https://www-sop.inria.fr/members/Laurent.Mirtain/ldap-livre.html) - Comprehensive LDAP tutorial from INRIA.
* [Add a specific schema - Vincent Liefooghe](https://www.vincentliefooghe.net/content/ajouter-un-sch%C3%A9ma-sp%C3%A9fique) - Instructions for adding a specific LDAP schema by Vincent Liefooghe.
* [Keycloak Documentation](https://www.keycloak.org/documentation) - Official Keycloak documentation, providing extensive resources on setup, configuration, and usage.
* [Keycloak GitHub Repository](https://github.com/keycloak/keycloak) - Keycloak's official GitHub repository, with the source code, release notes, and community contributions.
* [Keycloak Community Forum](https://www.keycloak.org/community) - Join discussions, ask questions, and find support from the Keycloak community.
* [Keycloak Quickstarts](https://www.keycloak.org/docs/latest/getting_started/#quickstarts) - Keycloak's official quickstart guides to help you get up and running quickly with different deployment scenarios.

User:MoustaphaAs

2024-11-29T11:17:02Z

MoustaphaAs:

= Keycloak =
Keycloak is an open-source identity and access management solution designed for modern applications and services. It provides centralized authentication and authorization, enabling Single Sign-On (SSO), identity brokering, and social login integration. With support for both OAuth2.0 and OpenID Connect protocols, Keycloak simplifies security management by handling user authentication, session management, and access control. Whether you're building cloud-native applications or integrating legacy systems, Keycloak offers a scalable, flexible, and secure solution for managing user identities and permissions across a wide range of platforms.

== Keycloak Puzzle Pieces ==

Keycloak is built on several key components, each playing a crucial role in identity and access management. Below is a breakdown of these "puzzle pieces" and their functions:

'''Realm'''
is an isolated space used to manage a group of users, applications, and security configurations. Realms allow you to separate data and configurations, making them ideal for multi-tenant environments.

'''Clients'''
are applications or services that use Keycloak for authentication and authorization. Each client can have its own security settings, such as authentication types and specific roles.

'''Users'''
are entities who log in to your applications. Keycloak manages user information, including credentials, roles, and groups.
What properties are available for users? (e.g., first name, last name, email, etc.)

'''Roles'''
are sets of permissions assigned to users or groups. They help control access to resources in a granular way.
How to authenticate users on servers? (e.g., using username/password, multi-factor authentication, etc.)

'''Groups'''
are a way to organize users. Groups can have associated roles, simplifying the management of permissions for a set of users.

'''Authentication Protocols,'''
Keycloak supports various authentication protocols, including OpenID Connect and SAML. This allows integration with a wide range of services and applications.
What should be the multi-factor authentication policy? (e.g., SMS, authenticator apps, etc.)

'''Authentication and Flows,'''
Keycloak allows you to define custom authentication flows, including steps like password validation, multi-factor authentication, and more.

'''Identity Brokering,'''
This feature allows Keycloak to act as an intermediary for other identity providers, enabling users to log in with third-party accounts (e.g., Google, Facebook, etc.).

'''Admin Console'''
is a web interface used to manage users, clients, roles, and security configurations in Keycloak. It is the primary tool for administrators.

'''REST API,'''
Keycloak provides a REST API to interact with the server, allowing integration with other systems and automation of administrative tasks.

'''Extensions and SPI (Service Provider Interfaces),'''
Keycloak allows customizations via extensions and service provider interfaces (SPIs), enabling the development of additional functionality tailored to specific needs.

== Keycloak Deployment Methods ==

Below are different methods for deploying Keycloak, along with their advantages, disadvantages, and ideal use cases:

{| class="wikitable"
! Deployment Method !! Description !! Advantages !! Disadvantages !! Ideal For
|-
| OpenJDK || This method involves installing Keycloak directly on bare metal using OpenJDK. It requires manual installation and dependency management. || Full control over configuration, optimized performance. || More complex setup, requires manual updates and security management. || Environments where full control is necessary or for specific deployments.
|-
| Docker || Uses Docker containers to deploy Keycloak. This simplifies the installation process and isolates the application. || Easy deployment, portability, simplified dependency management. || May require knowledge of containerization and Docker management. || Developers or teams looking for a fast, portable solution.
|-
| Podman || Similar to Docker, but Podman allows managing containers without a daemon. It is an alternative to Docker with a daemon-less architecture. || Daemon-less container management, better default security. || Less documentation and community support compared to Docker. || Users who prioritize security and wish to avoid using a daemon.
|-
| Kubernetes || Deploys Keycloak in a Kubernetes cluster, enabling advanced container orchestration. || Scalability, high availability, automated container management. || Increased complexity, requires in-depth Kubernetes knowledge. || Enterprises with high availability and scalability needs.
|-
| OpenShift || An enterprise-level Kubernetes platform that simplifies deployment and management of containerized applications. || Integrated tools for application management, enhanced security, CI/CD support. || Requires a license, more complex for novice users. || Enterprises already using OpenShift or looking for a robust, integrated solution.
|-
| Scaling || Focuses on optimizing Keycloak for scalability and performance tuning. || Improved performance, ability to handle large numbers of users. || Requires understanding of scalability best practices. || Large-scale deployments or environments with high performance needs.
|}

== Keycloak Database Types ==

Below are different types of databases that can be used with Keycloak, including their advantages, disadvantages, and ideal use cases:

{| class="wikitable"
! Database Type !! Description !! Advantages !! Disadvantages !! Ideal For
|-
| Relational Database (PostgreSQL, MySQL) || Keycloak is designed to work with relational databases, making configuration easier. || Native support, excellent transaction management, data integrity through constraints and relationships. || Vertical scalability, requires hardware upgrades for increased load, active administrative management required. || Environments that require strong data integrity and security, with manageable scalability.
|-
| NoSQL Database (MongoDB, Cassandra) || NoSQL databases provide flexible data models and are ideal for large, evolving data sets. || Horizontal scalability, flexible data models, great for large-scale data. || Limited native support in Keycloak, integration may require additional work. || Projects with large, dynamic datasets, where scalability is a priority.
|-
| Hosted Database (Amazon RDS, Azure Database) || Cloud providers manage the infrastructure, backups, and updates. || Simplified management, high availability, disaster recovery options. || Higher long-term costs, dependency on cloud service provider availability and performance. || Businesses seeking ease of management with high availability and disaster recovery capabilities.
|-
| Containerized Database (PostgreSQL in Docker) || Running the database in a container (e.g., Docker) for easy deployment and movement. || Portability, isolation from host system for improved security. || Persistent data management, requires proper volume configuration to avoid data loss when containers are removed. || Teams that need portability and isolation with containerized environments.
|-
| On-Premises Database || Managing the database directly on-site. || Full control over configuration and security, optimized performance. || Intensive management required, including maintenance, updates, and backups, fixed infrastructure costs. || Organizations with technical expertise, and those needing full control over their database.
|-
| Distributed Database (Cassandra) || A distributed database system designed for massive, scalable workloads. || High availability, designed to operate without interruptions, suitable for critical applications. || Difficult integration with Keycloak, lacks native support, fewer transaction features. || Large-scale deployments requiring high availability and scalability.
|-
| In-Memory Database (Redis) || A fast, in-memory database for applications needing low-latency data access. || Extremely fast data access, ideal for low-latency requirements. || Data persistence is not guaranteed, not suitable for critical data, limited support for Keycloak. || Applications that require very fast access to data and can tolerate the lack of persistence.
|}

== How to Build an LDAP Schema ==

Here are the steps to construct an LDAP schema:

'''1. Understand Basic Concepts'''
Familiarize yourself with **ObjectClasses** and **Attributes**. Each entry in an LDAP directory must be associated with at least one ObjectClass, which defines the type of entry (e.g., user, group).

'''2. Define ObjectClasses'''
Create ObjectClasses that represent the types of entries you wish to store. For example, an ObjectClass for users might include attributes such as `cn` (common name) and `mail` (email address).

'''3. Define Attributes'''
Define the attributes that each ObjectClass can have. Each attribute must have a name, a syntax, and can be marked as required (`MUST`) or optional (`MAY`).

'''4. Create the Schema File'''
Gather all the definitions of ObjectClasses and attributes into an LDIF file. This file will contain all the information necessary to add your schema to an LDAP server.

'''5. Add the Schema to OpenLDAP'''
Use the `ldapadd` command to add the schema to your OpenLDAP server. Make sure to use the correct options for authentication and the path to the LDIF file.

'''6. Test the Schema'''
After adding the schema, test it by adding entries that use the new ObjectClasses and attributes. Verify that the LDAP server accepts the new entries and that the validations are working properly.

'''7. Maintain and Evolve the Schema'''
As your needs change, you may need to update your schema. This may include adding new attributes or ObjectClasses.

== Useful Links ==
* [Create a new LDAP client schema - NetApp](https://docs.netapp.com/fr-fr/ontap/nfs-config/create-new-ldap-client-schema-task.html)
* [LDAP Tutorial - INRIA](https://www-sop.inria.fr/members/Laurent.Mirtain/ldap-livre.html)
* [Add a specific schema - Vincent Liefooghe](https://www.vincentliefooghe.net/content/ajouter-un-sch%C3%A9ma-sp%C3%A9cifique)

User:MoustaphaAs

2024-11-29T11:04:40Z

MoustaphaAs:

= Keycloak =
Keycloak is an open-source identity and access management solution designed for modern applications and services. It provides centralized authentication and authorization, enabling Single Sign-On (SSO), identity brokering, and social login integration. With support for both OAuth2.0 and OpenID Connect protocols, Keycloak simplifies security management by handling user authentication, session management, and access control. Whether you're building cloud-native applications or integrating legacy systems, Keycloak offers a scalable, flexible, and secure solution for managing user identities and permissions across a wide range of platforms.
== Keycloak Deployment Methods ==

Below are different methods for deploying Keycloak, along with their advantages, disadvantages, and ideal use cases:

{| class="wikitable"
! Deployment Method !! Description !! Advantages !! Disadvantages !! Ideal For
|-
| OpenJDK || This method involves installing Keycloak directly on bare metal using OpenJDK. It requires manual installation and dependency management. || Full control over configuration, optimized performance. || More complex setup, requires manual updates and security management. || Environments where full control is necessary or for specific deployments.
|-
| Docker || Uses Docker containers to deploy Keycloak. This simplifies the installation process and isolates the application. || Easy deployment, portability, simplified dependency management. || May require knowledge of containerization and Docker management. || Developers or teams looking for a fast, portable solution.
|-
| Podman || Similar to Docker, but Podman allows managing containers without a daemon. It is an alternative to Docker with a daemon-less architecture. || Daemon-less container management, better default security. || Less documentation and community support compared to Docker. || Users who prioritize security and wish to avoid using a daemon.
|-
| Kubernetes || Deploys Keycloak in a Kubernetes cluster, enabling advanced container orchestration. || Scalability, high availability, automated container management. || Increased complexity, requires in-depth Kubernetes knowledge. || Enterprises with high availability and scalability needs.
|-
| OpenShift || An enterprise-level Kubernetes platform that simplifies deployment and management of containerized applications. || Integrated tools for application management, enhanced security, CI/CD support. || Requires a license, more complex for novice users. || Enterprises already using OpenShift or looking for a robust, integrated solution.
|-
| Scaling || Focuses on optimizing Keycloak for scalability and performance tuning. || Improved performance, ability to handle large numbers of users. || Requires understanding of scalability best practices. || Large-scale deployments or environments with high performance needs.
|}

== Keycloak Database Types ==

Below are different types of databases that can be used with Keycloak, including their advantages, disadvantages, and ideal use cases:

{| class="wikitable"
! Database Type !! Description !! Advantages !! Disadvantages !! Ideal For
|-
| Relational Database (PostgreSQL, MySQL) || Keycloak is designed to work with relational databases, making configuration easier. || Native support, excellent transaction management, data integrity through constraints and relationships. || Vertical scalability, requires hardware upgrades for increased load, active administrative management required. || Environments that require strong data integrity and security, with manageable scalability.
|-
| NoSQL Database (MongoDB, Cassandra) || NoSQL databases provide flexible data models and are ideal for large, evolving data sets. || Horizontal scalability, flexible data models, great for large-scale data. || Limited native support in Keycloak, integration may require additional work. || Projects with large, dynamic datasets, where scalability is a priority.
|-
| Hosted Database (Amazon RDS, Azure Database) || Cloud providers manage the infrastructure, backups, and updates. || Simplified management, high availability, disaster recovery options. || Higher long-term costs, dependency on cloud service provider availability and performance. || Businesses seeking ease of management with high availability and disaster recovery capabilities.
|-
| Containerized Database (PostgreSQL in Docker) || Running the database in a container (e.g., Docker) for easy deployment and movement. || Portability, isolation from host system for improved security. || Persistent data management, requires proper volume configuration to avoid data loss when containers are removed. || Teams that need portability and isolation with containerized environments.
|-
| On-Premises Database || Managing the database directly on-site. || Full control over configuration and security, optimized performance. || Intensive management required, including maintenance, updates, and backups, fixed infrastructure costs. || Organizations with technical expertise, and those needing full control over their database.
|-
| Distributed Database (Cassandra) || A distributed database system designed for massive, scalable workloads. || High availability, designed to operate without interruptions, suitable for critical applications. || Difficult integration with Keycloak, lacks native support, fewer transaction features. || Large-scale deployments requiring high availability and scalability.
|-
| In-Memory Database (Redis) || A fast, in-memory database for applications needing low-latency data access. || Extremely fast data access, ideal for low-latency requirements. || Data persistence is not guaranteed, not suitable for critical data, limited support for Keycloak. || Applications that require very fast access to data and can tolerate the lack of persistence.
|}

== How to Build an LDAP Schema ==

Here are the steps to construct an LDAP schema:

'''1. Understand Basic Concepts'''
Familiarize yourself with **ObjectClasses** and **Attributes**. Each entry in an LDAP directory must be associated with at least one ObjectClass, which defines the type of entry (e.g., user, group).

'''2. Define ObjectClasses'''
Create ObjectClasses that represent the types of entries you wish to store. For example, an ObjectClass for users might include attributes such as `cn` (common name) and `mail` (email address).

'''3. Define Attributes'''
Define the attributes that each ObjectClass can have. Each attribute must have a name, a syntax, and can be marked as required (`MUST`) or optional (`MAY`).

'''4. Create the Schema File'''
Gather all the definitions of ObjectClasses and attributes into an LDIF file. This file will contain all the information necessary to add your schema to an LDAP server.

'''5. Add the Schema to OpenLDAP'''
Use the `ldapadd` command to add the schema to your OpenLDAP server. Make sure to use the correct options for authentication and the path to the LDIF file.

'''6. Test the Schema'''
After adding the schema, test it by adding entries that use the new ObjectClasses and attributes. Verify that the LDAP server accepts the new entries and that the validations are working properly.

'''7. Maintain and Evolve the Schema'''
As your needs change, you may need to update your schema. This may include adding new attributes or ObjectClasses.

== Useful Links ==
* [Create a new LDAP client schema - NetApp](https://docs.netapp.com/fr-fr/ontap/nfs-config/create-new-ldap-client-schema-task.html)
* [LDAP Tutorial - INRIA](https://www-sop.inria.fr/members/Laurent.Mirtain/ldap-livre.html)
* [Add a specific schema - Vincent Liefooghe](https://www.vincentliefooghe.net/content/ajouter-un-sch%C3%A9ma-sp%C3%A9cifique)

User:MoustaphaAs

2024-11-29T11:03:16Z

MoustaphaAs:

= Keycloak =
== Keycloak Deployment Methods ==

Below are different methods for deploying Keycloak, along with their advantages, disadvantages, and ideal use cases:

{| class="wikitable"
! Deployment Method !! Description !! Advantages !! Disadvantages !! Ideal For
|-
| OpenJDK || This method involves installing Keycloak directly on bare metal using OpenJDK. It requires manual installation and dependency management. || Full control over configuration, optimized performance. || More complex setup, requires manual updates and security management. || Environments where full control is necessary or for specific deployments.
|-
| Docker || Uses Docker containers to deploy Keycloak. This simplifies the installation process and isolates the application. || Easy deployment, portability, simplified dependency management. || May require knowledge of containerization and Docker management. || Developers or teams looking for a fast, portable solution.
|-
| Podman || Similar to Docker, but Podman allows managing containers without a daemon. It is an alternative to Docker with a daemon-less architecture. || Daemon-less container management, better default security. || Less documentation and community support compared to Docker. || Users who prioritize security and wish to avoid using a daemon.
|-
| Kubernetes || Deploys Keycloak in a Kubernetes cluster, enabling advanced container orchestration. || Scalability, high availability, automated container management. || Increased complexity, requires in-depth Kubernetes knowledge. || Enterprises with high availability and scalability needs.
|-
| OpenShift || An enterprise-level Kubernetes platform that simplifies deployment and management of containerized applications. || Integrated tools for application management, enhanced security, CI/CD support. || Requires a license, more complex for novice users. || Enterprises already using OpenShift or looking for a robust, integrated solution.
|-
| Scaling || Focuses on optimizing Keycloak for scalability and performance tuning. || Improved performance, ability to handle large numbers of users. || Requires understanding of scalability best practices. || Large-scale deployments or environments with high performance needs.
|}

== Keycloak Database Types ==

Below are different types of databases that can be used with Keycloak, including their advantages, disadvantages, and ideal use cases:

{| class="wikitable"
! Database Type !! Description !! Advantages !! Disadvantages !! Ideal For
|-
| Relational Database (PostgreSQL, MySQL) || Keycloak is designed to work with relational databases, making configuration easier. || Native support, excellent transaction management, data integrity through constraints and relationships. || Vertical scalability, requires hardware upgrades for increased load, active administrative management required. || Environments that require strong data integrity and security, with manageable scalability.
|-
| NoSQL Database (MongoDB, Cassandra) || NoSQL databases provide flexible data models and are ideal for large, evolving data sets. || Horizontal scalability, flexible data models, great for large-scale data. || Limited native support in Keycloak, integration may require additional work. || Projects with large, dynamic datasets, where scalability is a priority.
|-
| Hosted Database (Amazon RDS, Azure Database) || Cloud providers manage the infrastructure, backups, and updates. || Simplified management, high availability, disaster recovery options. || Higher long-term costs, dependency on cloud service provider availability and performance. || Businesses seeking ease of management with high availability and disaster recovery capabilities.
|-
| Containerized Database (PostgreSQL in Docker) || Running the database in a container (e.g., Docker) for easy deployment and movement. || Portability, isolation from host system for improved security. || Persistent data management, requires proper volume configuration to avoid data loss when containers are removed. || Teams that need portability and isolation with containerized environments.
|-
| On-Premises Database || Managing the database directly on-site. || Full control over configuration and security, optimized performance. || Intensive management required, including maintenance, updates, and backups, fixed infrastructure costs. || Organizations with technical expertise, and those needing full control over their database.
|-
| Distributed Database (Cassandra) || A distributed database system designed for massive, scalable workloads. || High availability, designed to operate without interruptions, suitable for critical applications. || Difficult integration with Keycloak, lacks native support, fewer transaction features. || Large-scale deployments requiring high availability and scalability.
|-
| In-Memory Database (Redis) || A fast, in-memory database for applications needing low-latency data access. || Extremely fast data access, ideal for low-latency requirements. || Data persistence is not guaranteed, not suitable for critical data, limited support for Keycloak. || Applications that require very fast access to data and can tolerate the lack of persistence.
|}

== How to Build an LDAP Schema ==

Here are the steps to construct an LDAP schema:

'''1. Understand Basic Concepts'''
Familiarize yourself with **ObjectClasses** and **Attributes**. Each entry in an LDAP directory must be associated with at least one ObjectClass, which defines the type of entry (e.g., user, group).

'''2. Define ObjectClasses'''
Create ObjectClasses that represent the types of entries you wish to store. For example, an ObjectClass for users might include attributes such as `cn` (common name) and `mail` (email address).

'''3. Define Attributes'''
Define the attributes that each ObjectClass can have. Each attribute must have a name, a syntax, and can be marked as required (`MUST`) or optional (`MAY`).

'''4. Create the Schema File'''
Gather all the definitions of ObjectClasses and attributes into an LDIF file. This file will contain all the information necessary to add your schema to an LDAP server.

'''5. Add the Schema to OpenLDAP'''
Use the `ldapadd` command to add the schema to your OpenLDAP server. Make sure to use the correct options for authentication and the path to the LDIF file.

'''6. Test the Schema'''
After adding the schema, test it by adding entries that use the new ObjectClasses and attributes. Verify that the LDAP server accepts the new entries and that the validations are working properly.

'''7. Maintain and Evolve the Schema'''
As your needs change, you may need to update your schema. This may include adding new attributes or ObjectClasses.

== Useful Links ==
* [Create a new LDAP client schema - NetApp](https://docs.netapp.com/fr-fr/ontap/nfs-config/create-new-ldap-client-schema-task.html)
* [LDAP Tutorial - INRIA](https://www-sop.inria.fr/members/Laurent.Mirtain/ldap-livre.html)
* [Add a specific schema - Vincent Liefooghe](https://www.vincentliefooghe.net/content/ajouter-un-sch%C3%A9ma-sp%C3%A9cifique)

User:MoustaphaAs

2024-11-29T10:57:03Z

MoustaphaAs:

= Keycloak =
== Keycloak Deployment Methods ==

Below are different methods for deploying Keycloak, along with their advantages, disadvantages, and ideal use cases:

{| class="wikitable"
! Deployment Method !! Description !! Advantages !! Disadvantages !! Ideal For
|-
| OpenJDK || This method involves installing Keycloak directly on bare metal using OpenJDK. It requires manual installation and dependency management. || Full control over configuration, optimized performance. || More complex setup, requires manual updates and security management. || Environments where full control is necessary or for specific deployments.
|-
| Docker || Uses Docker containers to deploy Keycloak. This simplifies the installation process and isolates the application. || Easy deployment, portability, simplified dependency management. || May require knowledge of containerization and Docker management. || Developers or teams looking for a fast, portable solution.
|-
| Podman || Similar to Docker, but Podman allows managing containers without a daemon. It is an alternative to Docker with a daemon-less architecture. || Daemon-less container management, better default security. || Less documentation and community support compared to Docker. || Users who prioritize security and wish to avoid using a daemon.
|-
| Kubernetes || Deploys Keycloak in a Kubernetes cluster, enabling advanced container orchestration. || Scalability, high availability, automated container management. || Increased complexity, requires in-depth Kubernetes knowledge. || Enterprises with high availability and scalability needs.
|-
| OpenShift || An enterprise-level Kubernetes platform that simplifies deployment and management of containerized applications. || Integrated tools for application management, enhanced security, CI/CD support. || Requires a license, more complex for novice users. || Enterprises already using OpenShift or looking for a robust, integrated solution.
|-
| Scaling || Focuses on optimizing Keycloak for scalability and performance tuning. || Improved performance, ability to handle large numbers of users. || Requires understanding of scalability best practices. || Large-scale deployments or environments with high performance needs.
|}

== Keycloak Database Types ==

Below are different types of databases that can be used with Keycloak, including their advantages, disadvantages, and ideal use cases:

{| class="wikitable"
! Database Type !! Description !! Advantages !! Disadvantages !! Ideal For
|-
| Relational Database (PostgreSQL, MySQL) || Keycloak is designed to work with relational databases, making configuration easier. || Native support, excellent transaction management, data integrity through constraints and relationships. || Vertical scalability, requires hardware upgrades for increased load, active administrative management required. || Environments that require strong data integrity and security, with manageable scalability.
|-
| NoSQL Database (MongoDB, Cassandra) || NoSQL databases provide flexible data models and are ideal for large, evolving data sets. || Horizontal scalability, flexible data models, great for large-scale data. || Limited native support in Keycloak, integration may require additional work. || Projects with large, dynamic datasets, where scalability is a priority.
|-
| Hosted Database (Amazon RDS, Azure Database) || Cloud providers manage the infrastructure, backups, and updates. || Simplified management, high availability, disaster recovery options. || Higher long-term costs, dependency on cloud service provider availability and performance. || Businesses seeking ease of management with high availability and disaster recovery capabilities.
|-
| Containerized Database (PostgreSQL in Docker) || Running the database in a container (e.g., Docker) for easy deployment and movement. || Portability, isolation from host system for improved security. || Persistent data management, requires proper volume configuration to avoid data loss when containers are removed. || Teams that need portability and isolation with containerized environments.
|-
| On-Premises Database || Managing the database directly on-site. || Full control over configuration and security, optimized performance. || Intensive management required, including maintenance, updates, and backups, fixed infrastructure costs. || Organizations with technical expertise, and those needing full control over their database.
|-
| Distributed Database (Cassandra) || A distributed database system designed for massive, scalable workloads. || High availability, designed to operate without interruptions, suitable for critical applications. || Difficult integration with Keycloak, lacks native support, fewer transaction features. || Large-scale deployments requiring high availability and scalability.
|-
| In-Memory Database (Redis) || A fast, in-memory database for applications needing low-latency data access. || Extremely fast data access, ideal for low-latency requirements. || Data persistence is not guaranteed, not suitable for critical data, limited support for Keycloak. || Applications that require very fast access to data and can tolerate the lack of persistence.
|}

== How to Build an LDAP Schema ==

Here are the steps to construct an LDAP schema:

# '''Understand Basic Concepts'''
Familiarize yourself with **ObjectClasses** and **Attributes**. Each entry in an LDAP directory must be associated with at least one ObjectClass, which defines the type of entry (e.g., user, group).
# '''Define ObjectClasses'''
Create ObjectClasses that represent the types of entries you wish to store. For example, an ObjectClass for users might include attributes such as `cn` (common name) and `mail` (email address).
# '''Define Attributes'''
Define the attributes that each ObjectClass can have. Each attribute must have a name, a syntax, and can be marked as required (`MUST`) or optional (`MAY`).
# '''Create the Schema File'''
Gather all the definitions of ObjectClasses and attributes into an LDIF file. This file will contain all the information necessary to add your schema to an LDAP server.
# '''Add the Schema to OpenLDAP'''
Use the `ldapadd` command to add the schema to your OpenLDAP server. Make sure to use the correct options for authentication and the path to the LDIF file.
# '''Test the Schema'''
After adding the schema, test it by adding entries that use the new ObjectClasses and attributes. Verify that the LDAP server accepts the new entries and that the validations are working properly.
# '''Maintain and Evolve the Schema'''
As your needs change, you may need to update your schema. This may include adding new attributes or ObjectClasses.

== Useful Links ==
* [Create a new LDAP client schema - NetApp](https://docs.netapp.com/fr-fr/ontap/nfs-config/create-new-ldap-client-schema-task.html)
* [LDAP Tutorial - INRIA](https://www-sop.inria.fr/members/Laurent.Mirtain/ldap-livre.html)
* [Add a specific schema - Vincent Liefooghe](https://www.vincentliefooghe.net/content/ajouter-un-sch%C3%A9ma-sp%C3%A9cifique)

User:MoustaphaAs

2024-11-29T10:55:14Z

MoustaphaAs: /* Keycloak */

User:MoustaphaAs

2024-11-29T09:32:52Z

MoustaphaAs: Created page with "= Keycloak ="

= Keycloak =

Upsection

2024-10-31T20:31:10Z

MoustaphaAs: Removed redirect to Static sites

=== Upsection ===
We need to maintain dependencies for the Gulp/handlebars site builder
across several repositories. The dependencies are brittle, security issues
will require to upgrade to a version of a package invoked by gulp-<feature>,
but gulp-<feature> will be abandoned and unmaintained. That's the usual
scenario. When it's maintained, the way to load the library in JS has changed.

That hard maintenance problem requires an unified solution, to be able to do it
one for all the sites. '''Upsection''' is the name of this ongoing effort to
maintain, and provide a tool to populate the dependencies and build the site
with a simple `make`. Proof of concept lives in {{repo|upsection}}.

A second advantage is the current repository creation process is a little
bit cumbersome, as highlighted by the previous sections instructions to
fetch the build mechanism and the src/ folder in two different sources.

Upsection repository contains our full usable template in ONE place.

As of 2024-10, Upsection dependencies aren't up-to-date, so you'll need if you use it
to upgrade Node packages to the one used in {{repo|join}} or {{repo|infra-www}}.

Expected features:

* Create a site with a `upsection` command
* Being able to only store upsection configuration + assets directories in the websites repositories
** `upsection` can regenerate the build mechanism: package.json, node dependencies
** Site get freshest dependencies for the build mechanism

Current languages stack:

* At upsection level
** Python for upsection itself
** BSD make (Makefile) to generate needed files
* At static site build level
** Node.JS and Gulp still manage the site build
* For the site assets
** SCSS
** modern JS with Babel to transpile when needed
** HTML from handlebars templates
** YAML for data

Static sites

2024-10-31T20:26:41Z

MoustaphaAs: /* Upsection */

'''Static sites''' are used in two context at Nasqueron:

# '''Information static sites.''' Sites with only static content
# '''JavaScript front-end clients.''' Sites with dynamic back-end: the HTML site uses JS to communicate with the back-end through a REST API.

== Static site template ==
We build the first sites from the Foundation CSS framework ZURB template.

This approach works well for pure static sites, or for JS clients to query an API
like we do in {{repo|infra-www}}.

Your site is composed of two parts:
* a src/ folder with your site assets (JS, CSS), pages and data
* a build mechanism driven by Gulp

This is perfect to quickly assemble a site, especially as we can do it on Jenkins for CD.

If you use frameworks like React/Vue and want to make them manage your site routing and structure,
don't use this template.

=== Create a site in 2024 ===

Currently, the build mechanism and the template are to be extracted from two different places:

+-----------------+ +-------------------------------------+
| Build mechanism | | Site assets: SCSS, JS, HTML, data. |
| | | |
| [ Gulp ] | | [ Foundation + Handlebars ] |
+-----------------+ +-------------------------------------+
^ ^
+-----------------+ +-------------------------------------+
| Copy it from an | | Take the up-to-date last version |
| existing site: | | from the Foundation Zurb template: |
| infra-www repo | | foundation/foundation-zurb-template |
+-----------------+ +-------------------------------------+

'''Step 1.''' To get the build mechanism right, as of 2023-05-28, take it from
the {{repo|join}} or from the {{repo|infra-www}} repository:

git clone https://devcentral.nasqueron.org/source/infra-www.git your-awesome-site
cd your-awesome-site
rm -rf src/ .git Jenkinsfile

You'll then get a folder with a correct build mechanism.

'''Step 2.''' Initialize your own repository:

git init .
$EDITOR .babelrc .browserslistrc config.yml gulpfile.babel.js package.json readme.md
git add .
git commit -m "Build a new static site"

At that stage, you've a correct build mechanism, configured for your website,
but no template or content.

'''Step 3.''' Add the Foundation template:

Copy a fresh <code>src/</code> folder from the [https://github.com/foundation/foundation-zurb-template foundation/foundation-zurb-template] repository:

git clone https://github.com/foundation/foundation-zurb-template /tmp/template
mv /tmp/template/src .
rm -rf /tmp/template

And that's it. You can now work on it and build your site.

You should get the following structure:
<pre>
.
├── config.yml
├── gulpfile.babel.js
├── Jenkinsfile
├── package.json
├── readme.md
└── src
├── assets
│   ├── img
│   ├── js
│   │   ├── app.js
│   │   └── lib
│   │   └── foundation-explicit-pieces.js
│   └── scss
│   ├── _settings.scss
│   ├── app.scss
│   ├── components
│   └── global
│   └── _typography.scss
├── data
├── layouts
│   └── default.html
├── pages
│   └── index.html
├── partials
└── styleguide
├── index.md
└── template.html

14 directories, 14 files
</pre>

'''Enjoy.''' Follow your README instructions to install Node dependencies and build your site:

yarn install
yarn start

'''Who to contact for support.''' {{u|Dereckson}} maintains those instructions and this build mechanism.

'''Note about Jenkins.''' We're currently looking how to switch from the old Jenkins deployment method to the new [[Alkane]] one, so don't commit a Jenkinsfile (excepted if you solve that exact problem of course), we'll figure it as soon as your site is ready to be published.

=== Upsection ===
We need to maintain dependencies for the Gulp/handlebars site builder
across several repositories. The dependencies are brittle, security issues
will require to upgrade to a version of a package invoked by gulp-<feature>,
but gulp-<feature> will be abandoned and unmaintained. That's the usual
scenario. When it's maintained, the way to load the library in JS has changed.

That hard maintenance problem requires an unified solution, to be able to do it
one for all the sites. '''Upsection''' is the name of this ongoing effort to
maintain, and provide a tool to populate the dependencies and build the site
with a simple `make`. Proof of concept lives in {{repo|upsection}}.

A second advantage is the current repository creation process is a little
bit cumbersome, as highlighted by the previous sections instructions to
fetch the build mechanism and the src/ folder in two different sources.

Upsection repository contains our full usable template in ONE place.

As of 2024-10, Upsection dependencies aren't up-to-date, so you'll need if you use it
to upgrade Node packages to the one used in {{repo|join}} or {{repo|infra-www}}.

Expected features:

* Create a site with a `upsection` command
* Being able to only store upsection configuration + assets directories in the websites repositories
** `upsection` can regenerate the build mechanism: package.json, node dependencies
** Site get freshest dependencies for the build mechanism

Current languages stack:

* At upsection level
** Python for upsection itself
** BSD make (Makefile) to generate needed files
* At static site build level
** Node.JS and Gulp still manage the site build
* For the site assets
** SCSS
** modern JS with Babel to transpile when needed
** HTML from handlebars templates
** YAML for data

== Build Vue.js application ==
Nidal uses another strategy for {{repo|servpulse}}: Vue.js provides a CLI tool to
bootstrap a web site, and Foundation is added afterwards:

<code>npm init vue@latest</code>

'''Who to contact for support.''' {{u|Inidal}} maintains those instructions and this build mechanism.

[[Category:Contributor guide]]
[[Category:Reference]]

Static sites

2024-10-31T20:26:05Z

MoustaphaAs: /* Upsection */

'''Static sites''' are used in two context at Nasqueron:

# '''Information static sites.''' Sites with only static content
# '''JavaScript front-end clients.''' Sites with dynamic back-end: the HTML site uses JS to communicate with the back-end through a REST API.

== Static site template ==
We build the first sites from the Foundation CSS framework ZURB template.

This approach works well for pure static sites, or for JS clients to query an API
like we do in {{repo|infra-www}}.

Your site is composed of two parts:
* a src/ folder with your site assets (JS, CSS), pages and data
* a build mechanism driven by Gulp

This is perfect to quickly assemble a site, especially as we can do it on Jenkins for CD.

If you use frameworks like React/Vue and want to make them manage your site routing and structure,
don't use this template.

=== Create a site in 2024 ===

Currently, the build mechanism and the template are to be extracted from two different places:

+-----------------+ +-------------------------------------+
| Build mechanism | | Site assets: SCSS, JS, HTML, data. |
| | | |
| [ Gulp ] | | [ Foundation + Handlebars ] |
+-----------------+ +-------------------------------------+
^ ^
+-----------------+ +-------------------------------------+
| Copy it from an | | Take the up-to-date last version |
| existing site: | | from the Foundation Zurb template: |
| infra-www repo | | foundation/foundation-zurb-template |
+-----------------+ +-------------------------------------+

'''Step 1.''' To get the build mechanism right, as of 2023-05-28, take it from
the {{repo|join}} or from the {{repo|infra-www}} repository:

git clone https://devcentral.nasqueron.org/source/infra-www.git your-awesome-site
cd your-awesome-site
rm -rf src/ .git Jenkinsfile

You'll then get a folder with a correct build mechanism.

'''Step 2.''' Initialize your own repository:

git init .
$EDITOR .babelrc .browserslistrc config.yml gulpfile.babel.js package.json readme.md
git add .
git commit -m "Build a new static site"

At that stage, you've a correct build mechanism, configured for your website,
but no template or content.

'''Step 3.''' Add the Foundation template:

Copy a fresh <code>src/</code> folder from the [https://github.com/foundation/foundation-zurb-template foundation/foundation-zurb-template] repository:

git clone https://github.com/foundation/foundation-zurb-template /tmp/template
mv /tmp/template/src .
rm -rf /tmp/template

And that's it. You can now work on it and build your site.

You should get the following structure:
<pre>
.
├── config.yml
├── gulpfile.babel.js
├── Jenkinsfile
├── package.json
├── readme.md
└── src
├── assets
│   ├── img
│   ├── js
│   │   ├── app.js
│   │   └── lib
│   │   └── foundation-explicit-pieces.js
│   └── scss
│   ├── _settings.scss
│   ├── app.scss
│   ├── components
│   └── global
│   └── _typography.scss
├── data
├── layouts
│   └── default.html
├── pages
│   └── index.html
├── partials
└── styleguide
├── index.md
└── template.html

14 directories, 14 files
</pre>

'''Enjoy.''' Follow your README instructions to install Node dependencies and build your site:

yarn install
yarn start

'''Who to contact for support.''' {{u|Dereckson}} maintains those instructions and this build mechanism.

'''Note about Jenkins.''' We're currently looking how to switch from the old Jenkins deployment method to the new [[Alkane]] one, so don't commit a Jenkinsfile (excepted if you solve that exact problem of course), we'll figure it as soon as your site is ready to be published.

=== Upsection ===
#REDIRECT [[Upsection]]
We need to maintain dependencies for the Gulp/handlebars site builder
across several repositories. The dependencies are brittle, security issues
will require to upgrade to a version of a package invoked by gulp-<feature>,
but gulp-<feature> will be abandoned and unmaintained. That's the usual
scenario. When it's maintained, the way to load the library in JS has changed.

That hard maintenance problem requires an unified solution, to be able to do it
one for all the sites. '''Upsection''' is the name of this ongoing effort to
maintain, and provide a tool to populate the dependencies and build the site
with a simple `make`. Proof of concept lives in {{repo|upsection}}.

A second advantage is the current repository creation process is a little
bit cumbersome, as highlighted by the previous sections instructions to
fetch the build mechanism and the src/ folder in two different sources.

Upsection repository contains our full usable template in ONE place.

As of 2024-10, Upsection dependencies aren't up-to-date, so you'll need if you use it
to upgrade Node packages to the one used in {{repo|join}} or {{repo|infra-www}}.

Expected features:

* Create a site with a `upsection` command
* Being able to only store upsection configuration + assets directories in the websites repositories
** `upsection` can regenerate the build mechanism: package.json, node dependencies
** Site get freshest dependencies for the build mechanism

Current languages stack:

* At upsection level
** Python for upsection itself
** BSD make (Makefile) to generate needed files
* At static site build level
** Node.JS and Gulp still manage the site build
* For the site assets
** SCSS
** modern JS with Babel to transpile when needed
** HTML from handlebars templates
** YAML for data

== Build Vue.js application ==
Nidal uses another strategy for {{repo|servpulse}}: Vue.js provides a CLI tool to
bootstrap a web site, and Foundation is added afterwards:

<code>npm init vue@latest</code>

'''Who to contact for support.''' {{u|Inidal}} maintains those instructions and this build mechanism.

[[Category:Contributor guide]]
[[Category:Reference]]

Upsection

2024-10-31T20:24:42Z

MoustaphaAs:

#REDIRECT [[Static sites]]
=== Upsection ===
We need to maintain dependencies for the Gulp/handlebars site builder
across several repositories. The dependencies are brittle, security issues
will require to upgrade to a version of a package invoked by gulp-<feature>,
but gulp-<feature> will be abandoned and unmaintained. That's the usual
scenario. When it's maintained, the way to load the library in JS has changed.

That hard maintenance problem requires an unified solution, to be able to do it
one for all the sites. '''Upsection''' is the name of this ongoing effort to
maintain, and provide a tool to populate the dependencies and build the site
with a simple `make`. Proof of concept lives in {{repo|upsection}}.

A second advantage is the current repository creation process is a little
bit cumbersome, as highlighted by the previous sections instructions to
fetch the build mechanism and the src/ folder in two different sources.

Upsection repository contains our full usable template in ONE place.

As of 2024-10, Upsection dependencies aren't up-to-date, so you'll need if you use it
to upgrade Node packages to the one used in {{repo|join}} or {{repo|infra-www}}.

Expected features:

* Create a site with a `upsection` command
* Being able to only store upsection configuration + assets directories in the websites repositories
** `upsection` can regenerate the build mechanism: package.json, node dependencies
** Site get freshest dependencies for the build mechanism

Current languages stack:

* At upsection level
** Python for upsection itself
** BSD make (Makefile) to generate needed files
* At static site build level
** Node.JS and Gulp still manage the site build
* For the site assets
** SCSS
** modern JS with Babel to transpile when needed
** HTML from handlebars templates
** YAML for data