We’re excited to introduce you to the new operation in
Clarive: Git Timesync available in the upcoming 7.10.6 release. This
operation is specifically designed to update the file timestamps in your job
directory to match their respective Git commit timestamps. Let’s dive in and
see how it works and how you can utilize it in your Clarive pipeline rule.

Motivation

When Git performs a checkout or clone operation, it intentionally does not update the timestamp of the files to reflect their last commit dates. Instead, all files receive the timestamp of when the clone or checkout occurred. The primary reason for this behavior is performance. Updating file timestamps to their respective commit dates would require Git to examine the entire commit history of each file, which can be computationally intensive and slow, especially for large repositories with extensive histories. By using the clone or checkout date as the timestamp, Git can quickly populate the working directory without any unnecessary overhead. Furthermore, maintaining consistent timestamps helps build systems, like make, determine if a file needs to be rebuilt, ensuring efficient and predictable builds.

What is Git Timesync?

Git Timesync is a Clarive rule operation that updates the timestamps of files in the job directory so they align with the most recent Git commit timestamps. However, files without a Git timestamp or those from other repositories that don’t match the job’s repository will remain unchanged.

Configuration Essentials

Before using Git Timesync, it’s crucial to understand its configuration:

• Path: This is the relative directory within each Git repository to be processed. By default, it uses . which means all files controlled by Git.

• Git Repositories: An optional list of Git Repositories that you wish to process. If you leave it blank, all Git Repositories included in the job where the rule is running will be processed.

Remember, you can use multiple Timesync operations if you’re dealing with different path and repository combinations.

Note: If you’re working with a sizable repository or one with an extensive commit history, Git Timesync is very optimized, but it may still take a while to process all the timestamps.

Dependencies

Ensure you execute Git Timesync after these operations:

• Load Job Items into Stash
• Checkout Job Items or another equivalent repository checkout.

How to Use Git Timesync in a Clarive Pipeline Rule?

1. Open your desired Clarive pipeline rule.
2. Navigate to the palette.
3. Simply drag the Git Timesync operation from the palette and drop it into your rule after the aforementioned dependencies.
4. Configure the Path and Git Repositories as per your requirements.
5. Save your rule, deploy a changeset and you’re good to go!

Git Timesync is a handy operation for those who wish to synchronize file timestamps with their Git commit timestamps, ensuring consistency and clarity. So, next time you’re working on a Clarive project, give Git Timesync a try and let it handle the timestamp synchronization for you!

Happy clariving!

As a DevOps engineer, having the ability to securely and reliably execute commands, transfer files, and automate workflows across your infrastructure is absolutely essential. That’s why we’re excited to announce the release of ClaX – an open source remote deployment agent that makes this possible.

We understand the critical need for efficient tools that streamline remote deployment, file exchange, and command execution across a variety of platforms. That’s where ClaX comes into play. ClaX is a portable HTTP(s) remote deployment agent developed by Clarive, designed to empower DevOps professionals. Whether you deploy to Windows, Mac, or Linux servers, ClaX simplifies these tasks as an alternative to SSH or other more involved methods.

What is ClaX?

ClaX is more than just your run-of-the-mill remote agent. It’s a powerful and versatile tool that can run commands, exchange files, and handle more complex operations with ease. One of its standout features is its ability to read requests from stdin and write responses to stdout, making it a perfect fit for inetd integration.

ClaX is a lightweight HTTP-based agent that can be installed on Windows, Linux, and UNIX servers. It allows you to:

• Run commands and scripts remotely
• Upload and download files
• Integrate with continuous deployment workflows

The ClaX agent exposes a REST API that can be called from any language or tool that supports HTTP requests. For security, the API uses SSL and access control via HTTP basic auth or client certificates.

Some example uses cases:

• Deploying application code to servers
• Running data migration scripts
• Automating post-deployment checks
• Collecting logs and artifacts
• Synchronizing files across a cluster

ClaX handles executing commands asynchronously. It streams the stdout and stderr back in real-time, while also returning the exit code and execution status. For long running processes, you can even set a timeout.

Why Use ClaX?

There are other tools that can do remote execution and orchestration. However, ClaX has a few advantages:

Portable and self-contained – ClaX is a single binary with no dependencies. Just drop it on a server and it works, no complex installation required. It also makes it easy to upgrade by just replacing the executable.

Embeddable and composable – ClaX exposes a simple HTTP API that can be called from any language or toolkit. It can be embedded into custom scripts and applications.

Lightweight and low overhead – ClaX utilizes a low memory footprint, making it suitable for containers and cloud environments. The API is optimized for performance and scalability.

Cross platform – Tested on Linux, UNIX, Windows, and legacy systems like mainframes.

Platform Compatibility

At Clarive, we understand that DevOps environments are diverse, with various servers running different operating systems. That’s why ClaX has been rigorously tested and proven to work seamlessly on a wide range of platforms, including:

• Debian GNU/Linux x86_64
• FreeBSD 10.3
• Mac OS 10.11+
• Cygwin x86_64
• Windows 2003, 2008, 2012+
• Solaris 10 i86pc
• z/OS 390
• Raspbian ARMv7

This extensive platform support ensures that ClaX can be your go-to tool, regardless of your server’s operating system. Contact us if the ClaX binary you need is not available in the download page and we’ll generate it for you.

Why not just plain SSH?

ClaX can serve as a valuable alternative to using plain SSH, even though the Clarive server also supports SSH. Here are some advantages of using ClaX over SSH in specific scenarios:

• Simplified Management: ClaX is designed as a remote deployment agent, which means it’s purpose-built for remote tasks. SSH, on the other hand, is a general-purpose remote access and administration tool. When you need to streamline specific tasks like running commands, exchanging files, or managing deployments, ClaX provides a more focused and simplified approach.

• Security Features: ClaX offers a robust set of security features, including SSL support and basic authentication, ensuring secure communication and access control. While SSH is inherently secure, it might require additional configurations for specific use cases. ClaX simplifies this by providing security out of the box.

• Platform Independence: ClaX is compatible with a wide range of platforms, including Windows, Mac, and various Linux distributions. SSH is primarily associated with Unix-like systems, making ClaX a more versatile choice for heterogeneous server environments. If you have mixed OS environments, ClaX can be a unifying solution.

• Service Integration: ClaX can be run as a Windows service, allowing it to seamlessly integrate with Windows server environments. SSH does not function as a service in the same way, and while it can be used on Windows, ClaX simplifies the process of running tasks on Windows servers.

• REST API: ClaX offers a REST API that simplifies automation and integration with other tools. SSH is a command-line tool and lacks the comprehensive API capabilities that ClaX provides. This API can be a game-changer when you need to automate deployment and management tasks.

• Inetd Integration: ClaX’s ability to read requests from stdin and write responses to stdout makes it suitable for inetd integration. This is particularly useful when you want to streamline request handling in a more controlled manner. SSH, on the other hand, is not designed for this level of integration.

• Configurability: ClaX’s INI-based configuration file makes it easy to customize and adapt to specific requirements. SSH typically relies on a more complex configuration file, which might be overkill for scenarios where simplicity is key.

In summary, ClaX is a specialized tool that excels in scenarios where you need a streamlined, secure, and platform-independent solution for remote deployment, file exchange, and command execution. While SSH is an essential and versatile tool for remote access and administration, it may require additional configuration and may not be as well-suited to specific DevOps tasks as ClaX. Depending on your use case, ClaX can be a valuable addition to your toolkit, enhancing your ability to manage and automate remote tasks efficiently.

Get Started with ClaX

Ready to give ClaX a try? Head over to the GitHub releases page to download the latest binary for your platform.

Installation takes just a minute:

1. Drop the tar or zip archive onto your server and extract the clax binary.

2. Create a clax.ini config file, there’s an example included. Choose between Basic HTTPs
   or Certificate based authentication.

3. Run clax -l clax.log -c clax.ini to start it as a daemon.

Now ClaX is running as a service exposing the HTTP API on the configured port.

The ClaX documentation contains examples of how interact with the API using cURL. There are also client libraries available for Node.js and Python that make it even easier work with the API by handling connections, serialization, and responses.

Windows Service

ClaX can also be run as a Windows service, making it even more versatile for managing your Windows servers. Here’s how you can install and control ClaX as a Windows service using the sc command:

• Install ClaX service (make sure there’s a space after binPath=):

  sc create clax binPath= "C:\clax.exe -l C:\clax.log -c C:\clax.ini" start= auto
  

• Start the service:

  sc start clax
  

• Query the service status:

  sc query clax
  

• Stop the service:

  sc stop clax
  

How to configure certificate-based authentication

Here’s instructions to use the most secure, SSL certificate-based authentication with ClaX:

1. Generate a Certificate Authority (CA) Certificate:
   • Start by creating a CA certificate, which will act as the root of trust for your ClaX setup. This certificate will be used to sign both the server and client certificates. Run the following command:

   openssl req -out clax_ca.pem -new -x509 -subj '/CN=ClaxCertificateAuthority'
   

   This command generates a CA certificate in the file clax_ca.pem with the common name “ClaxCertificateAuthority.”

2. Create a Serial File:

   • To manage signed certificates, create a serial file. Use the following command:

   echo -n '00' > clax_file.srl
   

3. Generate a Server Certificate:
   • Now, generate a server certificate for ClaX, which will be used for server-side SSL authentication. Use these commands:

   openssl genrsa -out clax_server.key 2048
   openssl req -key clax_server.key -new -out clax_server.req
   openssl x509 -req -in clax_server.req -CA clax_ca.pem -CAkey privkey.pem -CAserial clax_file.srl -out clax_server.pem -subj '/CN=clax-server'
   

   These commands create a server key (clax_server.key), a certificate signing request (clax_server.req), and the server certificate (clax_server.pem). Customize the common name (‘/CN’) to match your ClaX server’s name.

4. Generate a Client Certificate (Optional):

   • If you require SSL client verification, generate client certificates for ClaX. These certificates allow clients to authenticate themselves to the ClaX server.
   • Use commands similar to those in step 3 to create client keys, certificate signing requests, and client certificates.
5. Convert Client Certificate to PKCS12 (Optional):
   • If you’ve generated client certificates and want to use them in applications supporting PKCS12 format, convert them with the following command:

   openssl pkcs12 -export -in clax_client.pem -inkey clax_client.key -out clax_client.p12
   

   This command creates a client PKCS12 certificate in the file clax_client.p12.

6. Configure clax.ini File:

   • Open your clax.ini configuration file, and add or update the SSL section with the paths to the CA certificate, server certificate, and server key. The clax.ini file should have a section like this:

   [ssl]
   enabled = yes
   verify = yes
   cert_file = clax_server.pem
   key_file = clax_server.key
   ca_file = clax_ca.pem
   

• Adjust the paths in the cert_file, key_file, and ca_file parameters to match the location of your SSL certificates. These settings ensure that ClaX uses SSL authentication with the generated certificates.

By following these steps, you’ll have created SSL certificates for ClaX and configured them in the clax.ini file, enabling secure SSL communication for your ClaX server. Clients connecting to ClaX will use these certificates for authentication and encryption, enhancing the security of your remote deployments and file exchanges.

We hope you find ClaX useful! Let us know if you have any feedback by opening an issue on the GitHub repo. The project is open source and we welcome contributions from the community.