title: srec_trs80(5)

summary: Radio Shack TRS\[hy]80 object file format specification

text:
# srec_trs80(5)

## NAME
srec_trs80 - Radio Shack TRS‐80 object file format specification

## DESCRIPTION
This document describes the binary object file format for the Z80‐based Radio Shack TRS‐80 microcomputers, such as the Model I, II, III, 4, 4D, and 4P. The binary format is generated by the disk‐based Assembler/Editor, and used for TRS‐DOS program files.

The object file is blocked into records, each of which contains the record type, length, and payload data. For Data and End of File records, the payload starts with two bytes of address in little‐endian format. There are four main types of records that are defined. The record types are:

•

Data Record

•

End of File Record with Execution Transfer

•

End of File Record without Execution Transfer

•

Comment

•

Start Linear Address Record (32‐bit format only)

### General Record Format
Record Type

Record Length

Load Address

Data

Record Type.

Each record begins with a single byte Record Type field which specifies the record type of this record. The Record Type field is used to interpret the remaining information within the record. This field is one byte, represented as two hexadecimal characters. The encoding for all the current record types are: 1

Data Record

2

End of File Record with Execution Transfer

3

End of File Record without Execution Transfer

5

Comment Record

Record Length

Each record has a single byte Record Length field which specifies the number of bytes of information or data which follows the Record Length field of the record. The maximum value of the Record Length field is hexadecimal “FF” or 255. In the case of Data Records only, Record Length byte values of zero to two are considered to be lengths of 256 to 258, respectively.

Address

Data and End records have a two‐byte Address field in little‐endian byte order. For Data records, this is the starting address at which to load the remaining payload of the record. In End records, this is the address for the start of execution of the file, or zero if not applicable.

Data

Each record has a variable length Data field, it consists of zero or more bytes. The interpretation of this field depends on the Record Type field.

## REFERENCE
This information comes from the "Program Files" section of TRSDOS‐II Reference Manual, Tandy Corporation, 1982.

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


package: srecord

title: srec_vmem(5)

summary: vmem file format

text:
# srec_vmem(5)

## NAME
srec_vmem - vmem file format

## DESCRIPTION
This format is the Verilog VMEM format. This is a hex format suitable for loading into Verilog simulations using the $readmemh call.

The text file to be read shall contain only the following:

White space (spaces, new lines, tabs, and form‐feeds)

Comments (both types of C++ comment are allowed)

Hexadecimal numbers

White space and/or comments shall be used to separate the numbers.

In the following discussion, the term "address" refers to an index into the array that models the memory.

As the file is read, each number encountered is assigned to a successive word element of the memory. Addressing is controlled both by specifying start and/or finish addresses in the system task invocation and by specifying addresses in the data file.

When addresses appear in the data file, the format is an "at" character (@) followed by a hexadecimal number as follows:

```
@hh...h
```

Both uppercase and lowercase digits are allowed in the number. No white space is allowed between the @ and the number. As many address specifications as needed within the data file can be used. When the system task encounters an address specification, it loads subsequent data starting at that memory address.

### Commentary
There is no checksum in this format, which can generate false positives when guessing file formats on input.

There is no indication of the word size in the file, since it is dependent on the word type of the Verilog memory it is being read into. SRecord will guess the word size based on the number of digits it sees in the numbers, but this is only a guess.

SRecord will also assume that the numbers are to be loaded big‐endian; that is, most significant byte (first byte seen) into the lowest address covered by the word.

You can use the -byte‐swap filter to change the byte order; it takes an optional width of bytes to swap within.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.9 times (32‐bit), 3.1 times (16‐bit) or 3.6 times (8‐bit) when represented with this format.

## EXAMPLE
Here is an example Verilog VMEM file. It contains the data “Hello, World[rq] to be loaded at address 0x1000.

```
@00000400 48656C6C 6F2C2057 6F726C64 0AFFFFFF
```

## REFERENCE
IEEE P1364‐2005/D2, Standard for Verilog Hardware Description Language (Draft), section 17.2.8 "Loading memory data from a file", p. 295.

Copyright © 2003 IEEE

http://www.boyd.com/1364/

http://www.boyd.com/1364/1364‐2005‐d2.pdf.gz

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_wilson(5)

summary: wilson file format

text:
# srec_wilson(5)

## NAME
srec_wilson - wilson file format

## DESCRIPTION
This is a mystery format, added to support a mysery EPROM loader used by Alan Wilson <dvdsales@dvdlibrary.co.uk>

If you know the true name of this format, please let me know! It bears a remarkable similarity to the Motorola S‐Record format, however I can find no reference to a "compressed" Motorola format.

### The Lines
Each line contains normal ASCII characters, and “high bit on[rq] characters, but the ASCII control characters are avoided (the high‐bit‐on con characters are not avoided). Normal line termination characters (CRLF or LF, depending on your system) are used.

The presence of high‐bit‐on characters makes this format unattractive to send via email, as it must be wrapped as a binary attachment, increasing its size.

In general, a single byte per byte is used to encode values, however some values use two bytes, according to the following table:

Byte Value

Encoding (1 or 2 chars)

0x00 .. 0x9F

0x40 .. 0xDF

0xA0 .. 0xAF

0x3A 0x30 .. 0x3A 0x3F

0xB0 .. 0xBF

0x3B 0x30 .. 0x3B 0x3F

0xC0 .. 0xCF

0x3C 0x30 .. 0x3C 0x3F

0xD0 .. 0xDF

0x3D 0x30 .. 0x3D 0x3F

oxE0 .. 0xFF

0xE0 .. 0xFF

The rest of this description, when refering to “bytes[rq] means byte values encoded using the above table.

### The Fields
Each line consists of 5 fields. These are the type field, length field, address field, data field, and the checksum.

Type

Record Length

Address

Data

Checksum

Type

The type field is a 1 character field that specifies whether the record is data (0x43), or termination (0x47).

Record Length

The record length field is a 1 byte field that specifies the number of bytes in the record, excluding the type and record length fields.

Address

This is a 4‐byte address that specifies where the data is to be loaded into memory.

Data

The data field contains the executable code, memory‐loadable data or descriptive information to be transferred.

Checksum

The checksum is an 1‐byte field that represents the least significant byte of the one's complement of the sum of the values represented by the bytes making up the length, address, and data fields.

### Record Types
0x43 (#)

A record containing data and the 4‐byte address at which the data is to reside.

0x47 (')

A termination record. The address field may contain the 4‐byte address of the instruction to which control is passed. There is no data field.

### Size Multiplier
In general, binary data will expand in sized by approximately 1.5 times when represented with this format.

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srp_daemon.service(5)

text:
# srp_daemon.service(5)

## NAME
srp_daemon.service - srp_daemon systemd service that controls all ports

## SYNOPSIS
srp_daemon.service

## DESCRIPTION
The srp_daemon.service controls whether or not any srp_daemon processes are running. Although no srp_daemon processes are controlled directly by the srp_daemon.service, this service controls whether or not any srp_daemon_port@.service are allowed to be active. Each srp_daemon_port@.service controls one srp_daemon process.

## SEE ALSO
srp_daemon(1), srp_daemon_port@.service(5), systemctl(1)


title: srp_daemon_port@.service(5)

text:
# srp_daemon_port@.service(5)

## NAME
srp_daemon_port@.service - srp_daemon_port@ systemd service that controls a single port

## SYNOPSIS
srp_daemon_port@.service

## DESCRIPTION
The srp_daemon_port@.service controls whether or not an srp_daemon process is monitoring the RDMA port specified as template argument. The format for the RDMA port name is dev:port where dev is the name of an RDMA device and port is an port number starting from one. Starting an instance of this template will start an srp_daemon process. Stopping an instance of this template will stop the srp_daemon process for the specified port. It can be prevented that srp_daemon is started for a certain port by masking the corresponding systemd service, e.g. systemctl mask srp_daemon_port@mlx4_0:1.

A list of all RDMA device and port number pairs can be obtained e.g. as follows:

```
$ (cd /sys/class/infiniband >&/dev/null && for p in */ports/*; do

   [ -e "$p" ] && echo "${p/\/ports\//:}"; done)
mlx4_0:1
mlx4_0:2
mlx4_1:1
mlx4_1:2
```

```

```

## SEE ALSO
srp_daemon(1), srp_daemon.service(5), systemctl(1)


package: sssd

title: sss_rpcidmapd(5)

text:
# sss_rpcidmapd(5)

## NAME
sss_rpcidmapd - sss plugin configuration directives for rpc.idmapd

## CONFIGURATION FILE
rpc.idmapd configuration file is usually found at /etc/idmapd.conf. See idmapd.conf(5) for more information.

## SSS CONFIGURATION EXTENSION

### Enable SSS plugin
In section “[Translation]”, modify/set “Method” attribute to contain sss.

### [sss] config section
In order to change the default of one of the configuration attributes of the sss plugin listed below you will need to create a config section for it, named “[sss]”.

Configuration attributes

memcache (bool)

Indicates whether or not to use memcache optimisation technique. Default: True

## SSSD INTEGRATION
The sss plugin requires the NSS Responder to be enabled in sssd.

The attribute “use_fully_qualified_names” must be enabled on all domains (NFSv4 clients expect a fully qualified name to be sent on the wire).

## EXAMPLE
The following example shows a minimal idmapd.conf which makes use of the sss plugin.

```
[General]
Verbosity = 2
# domain must be synced between NFSv4 server and clients
# Solaris/Illumos/AIX use "localdomain" as default!
Domain = default
[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody
[Translation]
Method = sss
```

## SEE ALSO
sssd(8), idmapd.conf(5)

## AUTHORS
Noam Meltzer

Primary Data Inc.

Developer (2013-2014)

Noam Meltzer <tsnoam@gmail.com>

Developer (2014-)


sssd-session-recording

title: sssd-session-recording(5)

summary: Configuring session recording with SSSD

text:
# sssd-session-recording(5)

## NAME
sssd-session-recording - Configuring session recording with SSSD

## DESCRIPTION
This manual page describes how to configure sssd(8) to work with tlog-rec-session(8), a part of tlog package, to implement user session recording on text terminals. For a detailed configuration syntax reference, refer to the “FILE FORMAT” section of the sssd.conf(5) manual page.

SSSD can be set up to enable recording of everything specific users see or type during their sessions on text terminals. E.g. when users log in on the console, or via SSH. SSSD itself doesn't record anything, but makes sure tlog-rec-session is started upon user login, so it can record according to its configuration.

For users with session recording enabled, SSSD replaces the user shell with tlog-rec-session in NSS responses, and adds a variable specifying the original shell to the user environment, upon PAM session setup. This way tlog-rec-session can be started in place of the user shell, and know which actual shell to start, once it set up the recording.

## CONFIGURATION OPTIONS
These options can be used to configure the session recording.

scope (string)

One of the following strings specifying the scope of session recording: "none"

No users are recorded.

"some"

Users/groups specified by users and groups options are recorded.

"all"

All users are recorded.

Default: "none"

users (string)

A comma-separated list of users which should have session recording enabled. Matches user names as returned by NSS. I.e. after the possible space replacement, case changes, etc. Default: Empty. Matches no users.

groups (string)

A comma-separated list of groups, members of which should have session recording enabled. Matches group names as returned by NSS. I.e. after the possible space replacement, case changes, etc. NOTE: using this option (having it set to anything) has a considerable performance cost, because each uncached request for a user requires retrieving and matching the groups the user is member of.

Default: Empty. Matches no groups.

exclude_users (string)

A comma-separated list of users to be excluded from recording, only applicable with 'scope=all'. Default: Empty. No users excluded.

exclude_groups (string)

A comma-separated list of groups, members of which should be excluded from recording. Only applicable with 'scope=all'. NOTE: using this option (having it set to anything) has a considerable performance cost, because each uncached request for a user requires retrieving and matching the groups the user is member of.

Default: Empty. No groups excluded.

## EXAMPLE
The following snippet of sssd.conf enables session recording for users "contractor1" and "contractor2", and group "students".

```
[session_recording]
scope = some
users = contractor1, contractor2
groups = students
```

## SEE ALSO
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

## AUTHORS
The SSSD upstream - https://github.com/SSSD/sssd/


sssd-simple

title: sssd-simple(5)

summary: the configuration file for SSSD\*(Aqs \*(Aqsimple\*(Aq access\-control provider

text:
# sssd-simple(5)

## NAME
sssd-simple - the configuration file for SSSD's 'simple' access-control provider

## DESCRIPTION
This manual page describes the configuration of the simple access-control provider for sssd(8). For a detailed syntax reference, refer to the “FILE FORMAT” section of the sssd.conf(5) manual page.

The simple access provider grants or denies access based on an access or deny list of user or group names.

Groups from other domains configured in sssd.conf, even if the simple access provider is used there as well, and groups managed outside of SSSD are not evaluated.

The following rules apply:

•It is not recommended to leave an option empty, it might cause errors. If you want to allow all users, do not specify any `simple_allow_users` or `simple_allow_groups`.

•If any list is provided, the order of evaluation is: allow → deny. This means that any matching deny rule will supersede any matched allow rule.

•If either or both "allow" lists are provided, all users are denied unless they appear in at least one of these lists (OR condition).

•If either or both "deny" lists are provided, all users are granted access unless they appear in at least one of these lists (OR condition).

## CONFIGURATION OPTIONS
Refer to the section “DOMAIN SECTIONS” of the sssd.conf(5) manual page for details on the configuration of an SSSD domain.

simple_allow_users (string)

Comma-separated list of users who are allowed to log in. If this option is specified, all other users are denied unless they are members of groups listed in`simple_allow_groups`.

simple_deny_users (string)

Comma-separated list of users who are explicitly denied access. If this option is specified, these users will be denied regardless of whether they appear in `simple_allow_users` or `simple_allow_groups`. OR Logic Applies: A user will be denied access if they are listed in `simple_deny_users` or if they are a member of a group in `simple_deny_groups`.

simple_allow_groups (string)

Comma-separated list of groups that are allowed to log in. If this option is specified, all other users are denied unless they are explicitly listed in `simple_allow_users`. OR Logic Applies: A user can log in if they are listed in `simple_allow_users` or if they belong to a group in `simple_allow_groups`.

This applies only to groups within this SSSD domain. Local groups are not evaluated.

simple_deny_groups (string)

Comma-separated list of groups that are explicitly denied access. This applies only to groups within this SSSD domain. Local groups are not evaluated. OR Logic Applies: A user will be denied access if they are listed in `simple_deny_users` or if they are a member of any group in `simple_deny_groups`.

This applies only to groups within this SSSD domain. Local groups are not evaluated.

Specifying no values for any of the lists is equivalent to skipping it entirely. Beware of this while generating parameters for the simple provider using automated scripts.

## EXAMPLE
The following example assumes that SSSD is correctly configured and example.com is one of the domains in the [sssd] section. This example shows only the simple access provider-specific options.

```
[domain/example.com]
access_provider = simple
simple_allow_users = user1, user2
simple_deny_users = user3, user4
simple_allow_groups = allowed_group1
simple_deny_groups = denied_group1
```

## NOTES
The complete group membership hierarchy is resolved before the access check, thus even nested groups can be included in the access lists. Please be aware that the “ldap_group_nesting_level” option may impact the results and should be set to a sufficient value. (sssd-ldap(5)) option.

## SEE ALSO
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

## AUTHORS
The SSSD upstream - https://github.com/SSSD/sssd/


sssd-sudo

title: sssd-sudo(5)

summary: Configuring sudo with the SSSD back end

text:
# sssd-sudo(5)

## NAME
sssd-sudo - Configuring sudo with the SSSD back end

## DESCRIPTION
This manual page describes how to configure sudo(8) to work with sssd(8) and how SSSD caches sudo rules.

## CONFIGURING SUDO TO COOPERATE WITH SSSD
To enable SSSD as a source for sudo rules, add sss to the sudoers entry in nsswitch.conf(5).

For example, to configure sudo to first lookup rules in the standard sudoers(5) file (which should contain rules that apply to local users) and then in SSSD, the nsswitch.conf file should contain the following line:

```
sudoers: files sss
```

More information about configuring the sudoers search order from the nsswitch.conf file as well as information about the LDAP schema that is used to store sudo rules in the directory can be found in sudoers.ldap(5).

Note: in order to use netgroups or IPA hostgroups in sudo rules, you also need to correctly set nisdomainname(1) to your NIS domain name (which equals to IPA domain name when using hostgroups).

## CONFIGURING SSSD TO FETCH SUDO RULES
All configuration that is needed on SSSD side is to extend the list of services with "sudo" in [sssd] section of sssd.conf(5). To speed up the LDAP lookups, you can also set search base for sudo rules using ldap_sudo_search_base option.

The following example shows how to configure SSSD to download sudo rules from an LDAP server.

```
[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = EXAMPLE
[domain/EXAMPLE]
id_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
```

It's important to note that on platforms where systemd is supported there's no need to add the "sudo" provider to the list of services, as it became optional. However, sssd-sudo.socket must be enabled instead.

When SSSD is configured to use IPA as the ID provider, the sudo provider is automatically enabled. The sudo search base is configured to use the IPA native LDAP tree (cn=sudo,$SUFFIX). If any other search base is defined in sssd.conf, this value will be used instead. The compat tree (ou=sudoers,$SUFFIX) is no longer required for IPA sudo functionality.

## THE SUDO RULE CACHING MECHANISM
The biggest challenge, when developing sudo support in SSSD, was to ensure that running sudo with SSSD as the data source provides the same user experience and is as fast as sudo but keeps providing the most current set of rules as possible. To satisfy these requirements, SSSD uses three kinds of updates. They are referred to as full refresh, smart refresh and rules refresh.

The smart refresh periodically downloads rules that are new or were modified after the last update. Its primary goal is to keep the database growing by fetching only small increments that do not generate large amounts of network traffic.

The full refresh simply deletes all sudo rules stored in the cache and replaces them with all rules that are stored on the server. This is used to keep the cache consistent by removing every rule which was deleted from the server. However, full refresh may produce a lot of traffic and thus it should be run only occasionally depending on the size and stability of the sudo rules.

The rules refresh ensures that we do not grant the user more permission than defined. It is triggered each time the user runs sudo. Rules refresh will find all rules that apply to this user, check their expiration time and redownload them if expired. In the case that any of these rules are missing on the server, the SSSD will do an out of band full refresh because more rules (that apply to other users) may have been deleted.

If enabled, SSSD will store only rules that can be applied to this machine. This means rules that contain one of the following values in sudoHost attribute:

•keyword ALL

•wildcard

•netgroup (in the form "+netgroup")

•hostname or fully qualified domain name of this machine

•one of the IP addresses of this machine

•one of the IP addresses of the network (in the form "address/mask")

There are many configuration options that can be used to adjust the behavior. Please refer to "ldap_sudo_*" in sssd-ldap(5) and "sudo_*" in sssd.conf(5).

## TUNING THE PERFORMANCE
SSSD uses different kinds of mechanisms with more or less complex LDAP filters to keep the cached sudo rules up to date. The default configuration is set to values that should satisfy most of our users, but the following paragraphs contain few tips on how to fine- tune the configuration to your requirements.

1. Index LDAP attributes. Make sure that following LDAP attributes are indexed: objectClass, cn, entryUSN or modifyTimestamp.

2. Set ldap_sudo_search_base. Set the search base to the container that holds the sudo rules to limit the scope of the lookup.

3. Set full and smart refresh interval. If your sudo rules do not change often and you do not require quick update of cached rules on your clients, you may consider increasing the ldap_sudo_full_refresh_interval and ldap_sudo_smart_refresh_interval. You may also consider disabling the smart refresh by setting ldap_sudo_smart_refresh_interval = 0.

4. If you have large number of clients, you may consider increasing the value of ldap_sudo_random_offset to distribute the load on the server better.

## SEE ALSO
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

## AUTHORS
The SSSD upstream - https://github.com/SSSD/sssd/