<Incomplete, but the existing information is correct>
The agreegated picture is here Seamless Access Deployment Architecture
We have four sites in production currently.
We have one Load balaner, two thiss-js servers, two MDQ servers and one Medata Agreegator & Publisher server per site. They are all virtual machines managed by SUNET but has both geographic and network redundancy.
The relationship between these servers in combination with the services in Fastly are described in below diagrams. More details follow for each of these components further in this documentation.
The number of servers and sites in Beta enviornment are limited but has the same relationship between them as Production.
Knowledge of SUNET's puppet & cosmos structure https://wiki.sunet.se/display/sunetops/Cosmos
Fastly is CDN (content delivery network) provider. We use CDN to provide greater rechability by take advantage of their cache nodes spread all over the world.
Services that are hosted in Fastly are
The configuration of these services reside here https://manage.fastly.com/services/all
https://docs.fastly.com/en/guides/checking-cache, curl -I -H"Fastly-debug:1" https://service.seamlessaccess.org |
curl -s "https://api.fastly.com/content/edge_check?url=https://service.seamlessaccess.org/990.js" -H 'Fastly-Key:xxx' |
https://wiki.sunet.se/pages/viewpage.action?pageId=83493119
The servers with the name meta.*seamlessaccess.org run PyFF (https://pyff.io) in production environment. In Beta & Staging they are named a-*.thiss.io.
PyFF is short for python Federation Feeder - is a simple SAML metadata aggregator
In this environment, PyFF aggregates metadata from 3 federations - SWAMID, EduGAIN, InCommon & OpenAthens and publish them under /var/www/html/ using the script /usr/local/sbin/run-pyff running as a cronjob.
# Puppet Name: publish */30 * * * * /usr/local/bin/scriptherder --mode wrap --syslog --name publish -- /usr/local/sbin/run-pyff /opt/pyff/mdx.fd /var/www/html/metadata.json /var/www/html/metadata_sp.json |
They aggreagate 'general' metadata in /var/www/html/metadata.json and SP trust metadata in /var/www/html/metadata_sp.json. They are created every 30 minutes by running PyFF in a docker container momentarily.
The script also checks manually the fingerprint on the metadata and PyFF does the same thing again.
Read details about the sources and certificates of federation metadata in SeamlessAccess Metadata Feeds.
The servers also runs Apache in a docker container service called sunet-md_publisher to expose and publish the metadata JSON files on port 443 which are accisible only by the servers running MDQ (md-*.seamlessaccess.org) belonging to the same site.
We monitor ages of all the metadata files in https://monitor.seamlessaccess.org/nagios3/. They are
/opt/pyff/metadata//var/www/html/metadata.json/var/www/html/metadata_sp.json.Take help of the 'Description & Troubleshooting' section to troubleshoot the alarms.
sunet-md_publisher are upgraded by chaging the versions in thiss-ops/global/overlay/etc/puppet/cosmos-rules.yaml. The puppet manifests for production, beta and staging are separate. thiss::pyff_prod:
pyff_version: 2.1.3
output: /var/www/html/metadata.json
output_trust: /var/www/html/metadata_sp.json
thiss::md_publisher_prod:
watch: /var/www/html/metadata.json
watch_sp: /var/www/html/m |
sunet-md_publisher if you have upgraded the metdata publishing service.d-*.seamlessaccess.org should be able to fetch the metadata from the Aggregator & Publisher servers. Make sure it is all 'green' for those servers too./usr/local/bin/get_metadata.sh and see that they are able to fetch metadata files without any issues.The servers with the name md-.*seamlessaccess.org run thiss-mdq in production environment. In Beta & Staging they are named md-*.thiss.io.
The code for thiss-mdq lives here https://github.com/TheIdentitySelector/thiss-mdq.
The aggregator servers running PyFF expose their port 443 to MDQ servers. They run a cronjob that checks to see if there are changes in the metadata JSON files in the Aggregator servers, if there is, it updates the file in the docker container running thiss-mdq and restart it. The script also does a pre-check to see if the fetched metadata files are empty or not, if empty, it won't restart and risk exposing empty metadatas.
# Puppet Name: thiss__mdq_prod_fetch_metadata */5 * * * * /usr/local/bin/scriptherder --mode wrap --syslog --name thiss__mdq_prod_fetch_metadata -- /usr/local/bin/get_metadata.sh |
The MDQ is a REST-like API for requesting and receiving arbitrary metadata. It exposes the metadata in the URL https://md.seamlessaccess.org/entities. The URL for beta is https://md.thiss.io/entities.
The servers run the MDQ service on port 80 which is open to the HAproxy load balancers with names md.*.seamlessaccess.org belonging to the same site.
We monitor the date when the metadata JSON files are last modified in both monitor.seamlessaccess.org and nagiosxi.nordu.net. The check warns if the metadata is 2 days old, it becomes critical if it is 2 days old.
We have this check on MDQ servers, HAproxy Load balancer server and on the top domain which is https://md.seamlessaccess.org.
A simple check on the URLs on each level will show information about the metadata. The one on MDQ server level can only be run locally from that server or from the HAproxy server belonging to the same site.
➜ ~ curl https://md.seamlessaccess.org
{"version":"1.5.8","start_time":"2025-11-22T00:35:20.300Z","metadata":{"last_modified":"2025-11-22T14:15:02.808Z","last_created":"2025-11-22T14:15:02.808Z","size":17502},"trust_metadata":{"last_modified":"2025-11-22T14:15:02.952Z","last_created":"2025-11-22T14:15:02.952Z","size":156}}%
➜ ~ curl -k https://md.ntx.sunet.eu.seamlessaccess.org
{"version":"1.5.8","start_time":"2025-11-22T00:35:03.460Z","metadata":{"last_modified":"2025-11-22T14:15:02.125Z","last_created":"2025-11-22T14:15:02.125Z","size":17502},"trust_metadata":{"last_modified":"2025-11-22T14:15:02.212Z","last_created":"2025-11-22T14:15:02.212Z","size":156}}%
: 14:19 root@md-1: ~ # curl -k http://localhost
{"version":"1.5.8","start_time":"2025-11-22T00:35:05.392Z","metadata":{"last_modified":"2025-11-22T14:15:03.281Z","last_created":"2025-11-22T14:15:03.281Z","size":17502},"trust_metadata":{"last_modified":"2025-11-22T14:15:03.409Z","last_created":"2025-11-22T14:15:03.409Z","size":156}} |
SeamlessAccess HAproxy Upgrade
Almost all services run in docker containers. They are addes as systemd units. The names start with sunet-*.
journalctl -fu <service name of the system unit> /var/log/syslog for older logsdocker logs -f <docker container name>service <service name of the system unit> restartFor deeper troubleshooting knowledge of SUNET's puppet & cosmos structure is needed as mentioned in the Prerequisites section above.
The puppet manifests that deploy and manage the internal components are found here https://github.com/TheIdentitySelector/thiss-ops/tree/master/global. Those who have write acces to it are mentioned here https://wiki.sunet.se/pages/viewpage.action?pageId=83493119
add details
SeamlessAccess SUNET INFRA cert update
https://wiki.sunet.se/pages/viewpage.action?pageId=83493119
https://wiki.sunet.se/display/sunetops/Monitoring