Re: Access Security Config File (ACF) size?

["Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>]

Ah, those PVs may have to connect via CA though, which would be a problem if you’re aiming to only run PVA servers on your IOCs. They do work through the IOCs local CA short-circuit connector, but I don’t know if your IOC configuration allows that — do any other PVA-only sites have experience with AS access to PVs through local CA links if RSRV is disabled?

- Andrew

-- 

Complexity comes for free, Simplicity you have to work for.

On 4/22/26, 11:10 AM, "David Bracey" <dbracey at fnal.gov> wrote:

This Message Is From an External Sender

This message came from outside your organization.

 

>> If you’re going to give each record its own ASG you would need to have a separate file for each IOC …

 

That was just an extreme example for the sake of discussion – I’m sure we won’t do that …

 

>> I assume you know that rules can use PV values to control whether they are enabled or not; that’s how

>> you should try to configure dynamic access changes if possible, reloading a large ACF isn’t something I’d want to be doing very often.

 

That seems pretty promising, thanks!

 

From: Johnson, Andrew N. <anj at anl.gov>
Date: Wednesday, April 22, 2026 at 11:01 AM
To: David Bracey <dbracey at fnal.gov>, Anders Lindh Olsson <anders.lindholsson at ess.eu>, tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Access Security Config File (ACF) size?

Hi David,

 

We try to share ACF files amongst all the IOCs that implement a subsystem, and as you suggest we do load them from an NFS share. For example all our vacuum IOCs in the storage ring would load the same file, since the same people need the same access rights to all of those IOCs. We currently have around 70 ACF files for the whole of the APS accelerator (~2,300,000 records), although many of the older IOCs don’t enable access security.

 

The only limits for the IOC on the size of the file are going to be how much memory it takes to store the data, and how long it takes to parse it (I’m not sure if the server disables I/O or new connections while it’s reloading the file). If you’re going to give each record its own ASG you would need to have a separate file for each IOC instead of sharing them, just to minimize how long a reload takes. There is a hash table in asLib used for doing lookups by name, but it looks like that currently gets initialized with only 256 buckets. For performance you would want to increase that if you’re going to load more than about a thousand named groups (UAG+HAG+ASG).

 

I assume you know that rules can use PV values to control whether they are enabled or not; that’s how you should try to configure dynamic access changes if possible, reloading a large ACF isn’t something I’d want to be doing very often.

 

HTH,

 

- Andrew

 

-- 

Complexity comes for free, Simplicity you have to work for.

 

On 4/22/26, 10:17 AM, "Tech-talk" <tech-talk-bounces at aps.anl.gov> wrote:

 

It seems to me that managing the ACF (or ACFs) is straightforward, since these can be centrally located (on some network share, where IOC’s can read them).

 

The hard part is the association of ASG to DB record, since these are declared with the record instances on the IOC.  Since these are scattered at your edge, they are more difficult to manage or audit.

 

I would think a strategy that required the ASG <-> record association to change as rarely as possible, and instead favored modifying the ACF(s) and telling IOC’s to reload would be desired.

 

From: Anders Lindh Olsson <anders.lindholsson at ess.eu>
Date: Wednesday, April 22, 2026 at 9:43 AM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>, David Bracey <dbracey at fnal.gov>
Subject: Re: Access Security Config File (ACF) size?

[EXTERNAL] – This message is from an external sender

Hi Dave,

 

We use a singular ACF file at ESS, and we currently have around ~10 M records in production. It has not really been a problem thus far, but we also do not (yet?) have many conditionals in the file.

 

When we decided on the approach, we weighed between per-IOC and global and centralised. One of the main concerns for per-IOC was traceability - doing pvget MY-PV.ASG will not be very helpful.

 

 

Cheers

A

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of David Bracey via Tech-talk <tech-talk at aps.anl.gov>
Sent: 22 April 2026 16:19
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Access Security Config File (ACF) size?

 

Does anyone have a feel for how large an ACF could be without becoming problematic?

 

Considering an extreme example, if one had ~100000 PVs, and one defined an ASG for each PV, would that be a problem?

 

How big do ACF’s get in the wild?

 

Are there strategies for using multiple ACF’s?

 

• Dave Bracey, Fermilab