AIStor supports configuring a single Active Directory or LDAP (AD/LDAP) service for external management of user identities. Steps to integrate your AD/LDAP service: Configure your AIStor cluster for AD/LDAP integration. Access the AIStor console with AD/LDAP credentials. Generate temporary credentials for application access with the AssumeRoleWithLDAPIdentity Security Token Service (STS) API See the documentation for your AD/LDAP provider for detailed information about configuring user identities. Prerequisites Access to AISor Cluster

AIStor server-side bucket replication is an automatic bucket-level configuration that synchronizes objects between a source and destination bucket. AIStor server-side replication requires the source and destination bucket be two separate AIStor clusters running the same Object Store version. For each write operation to the bucket, AIStor checks all configured replication rules for the bucket and applies the matching rule with highest configured priority. AIStor synchronizes new objects and object mutations, such as new object versions or changes to object metadata. This includes metadata operations such as enabling or modifying object locking or retention settings.

An object is binary data, such as images, audio files, spreadsheets, or even binary executable code. The term “Binary Large Object” or “blob” is sometimes associated to object storage, although blobs can be anywhere from a few bytes to several terabytes in size. Object Storage platforms like AIStor provide dedicated tools and capabilities for storing, listing, and retrieving objects using a standard S3-compatible API. AIStor Object Storage uses buckets to organize objects. A bucket is similar to a top-level drive, folder, or directory in a filesystem (/mnt/data or C:\), where each bucket can hold an arbitrary number of objects.

This procedure provides guidance for enabling Server-Side Encryption (SSE) using AIStor Key Manager as the Key Management Service (KMS). Enabling SSE on an AIStor deployment automatically encrypts the backend data for that deployment using the default encryption key selected during the setup process. AIStor requires access to the Key Manager to decrypt the backend and start normally. You can neither disable nor reset encryption of the backend.

The AIStor Batch Framework allows you to create, manage, monitor, and execute jobs using a YAML-formatted job definition file (a “batch file”). The batch jobs run directly on the AIStor server to take advantage of the server-side processing power without constraints of the local machine where you run the AIStor Client. The expire batch job applies Automatic Object Expiration behavior to a single bucket. The job determines expiration eligibility based on the provided configuration, independent of any configured expiration rules.

This tutorial deploys AIStor onto Kubernetes distributions that follow the upstream API and functionality. The steps in this procedure may work on forked Kubernetes distributions. This procedure requires the installation of Kubernetes operators and associated resources including CustomResourceDefinitions, Statefulsets, and secrets into new or existing namespaces. You must perform the operations in this procedure as a user that has broad permissions to create resources within multiple namespaces. Deploy AIStor using Helm This procedure documents installation on Kubernetes with the AIStor Helm Charts.

AIStor supports publishing bucket notification events to a MySQL service endpoint. AIStor supports MySQL 5.7.8 and later only. Prerequisites MySQL 5.7.8 and later AIStor relies on features introduced with MySQL 5.7.8. The AIStor mc command line tool This procedure uses the mc command line tool for certain actions. See the mc Quickstart for installation instructions.

AIStor supports publishing audit logs to one or more configured remote webhook receivers. AIStor send an event for each API operation to the receiver for processing and storage. The receiver is responsible for correctly processing events, including returning 200OK or similar success messages upon receipt of the event. AIStor cannot recover events that were successfully sent but not correctly stored on the receiver. You can configure a new HTTP audit webhook endpoint using either environment variables or runtime configuration settings:

AIStor supports publishing bucket notification events to a AMQP 0-9-1 service endpoint such as RabbitMQ. Prerequisites AMQP 0-9-1 service endpoint. AIStor relies on the https://github.com/streadway/amqp project for AMQP connectivity. The project is primarily tested against RabbitMQ deployments, though other AMQP 0-9-1-compatible services may also work. This procedure assumes a RabbitMQ deployment using the 0-9-1 protocol as the service endpoint.

Creates a new policy on the target AIStor deployment. AIStor deployments include the following built-in policies by default: consoleAdmin readonly readwrite diagnostics writeonly Syntax Example Consider the following JSON policy document saved at a file called /tmp/listmybuckets.json: