tdatudf need not be the primary group for the OS platform user, but that user must be a member of the group. Consult your Linux operating system documentation, as appropriate, for the specific definitions of group, local group, and so on.
The tdatudf group is used by protected mode external routines and must always exist. You can change the tdatudf group assignment for external routines using their EXERNAL SECURITY clause.
The best practice is to make this group serve only the external routines that specify an EXTERNAL SECURITY clause and not use it for any other purpose.
Authentication is automatic as long as the platform nodes are part of the global authentication process. If they are not part of that process, then you must create a local OS user on each node. A local OS user is any user that must be created manually. Local OS users are not associated with a domain.
When you create an external routine that includes an EXTERNAL SECURITY clause, the name of the OS user specified in that clause must be a member of the group tdatudf. The system creates this group by default during the installation of Teradata Database.
The tdatudf group must always exist and must never be altered.
The reason for these restrictions is that Teradata Database always uses the tdatudf group to run protected or secure mode routines.
When an external routine runs in either protected or secure mode, it runs as the OS user associated with its authorization.
In both protected and secure modes, the system sets the platform process up on a PE or AMP vproc as needed to execute the external routine.
You can run a maximum of 20 protected mode servers and 20 secure mode servers per AMP or PE. To clarify, you can run up to 40 “protected” mode servers concurrently per AMP or PE, but not more than 20 each of the protected and secure mode types.
When modifying the cufconfig fields, keep in mind that each protected or secure mode process uses its own private shared memory, which requires private disk swap space. Each process for a routine written in C or C++ requires 256 KB of disk space.
For example, if two protected mode servers are allocated per vproc and there are 8 vprocs on the node, then 4 megabytes of system disk file space are required, as indicated by the following equation.
By substitution, for a system defined with 2 protected mode servers per vproc, 4 MB of disk swap space are required.
For a system defined with 20 protected mode servers per vproc for C and C++ external routines, 40 MB of disk swap space are required.
The system does not allocate space until an external routine is executing that requires the space. If you run 10 sessions, and each one executes a query that uses a UDF at the same instance, then the system creates 10 protected mode servers per vproc.
If, however, the 10 sessions execute the UDF queries sequentially, then only one protected mode process per vproc needs to be created. Once a protected mode server is set up, it remains in existence until the database restarts. If any servers are not used, the system swaps them out to disk, so they do not consume any physical memory resources.
Each Java server for external routines requires roughly 30 MB of memory for swap space, and there can be two such Java servers per node. A Java UDF multithreaded server for non‑secure mode Java UDFs uses a minimum of an additional 30 MB (the amount required can be larger, depending on the size of the JARs for a user), so each node requires approximately 100 MB of swap space if all server flavors are used.