Projects | Flyn Computing

gowasmdemo

Thu, 02 Oct 2025 10:15:55 -0400

Overview

This project provides a starting point for web applications written entirely in Go. The client-side portion of the example compiles to WebAssembly.

Downloads

The gowasmdemo project is available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/gowasmdemo

reflectcrud

Sun, 09 Mar 2025 10:07:45 -0400

Overview

Reflectcrud allows for a Go program to interact with an SQL database using reflection. For example, you can create a table in a database by providing only a Go structure that contains a few field tags.

Downloads

The reflectcrud project is available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/reflectcrud

alpine-build

Sat, 09 Jul 2022 09:02:58 -0400

The alpine-build script builds an Alpine disk image from a JSON-encoded definition. See definitions/example.json for one such definition.

The alpine-build project is available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/alpine-build

golatex

Thu, 14 Apr 2022 09:28:26 -0400

Overview

GoLaTeX provides routines for the Go programming language that are helpful when writing code that involves LaTeX.

Downloads

The golatex project is available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/golatex

safe

Thu, 14 Apr 2022 09:28:26 -0400

Overview

Safe provides routines for the Go programming language that sanitize, unmarshal, and marshal input.

Downloads

The safe project is available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/safe

wasm

Thu, 14 Apr 2022 09:28:26 -0400

Overview

Wasm provides routines for the Go programming language that are helpful when writing code that is compiled to WebAssembly.

Downloads

The wasm project is available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/wasm

Aquinas

Thu, 12 Mar 2020 09:02:58 -0400

Aquinas is an interactive learning system that aims to teach computer programming and exploit development. Teachers define programming projects, and students complete the projects and submit their work using Git. Aquinas provides a website that lists the projects and provides a summary of each student’s progress.

A number of goals drove the design of Aquinas:

Allow for projects that involve network programming and exploit development.
Facilitate easy-to-define projects with a consistent specification language.
Ease reuse of projects across many programming languages.
Allow for high-quality assignment instructions.
Provide a web- and Git-based interface to students.
Provide for automated grading and student feedback.
Apply the principle of least privilege and use a type-safe language.

Aquinas dependencies

Building, configuring, and deploying Aquinas requires the following software:

make
GCC, including support for C++ (to build VMs)
A C library suitable for static linking
expect
qemu-system-x86
The Go programming language
The Perl programming language (to build VMs)
The jq JSON parser
Git
An ssh client
LaTeXML and TeX Live
The tidy HTML beautifier
The dig DNS resolver
The Hugo website generator
The wget HTTP utility (to build VMs)
which

Obtaining Aquinas

Download Aquinas using:

git clone --recurse-submodules https://www.flyn.org/git/aquinas

Building Aquinas

Building Aquinas can take a long time. If you prefer to install Aquinas using the binary VM images we provide, then download them from https://www.flyn.org/projects/Aquinas, and skip to the section titled “Configuring and deploying Aquinas.”

Quick check

Run “make deps all”.
Run “(sudo) ./build/httpd -dummy -root www/public/”.

You should now be able to browse to http://localhost/. The dynamic aspects of Aquinas will not work without a full installation, but you should be able to review most of Aquinas’ look and feel using this dummy mode.

Full build

Review aquinas-build.json to facilitate installing Aquinas at your site. The default values should be adequate in most cases.
Run “make deps all vms”. This will build some utilities and the Aquinas VMs.

Configuring and deploying Aquinas

Install your public SSH key the VMs by running “./aquinas-setup-ssh-developer DEVELOPER-HOME/.ssh/id_rsa.pub” with root privileges. (Mounting the VM disk images requires root privileges.)
Install each disk image (e.g., aquinas-git-alpine-x86-64.img) and each domain configuration (e.g., vm-aquinas-git.cfg) so that they can be run by your hypervisor. Edit each domain configuration to suit your needs. (Note that you will need to build a new VM around each disk image if not using Xen.)
Update your DHCP service to provide the correct IP address to each domain. Refer to each domain configuration for the host’s MAC address.
Update your DNS service to provide an appropriate A record for each domain. Refer to each domain configuration for the host’s name.
Start each configured VM.
Use SSH to sign in on each VM to edit /etc/aquinas/aquinas.json. It is likely you will need to modify “domain,” “logServer,” “emailRegex,” “emailRelay,” emailSender," and “emailSenderName.”
Install a certificate and private key in aquinas-www’s /etc/httpd directory, writing them to the files aquinas.cert and aquinas.key, respectively.
Configure syslog-ng on each VM. The /etc/hosts files on aquinas-user and aquinas-target must contain records for the syslog server (which accepts connections on TCP port 6514), as their firewall prohibits DNS queries.
Configure collectd on each VM. The /etc/hosts files on aquinas-user and aquinas-target must contain records for the collectd server (which accepts connections on UDP port 25826), as their firewall prohibits DNS queries.
Add a record for your target host to /etc/hosts on your user host; neither can make DNS requests, as their firewall prohibits DNS queries.
Add a record for your user host to /etc/hosts on your target host.
Add “server [IP of git host]” to /etc/ntpd.conf on www, user, and target.
Edit /etc/config/system on each VM. You might need to adjust the timezone, and you should set the NTP server to the IP address of aquinas-git host on all of the VMs except for aquinas-git. Note that the firewall rules will allow NTP queries from aquinas-user and aquinas-target only to aquinas-git, and these hosts can only reference aquinas-git by its IP address due to the firewall blocking DNS.
On your development computer, run “./aquinas-setup-ssh”.
On aquinas-www, run “sudo -u http aquinas-add-student test PASSWORD ‘Test Account’”. Ensure you select a strong password to replace PASSWORD.
On your development computer, run “./aquinas-add-teacher DEVELOPER-HOME/.ssh/id_rsa.pub”.
Push a projects repository to aquinas-git:/home/teacher/projects.
Push a records repository to aquinas-git:/home/teacher/records.
Push the HTML documents to aquinas-www using make all publish.
On your development computer and from the directory test/, run “./test-all.”

Writing a project

Writing a project is a matter of creating a machine-readable JSON file to define the project and a LaTeX (or Markdown) fragment to instruct students in how to complete the project.

Project definition

Here is the definition of a very simple project named unix. The absence of the checks keyword means that Aquinas will not grade this project. Because languages is set to none, Aquinas will generate no language-specific variants of this project. Perhaps this project could guide the student through an introduction to UNIX without requiring a graded deliverable.

{
        "name": "unix",
	"summary": "An introduction to Unix and the Bourne shell",
        "languages": [ "none" ]
}

Here is another language-agnostic project. This project, git, assumes the completion of unix. Aquinas will take this into account when ordering the list of projects presented to a student. This project provides a check (checks); running the command cat NOTES from the root of the student’s Git repository should print “In case of fire: git commit, git push, and leave the building!” to standard out. (I.e., the file NOTES should exist in the Git repository and it should contain “In case of fire: …”)

The value in the stdout field is this string, base64 encoded (but not depicted in its entirety here). The base64 encoding is to allow such values to contain binary data.

Aquinas will present the string defined in a check’s hint field as part of the feedback it provides upon grading a failed submission.

{
	"name": "git",
	"summary": "An introduction to the Git version control system",
	"languages": [
		"none"
	],
	"prerequisites": [
		"unix"
	],
	"checks": [
		{
			"type": "basic",
			"parameters": {
				"command": "cat NOTES",
				"stdin": null,
				"stdout": "SW4gY2Fz...",
				"stderr": null,
				"exitCode": 0,
				"hint": "Does your NOTES file contain the correct string?"
			}
		}
	]
}

Using a check of kind compare causes Aquinas to evaluate student work in a different way. With compare checks, Aquinas can reveal its test inputs without allowing the student to tailor his solution to a limited test plan. The idea is to use a generator to produce random input that is well-formed with respect to the project definition. Aquinas generates such input, which it provides both to the reference solution and the student submission. If the programs’ outputs match, then Aquinas deems the student submission correct. Otherwise, the student submission is incorrect. A compare check requires the definition of a reference solution along with a program that generates standard input data (genstdin) or a program that generates command-line arguments (gencmdargs). The following example demonstrates a compare check that generates standard input data.

{
	"kind": "compare",
	"parameters": {
		"command": "./project",
		"reference": "projectC.c",
		"genstdin": "generator-project.c"
	}
},

Assume the project processes non-negative integers, read from standard input. The following definition of generator-project.c generates such inputs.

#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>

int main(void)
{
        struct timeval tv;

        gettimeofday(&tv, NULL);
        srand((unsigned int)(tv.tv_sec * tv.tv_usec));
        printf("%d\n", rand());
}

The use of gencmdargs is similar. Aquinas assumes each line printed by this type of generator represents a command-line argument. Aquinas will compile and deploy generators and reference solutions that exist in a project’s directory and are referenced by a compare check.

A student may submit the following project in C or Python. In the case of C, the submission should contain hello.c, and this file should compile to a program that prints “Hello, world\n”. A Python submission should take the form of hello as an executable script (i.e., with shebang). As with the previous example, the value of stdout is base64 encoded to support binary data.

{
	"name": "hello",
	"summary": "Printing to the screen",
	"languages": [
		"C",
		"Python"
	],
	"prerequisites": [
		"git"
	],
	"checks": [
		{
			"type": "basic",
			"parameters": {
				"command": "./hello",
				"stdin": null,
				"stdout": "SGVsbG8sIHdvcmxkIQo=",
				"stderr": null,
				"exitCode": 0
			}
		}
	]
}

The following network project installs a service, defined in network.go, on Aquinas’ target host. A correct solution will interact with this service as the project instructions prescribe to produce the output required by the project’s checks. The value of source minus its extension must match the value of name, and every project must bear a unique port. Note that Aquinas will replace TARGET with the target host’s name when performing this check.

{
	"name": "network",
	"summary": "Programming a TCP/IPv4 client",
	"languages": [
		"C",
		"Go",
		"Python"
	],
	"prerequisites": [
		"hello",
		"variables"
	],
	"checks": [
		{
			"type": "basic",
			"parameters": {
				"command": "./network TARGET 1025",
				"stdin": null,
				"stdout": "...",
				"stderr": null,
				"exitCode": 0
			}
		}
	],
	"services": [
		{
			"source": "service-network.go",
			"port": 1025
		}
	]
}

Adding the following within a particular service’s definition makes the service binary available for download.

        "publish_binary": true

A teacher can also specify flags in a service definition that Aquinas will pass to the compiler when building the service binary:

        "compiler_flags": "-fstack-protector"

When presenting lists of projects, Aquinas will make use of tags for organization. A set of tags augment the language categories:

	"tags": {
		"Exploitation": true
	}

Sometimes it might be useful to directly call functions in a project solution when testing. An altmain statement allows this. For example, if altmain is defined as true for C, Aquinas will compile the submitted program such that the function main2 in the teacher-defined file main2.c serves as the program’s main function.

{
	"name": "functions",
	"summary": "Abstraction and code reuse using functions",
	"languages": [
		"C",
		"Go",
		"Python"
	],
	"prerequisites": [
		"hello",
		"variables"
	],
	"altmain": {
		"C": true,
		"Go": true,
		"Python": true
	},
	"checks": [
		{
			"type": "basic",
			"parameters": {
				"command": "./functions",
				"stdin": null,
				"stdout": "...",
				"stderr": null,
				"exitCode": 0
			}
		}
	]
}

Aquinas supports solution templates, which provide students with a starting point for their solution. In this example, the values of templates should correspond with template files for C, Go, and Python. These files must exists in the same Git repository as this description, and Aquinas will copy them to the students’ variables repositories. If the template value is a directory, then Aquinas will copy all of the files in that directory to the root of the student’s repository.

{
	"name": "variables",
	"summary": "Programming language variables and arithmetic operators",
	"languages": [
		"C",
		"Go",
		"Python"
	],
	"prerequisites": [
		"hello"
	],
	"checks": [
		{
			"type": "basic",
			"parameters": {
				"command": "./variables",
				"stdin": "...",
				"stdout": "...",
				"stderr": null,
				"exitCode": 0
			}
		},
		{
			"type": "basic",
			"parameters": {
				"command": "./variables",
				"stdin": "...",
				"stdout": "...",
				"stderr": null,
				"exitCode": 0
			}
		},
		{
			"type": "basic",
			"parameters": {
				"command": "./variables",
				"stdin": "...",
				"stdout": "...",
				"stderr": null,
				"exitCode": 0
			}
		}
	],
	"templates": {
		"C": "template-variablesC.c",
		"Go": "template-variablesGo.go",
		"Python": "template-variablesPython"
	}
}

Aside from templates, Aquinas supports the following file-related specifications. Each of these name an array of strings:

files: Causes grader to place files in student's submission directory after cloning it, possibly overwriting what is already there
user_files: Places files in /usr/libexec/aquinas/files/PROJECT on aquinas-user, making them available to the grader
service_files: Places files in /usr/libexec/aquinas/services/PROJECT on aquinas-target, making them available to the target service
service_links: Set up a link on aquinas-target from the given path outside the service chroot to inside of the service chroot
service_chroot_programs: Copies files from outside the target service chroot to inside the target service chroot

Project instructions

Teachers write project instructions in the form of a LaTeX fragment, which Aquinas combines with a template before processing into a HTML document. It is a good practice to use \section* to provide three sections: Command (or Function) summary, Lesson, and Assignment. Aquinas will provide the prelude and epilog material; here it is sufficient to begin with the first \section*.

Aquinas provides the following LaTeX commands for use in a project’s instructions:

\cmd: Typeset the argument as a command.
\project: Typeset the argument as a project name.
\conf: Typeset the argument as a configuration file.
\file: Typeset the argument as a file name.
\dir: Typeset the argument as a directory name.
\fn: Typeset the argument as a function name.
\host: Typeset the argument as a host name.
\keypress: Typeset the argument as if it were a key to be pressed.
\unix: Typeset the work UNIX.
\shprompt: Typeset a Bourne shell prompt.
\cmddesc: Define a command within a LaTeX description list. Like \item, except Aquinas notes occurences of \cmddesc to produce a command reference page.
\fncdesc: Define a C function within a LaTeX description list. Like \item, except Aquinas notes occurences of \fncdesc to produce a C function reference page. Variants exist for other languages such as Go (\fngodesc) and Python (\fnpythondesc).
\ifC: If the language associated with the current project variant matches (here the C variant), then include the subsequent text up until the next \fi. Otherwise print nothing.
\ifshebang: If the language can make use of a shebang, then print the second argument. Otherwise print nothing.
\clone: Provide instructions on how to clone the current project using Git.
\submission: Print instructions on how to submit a project solution.
\submissionNoLanguage: Print instructions on how to submit a language-agnostic project solution.

Alternatively, a teacher can describe a project using Markdown.

The Aquinas VMs

aquinas-www: The HTTP server that allows users to read project assignments and view submission results.
aquinas-git: The Git server to which users make project submissions.
aquinas-user: The host that runs project submissions during the grading process.
aquinas-target: The host that runs network services with which user programs might interact.

System inputs

(unauthenticated) http://aquinas-www/landing.html: Allows a user to either log in or register.
(unauthenticated) http://aquinas-www/login.html: Accepts student email and password. Allows a student to log in to the web interface. Transitions state of HTTP session to authenticated.
(unauthenticated) http://aquinas-www/register.html: Accepts an email address. Allows a registering student to initiate the registration process. Sends an email to the registering student that allows him to complete the registration.
(unauthenticated) http://aquinas-www/register3.html: Accepts an email address, nonce, hashed token, and password. Allows a registering student to prove ownership of an email address and thus complete the registration process.
(authenticated) http://aquinas-www/index.html: Allows a student to select a project page.
(authenticated) http://aquinas-www/p.html, where p is a project: Allows a student to view information that describes project p.
ssh://s@aquinas-git/home/s/p, where s is a student and p is a project: Interact with student s's project p submission using Git/git-shell.
ssh://t@aquinas-git/home/teacher/projects, where t is a teacher: Interact with the project definitions using Git/git-shell. Git hook invokes aquinas-initialize-projects, run as root.
ssh://t@aquinas-git/home/teacher/records, where t is a teacher: Interact with the project submission records using Git/git-shell.
ssh://root@\*: Allows developers shell access.

Sudo permissions

aquinas-git

All users can run grader as teacher
Teacher can run aquinas-initialize-projects as root
Http can run aquinas-add-student-slave as root
Http can run aquinas-get-ssh-authorized-keys as root
Http can run aquinas-deploy-key as root
Http can run aquinas-remove-student-slave as root

SSH keys

root@aquinas-git: generated by alpine-build
teacher@aquinas-git: generated by alpine-build
http@aquinas-www: generated by alpine-build
Developers: installed by hand
Teachers: installed by aquinas-add-teacher
Students: installed by ssh/ssh2.html

Permitted SSH connections

From	To	Installed by	Purpose
Developers	root@aquinas-git	alpine-build/manual	Development/administration
Developers	test@aquinas-git	test case	Pushing solutions during test
Teachers	teacher@aquinas-git	add-teacher	Project deployment
http@aquinas-www	http@aquinas-git	setup-ssh	Httpd uses to run httpsh: check for student check for SSH key add a new student deploy SSH key remove a student
Students	STUDENT@aquinas-git	ssh/ssh2.html	Commit submissions to Git
Developers	root@aquinas-www	alpine-build/manual	Development/administration
Teachers	teacher@aquinas-www	add-teacher	Updating HTML documents
teacher@aquinas-git	teacher@aquinas-www	setup-ssh	Used by grader to update records on aquinas-www
Developers	root@aquinas-user	alpine-build/manual	Development
teacher@aquinas-git	root@aquinas-user	setup-ssh	Used by initialize-project to pull host key and user key from aquinas-user (Cannot use test@, because test has shell set to buildrunsh) Also used by grader to place user-submitted code on aquinas-user
teacher@aquinas-git	teacher@aquinas-user	setup-ssh	Used grader to run reference solution on aquinas-user in the case of compare-type checks
root@aquinas-git	root@aquinas-user	setup-ssh	Add or remove user
root@aquinas-git	teacher@aquinas-user	setup-ssh	Compile network project services
teacher@aquinas-git	STUDENT@aquinas-user	add-student	Grader uses to run buildrunsh on user VM; Git hook runs as user, and uses sudo to run grader as teacher
root@aquinas-git	root@aquinas-target	setup-ssh	Deploy network project services

Component isolation

The design of Aquinas isolates its components to prevent student program from exfiltrating data available to them during the grading process. This prevents student knowledge of the checks that grade their submissions. Furthermore, student programs cannot interact beyond the aquinas-user host with the exception of allowed connections to aquinas-target.

Firewall rules

The host firewalls on aquinas-user and aquinas-target prohibit all outgoing connections with the exception of a connection to a syslog server (TCP port 6514). All interaction with these hosts is by way of incoming SSH connections or project-specific services. The aim of this is to prevent a user-written program from exfiltrating data from either host while executing for the purpose of grading.

Chroot jails

Services on aquinas-target run as the user nobody and within a chroot jail.

Aquinas administation

Manually fork a repository

The following assumes the student is using Aquinas’ native Git repository, rather than a third-party repository such as GitLab. If this is not the case, then you would need to provide more information in the JSON-encoded parameter.

aquinas-fork-project STUDENT@EXAMPLE.COM PROJECT '{"git-provider":"","git-path":"","git-username":"","git-token":""}'

Force the grading of a project

root@aquinas-git> aquinas-enqueue /usr/sbin/grader STUDENT@EXAMPLE.COM PROJECTLANG

Force the grading of a project directly, without using the queuing system

root@aquinas-git> scp -r /home/teacher/workdir/students/STUDENT@EXAMPLE.COM/helloC/ root@aquinas-user.EXAMPLE.COM:/home/STUDENT@EXAMPLE.COM/helloC/
root@aquinas-git> ssh root@aquinas-user.EXAMPLE.COM chown -R STUDENT_at_EXAMPLE_dot_COM:STUDENT_at_EXAMPLE_dot_COM /home/STUDENT@EXAMPLE.COM/helloC
root@aquinas-git> ( echo build; echo \"C\"; cat /home/teacher/workdir/projects/hello/description.json ) | sudo -u teacher ssh -T STUDENT_at_EXAMPLE_dot_COM@aquinas-user.EXAMPLE.COM
Possibly copy files required by project to root@aquinas-user.EXAMPLE.COM:/home/STUDENT@EXAMPLE.COM/helloC/.
root@aquinas-git> ( echo run; echo \"C\"; cat /home/teacher/workdir/projects/hello/description.json ) | sudo -u teacher ssh -T STUDENT_at_EXAMPLE_dot_COM@aquinas-user.EXAMPLE.COM

Rename a user

Note the student’s alias.
Backup the student OLD’s home directory at /home/OLD@EXAMPLE.COM.
On aquinas-www, run sudo -u http aquinas-remove-student OLD@EXAMPLE.COM.
On aquinas-www, run sudo -u http aquinas-add-student NEW@EXAMPLE.COM PASSWORD.
Install SSH key from backup.
Restore student’s alias.
For each repository in the backup, git clone the repository to a temporary location, and from that location run git push repo=NEW_AT_EXAMPLE_DOT_COM@aquinas-git.DOMAIN:/home/NEW@EXAMPLE.COM/PROJECT --all --force.

Mark a user as a teacher

root@aquinas-www> touch /etc/httpd/accounts/USER/teacher
root@aquinas-www> chown http:www-data /etc/httpd/accounts/USER/teacher

Courses as Code: The Aquinas Learning System

W. Michael Petullo

PDF Cite

Downloads

The Aquinas project is also available as a Git repository. To clone the repository, execute

git clone --recurse-submodules https://www.flyn.org/git/aquinas

beamer-control

Thu, 12 Mar 2020 09:02:58 -0400

Overview

Beamer is a LaTeX class for creating slides for presentations. beamer-control allows you to simultaneously control two PDF viewers to synchronize slides—displayed with a projector—and notes—displayed on a laptop screen. beamer-control uses the AT-SPI accessibility framework to communicate with any compatible viewers, such as evince.

Setup (in the case of the Awesome window manager)

Ensure you are running at-spi2-registryd.
Run beamer-control and use xwininfo to identify its window identifier.
Configure Awesome to treat beamer-control as a floating window; write the following to your Awesome configuration, where Beamer Control is the window identifier from the previous step:

awful.rules.rules = {
...
	{ rule = { name="Beamer Control", instance = "python3" }, properties = {floating = true}},
...
}

A workflow

Add the following to your presentation's preamble to ensure every slide has a note, and thus the number of slides and note pages are equal:

\makeatletter
\def\beamer@framenotesbegin{%
	\gdef\beamer@noteitems{}%
	\gdef\beamer@notes{{}}%
}
\makeatother

Add the following to allow building either the slides or notes from the command line:

\ifcsname ifshowOnlyNotes\endcsname\else
\expandafter\let\csname ifshowOnlyNotes\expandafter\endcsname
\csname iffalse\endcsname
\fi

\ifshowOnlyNotes
\setbeameroption{show only notes}
\fi

Build slides with pdflatex presentation.tex.
Build notes with pdflatex --jobname=notes "\let\ifshowOnlyNotes\iftrue\input{presentation}".
Open the slides using evince and place them on one screen in presentation mode.
Open the notes using evince and place them on the other screen in fullscreen mode.
Run beamer-control and place on the notes screen (anywhere but the top-left corner).
Control the presentation by placing the focus on beamer-control and pressing the up or down arrow keys.

Downloads

beamer-control

dmapd

Thu, 12 Mar 2020 09:02:58 -0400

The dmapd project provides a GObject-based, Open Source implementation of DMAP sharing with the following features:

Support for both DAAP and DPAP
Support for realtime transcoding of media formats not natively supported by clients
Support for many metadata formats, such as those associated with Ogg Vorbis and MP3 (e.g., ID3)
Detection of video streams so that clients may play them as video
Use of GStreamer to support a wide range of audio and video CODECs
Caching of photograph thumbnails to avoid regenerating them each time the server restarts

Dmapd runs on Linux and other POSIX operating systems. It has been used on OpenWrt Linux-based systems with as little as 32MB of memory to serve music, video, and photograph libraries containing thousands of files.

Dmapd supports the following command line options:

-?, --help: Show help options
-f, --foreground: Do not fork; remain in foreground
-n, --name: Name of media shares
-m, --music-dir: Music directory
-p, --picture-dir: Picture directory
-M, --music-format: Acceptable music format
-P, --picture-format: Acceptable picture format
-l, --lockpath: Path to lockfile
-i, --pidpath: Path to PID file
-d, --db-dir: Media database directory
-u, --user: User to run as
-g, --group: Group to run as
-t, --transcode-mime-type: Target MIME type for transcoding
-r, --rt-transcode: Perform transcoding in real-time
-w, --max-thumbnail-width: Maximum thumbnail size (may reduce memory use)
-c, --directory-containers: Serve DMAP containers based on filesystem heirarchy

Dmapd supports the following environment variables:

DMAPD_DEBUG: Enable verbose debugging messages
DMAPD_CONFIG_FILE: Path to an alternate configuration file
DMAPD_MODULEDIR: Directory containing dmapd modules
DMAPD_AV_META_READER_MODULE: Name of an alternate AV module
DMAPD_AV_RENDER_MODULE: Name of an alternate AV render module; when applicable may also specify a host, e.g.: DMAPD_AV_RENDER_MODULE=gst:host=192.168.0.1
DMAPD_PHOTO_META_READER_MODULE: Name of an alternate photograph module
DMAPD_DB_MODULE: Name of an alternate database module

Dmapd can provide content to any client that supports DAAP or DPAP. This includes the following software clients and hardware devices:

Apple iTunes™
Apple iPhoto™
Rhythmbox
Roku SoundBridge™

Dmapd can read metadata from any music file supported by GStreamer. In order to use this feature you must have the appropriate GStreamer plugins installed. The following plugins are always required if you wish to use this feature:

app
decodebin
typefindfunctions

The following GStreamer plugins are required for the corresponding media types:

mad (MP3)
id3demux (MP3)
ogg (Ogg Vorbis, etc.)
vorbis (Ogg Vorbis)
flac (FLAC)
mpeg2dec (MPEG video)
theora (Ogg Theora video)

The dmapd project is also available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/dmapd

fctk

Thu, 12 Mar 2020 09:02:58 -0400

Overview

The Flyn Computing Template Kit (fctk) is a collection of fmt-ptrn templates, XSLT templates, and project descriptions. These tools are used at Flyn Computing for development. The collection of templates use XML and the priciple of not repeating oneself. For example, this description comes from an XML file that is used to generate the fctk package's man page, HTML documentation, RPM specification, Debian package specifications, etc.

Nasty Details

Using np with the included project template, gnu_c:

np foo gnu_c

…will create the following directory tree:

.:
AUTHORS    INSTALL      TODO          dry         missing        src
COPYING    Makefile.am  configure.in  include     mkinstalldirs
ChangeLog  NEWS         debian        install-sh  scripts
 
./debian:
changelog  control  copyright  rules
 
./dry:
Makefile.am  foo.xml
 
./include:
Makefile.am
 
./scripts:
Makefile.am
 
./src:
Makefile.am  foo.c

Each file that is created provides a reasonable starting point for a GNU C project. Dry/foo.xml is used by dry/Makefile to create getopt() C code, man pages, etc.

Project directory structure:

xslt: XSLT templates to generate getopt() C code, man pages, HTML documentation, Debian package specifications, RPM specifications, etc. from one XML description.
templates: Templates for use with nf.
projects: Project descriptions for use with np
fctk: Auxillary files which are referenced by some of the other templates. These should go in /etc/fctk/

flyn_docs

Thu, 12 Mar 2020 09:02:58 -0400

Flyn_docs is a set of files which may be used to create letterhead, envelopes, etc. related to Flyn Computing.

fmt-ptrn

Thu, 12 Mar 2020 09:02:58 -0400

Overview

New is a template system, especially useful in conjunction with a simple text editor such as vi. The user maintains templates which may contain format strings. At run time, nf replaces the format strings in a template with appropriate values to create a new file.

For example, given the following template:

//   FILE: %%(FILE)
// AUTHOR: %%(FULLNAME)
//   DATE: %%(DATE)

// Copyright (C) 1999 %%(FULLNAME) %%(EMAIL)
// All rights reserved.

nf will create:

//   FILE: foo.cpp
// AUTHOR: W. Michael Petullo
//   DATE: 11 September 1999

// Copyright (C) 1999 W. Michael Petullo new@flyn.org
// All rights reserved.

on my computer.

The program understands plaintext or gziped template files.

The fmt-ptrn system also provides a shared library which allows a programmer access to nf's functionality. The system was developed to be light and fast. Its only external dependencies are the C library, glib2 and zlib.

Nasty Details

Nf first looks for templates in ~/.fmt-ptrn/templates. Second, nf looks for templates in <datadir>/fmt-ptrn/template, where datadir is defined by autoconf. This directory is usually /usr/local/share or /usr/share.

The templates directory contains several subdirectories matching filename extensions. This may include directories such as html, cpp, c, and tex. Within each subdirectory are the actual template files. The template file named default is the default template used for the filename extension. Other templates can be used by specifying their filename to nf on the command line (see NF(1)).

Certain types of files generally don't have extensions. In this case, nf looks for a template directory with the same name as the file being created. This is useful when using templates to create files with names such as Makefile and README.

When filling a format pattern, nf knows the value for the following format patterns:

DATE: Today's date.
FILE: The name of the file being created.
FULLNAME: The user's full name (from GECOS field).
FIRSTNAME: The user's first name (from GECOS field).
MIDDLENAME: The user's middle name (from GECOS field).
LASTNAME: The user's last name (from GECOS field).
EMPTY_STR: The empty string.

In addition, any environment variable can be used as a format pattern. An alternate string to be used in the case of an environment variable being undefined can be specified as follows:

%(UNDEFINED:foo)

This will be replaced with ”foo” in the created file if UNDEFINED is not a part of one's environment.

The alternative may be a format pattern, too. If FIRSTNAME is defined a Mike, the following:

%(UNDEFINED:%(before="My name is " FIRSTNAME))

will print “My name is Mike.”

A format pattern can also be acted on by a modifier. The following will print the value of FOO in capital letters:

%(upper FOO)

It makes sense to use some modifiers with a literal, instead of a key which will be replaced by a value. For example:

%(file FOO)

will insert the text contained in a the file whose path is the value of the key FOO. But:

%(file "foo")

will insert the contents of the file named foo.

The following modifiers are currently available:

upper: Convert to upper case.
lower: Convert to lower case.
basename: Convert to the basename of a filename.
before="str": Append the string str before.
after="str": Append the string str after.
fn: Tag a " ()" on the end.
c_delim: Print enveloped in a C style deliminator, ie: /* == foo == */.
cpp_delim: Print enveloped in a C++ style deliminator, ie: // == foo.
sh_delim: Print enveloped in a shell script style deliminator, ie: # == foo.
tex_delim: Print eveloped in a LaTeX style deliminator, ie: % == foo.
newlines: Replaces occurrences of " " in the string with new lines
no_newlines: Replaces occurrences of "\n" in the string with ' '
remove_underscore: Replaces occurrences of '_' in the string with '-'
file: Treats the key as the path to a file, which is included
template: Treats the key as the path to a template, which is filled and included
#: A comment, this will not appear in destination file %(# Comment.)

Several modifiers can act within one format string as illustrated:

%(basename upper FOO)

Modifiers use a stack to be applied. The first modifier to be applied is the one farthest to the right. The last to be applied it the one farthest to the left.

gitstats

Thu, 12 Mar 2020 09:02:58 -0400

Gitstats collects statistics about the activity surrounding Git repositories.

The gitstats project is available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/gitstats

guestrace

Thu, 12 Mar 2020 09:02:58 -0400

Ryan Johnson and Matt Shockley wrote guestrace as a prototype for a research project, and we have since packaged it as a stand-alone utility. A properly-configured guestrace will print as they occur the system calls which processes invoke within a Xen domain. This resembles strace, but provides the activity of every running process. The guestrace utility relies on libvmi to perform virtual-machine introspection. Guestrace can trace both Linux and Windows, and it requires no modifications to the target aside from running the target on Xen.

Guestrace also provides a library, libguestrace, which gives programmers access to the guestrace engine. This is useful for programs which must trace system calls and do more than merely print them.

Limitations

As an ongoing research project, guestrace presently has a few limitations in its implementation:

we have not yest tested any version of Windows other than Windows 7 Enterprise with Service Pack 1,
guestrace malfunctions when monitoring Windows running with more than 2 GB of memory (page sizes > 4 KB), and
guestrace supports only 64-bit guest operating systems.

We would be happy to consider any patches which remove these limitations, and we ourselves hope to address them when time permits.

Details

Please refer to guestrace's API documentation for details about how to use the library.

The guestrace project is also available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/guestrace

kodi-plugin.audio.grilo

Thu, 12 Mar 2020 09:02:58 -0400

Kodi-plugin.audio.grilo is an addon for Kodi which provides access to shares supported by Grilo.

kodi-plugin.audio.grilo-0.0.1.tar.gz

The kodi-plugin.audio.grilo project is also available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/kodi-plugin.audio.grilo

lcdgrilo

Thu, 12 Mar 2020 09:02:58 -0400

Overview

Lcdgrilo is a Grilo-based media player for use on a Raspberry Pi with a PiFace CAD. Because it is based on Grilo, lcdgrilo can play media from any Grilo audio source, including DMAP, Jamendo, and Magnatune. The program makes use of the PiFace CAD for input and output through the use of a menu-based interface.

Detailed instructions that describe one way to build a network radio using lcdgrilo, a Raspberry Pi, and a PiFace CAD can be found here.

The lcdgrilo project is also available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/lcdgrilo

lcdringer

Thu, 12 Mar 2020 09:02:58 -0400

Overview

Lcdringer is a ringer for use on a Raspberry Pi with a PiFace CAD. The idea is that the audio ring announces the intention to initiate a video chat. This is useful in households which do not leave their computers or other electronic devices on all of the time.

Lcdringer connects to an XMPP server, listens for messages, and displays messages that arrive before activating an audible alarm. Lcdringer also responds to the messages it receives with an indication of whether or not the audible alarm was acknowledged with a button press.

Upon running, lcdringer reads /etc/lcdringer.conf. Here is an example configuration (replace EXAMPLE.COM, PASSWORD, USER1, and USER2; USER1 and USER2 are the users permitted to cause lcdringer to ring):

[account]
jid=lcdringer@EXAMPLE.COM
password=PASSWORD
ring_path=/usr/share/lcdringer/ring.mp3

[friends]
jids=USER1@EXAMPLE.COM;USER2@EXAMPLE.COM

Detailed instructions that describe one way to build a device using lcdringer, a Raspberry Pi, and a PiFace CAD can be found here.

The lcdringer project is also available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/lcdringer

libdmapsharing

Thu, 12 Mar 2020 09:02:58 -0400

Overview

Libdmapsharing is a library which allows programs to access, share and control the playback of media content using DMAP (DAAP, DPAP & DACP). Libdmapsharing also detects audio AirPlay services; coupled with the AirPlay™ support in PulseAudio or GStreamer, this can allow an application to stream audio to an AirPlay device. The library presently supports Linux and other POSIX-based systems. It is written in C using GObject and libsoup. The DMAP family of protocols are used by products such as Apple iTunes™, Apple iPhoto™, and the Roku SoundBridge™ family to share media such as music and photos.

Possible uses for libdmapsharing include:

Adding picture sharing capabilities to a photograph application
Adding music sharing capabilities to an audio application
Adding audio AirPlay output to an application
Allowing an audio application to be controlled using Apple's iOS Remote
Developing DPAP server software for a home networking product
Developing DMAP client software for a media player appliance
Developing gateways that translate between DMAP and DLNA

Links

The libdmapsharing project is also available as a Git repository. To clone the repository, execute

git clone git://git.gnome.org/libdmapsharing

libtlssep

Thu, 12 Mar 2020 09:02:58 -0400

Overview

Libtlssep (pronounced lib·te̅·el·sep) aims to provide an improved TLS API while also protecting private keys using privilege separation. Libtlssep's architecture includes a helper process called tlssep-decorator which handles all TLS operations and thus is able to isolate private keys from applications. An application first creates a network socket to a server (or client), and then it passes this socket to tlssep-decorator. All subsequent communication with the server passes through tlssep-decorator.

Please refer to libtlssep's API documentation for details about how to use the library.

The libtlssep project is also available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/libtlssep

openwrt-build

Thu, 12 Mar 2020 09:02:58 -0400

The openwrt-build script builds an OpenWrt disk image from a JSON-encoded definition. See definitions/example.json for one such definition.

Aside from example.json, you can provide openwrt-build with a diffconfig definition and one or more directory structures which openwrt-build will add to the disk image. For example,

./openwrt-build -c example.json files/

where files/ contains

etc/dropbear/authorized_keys

will produce an OpenWrt image to which the owner of the public key in authorized_keys can connect using SSH.

You can also specify a post-install script using the ‘-p’ option. The openwrt-build script will arrange for this script to run the first time a VM boots the image.

The default diffconfig causes openwrt-build to build an x86_64 image. You can provide an alternative diffconfig using the ‘-d’ option. See diffconfig/example.

The openwrt-build script also generates a file named vm-[NAME].cfg which defines a Xen domain which will boot the generated disk image. For quick tests, you might also want to run the disk image using QEMU; you can do this by executing:

qemu-system-x86_64 -hda [IMAGE.img] -net nic -net user -m 512 -localtime

The openwrt-build project is available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/openwrt-build

pam_keyring

Thu, 12 Mar 2020 09:02:58 -0400

A component of the GNOME Keyring now includes functionality based on pam_keyring. As a result, pam_keyring is now no longer maintained. See https://gitlab.gnome.org/GNOME/gnome-keyring.

pam_mount

Thu, 12 Mar 2020 09:02:58 -0400

The pam_mount module is now maintained by Jan Engelhardt and is available at http://pam-mount.sourceforge.net/.

Administrator’s Guide to Linux in the Windows Enterprise

Jan 1, 2003

Cite

Downloads

pedansee

Thu, 12 Mar 2020 09:02:58 -0400

Pedansee checks C source files for compliance with a particular programming style. The style is currently defined by the pedansee source code in the form of functions which walk each source file’s syntax tree. You can modify some aspects of this style through the use of regular expressions.

For example, given the following silly program stored at silly.c:

#include <stdio.h>
#include <glib.h>

float pi = 3.14;

static void foo(void)
{
}

int main(int argc, char *argv)
{
	foo();
	g_print("Hello, world!\n");
}

you could run pedansee in the following way, producing the indicated effect:

$ pedansee silly.c -- -I/usr/include/glib-2.0/ -I/usr/lib64/glib-2.0/include/
silly.c:4:7 id pi does not start with silly_
silly.c:6:13 static id silly does not start with '_'
silly.c:6:13 function silly name not on column one
silly.c:10:5 function main name not on column one

Pedansee prefers that silly.c instead contain:

#include <stdio.h>
#include <glib.h>

float silly_pi = 3.14;

static void
_foo(void)
{
}

int
main(int argc, char *argv)
{
	_foo();
	g_print("Hello, world!\n");
}

Pedansee supports configuration files which allow you to configure some aspects of its style. For example, the following pedansee.conf defines the form static, constant, and exported symbols must follow:

[regex]
        const = [A-Za-z_]*
        static = _[A-Za-z_]*
        exported = [^_][A-Za-z_]*

The pedansee project is also available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/pedansee

Pylog

Thu, 12 Mar 2020 09:02:58 -0400

Pylog is a Python module which gives one access to a Prolog interpreter. Pylog simply executes a Prolog interpreter process, communicates with it using pipes, and provides a simple API for communicating with it.

The gocept company has modified Pypvm to work with newer versions of SWI Prolog.

pypvm

Thu, 12 Mar 2020 09:02:58 -0400

Pypvm is a Python module that allows interaction with the Parallel Virtual Machine (PVM) package. PVM allows a collection of computers connected by a network to serve as a single parallel computer.

Pypvm is intended to be an educational and prototyping tool.

Greg Baker has taken over the maintenance of pypvm. One can now find the up to date pypvm source code at http://pypvm.sourceforge.net.

pypvm-0.8.7.tar.gz

SimpleFlow

Thu, 12 Mar 2020 09:02:58 -0400

Overview

SimpleFlow implements a very simple view of information flow within the Linux kernel. (We do not claim to approach the sophistication of IX, HiStar, etc.) We have found the design of SimpleFlow useful in education and certain computer-security competitions, and we are also interested in the use of SimpleFlow to study post-compromise exfiltration and insider threats.

Under SimpleFlow, the system administrator designates some filesystem objects as confidential and some programs as trusted (SimpleFlow stores both using extended attributes). Any process not loaded from a trusted program will become tainted upon reading a confidential object. The kernel transfers this taint status from process to process as a result of inter-process communication (e.g., an untainted process reads from a tainted process over an IPC channel). If a tainted process writes to the network, the kernel sets the packet's RFC 3514 evil bit; this allows for a variety of filtering or spoofing strategies which might help determine the intention of the principal who read the confidential data in the first place.

SimpleFlow Virtual Machine

SimpleFlowDemo-0.3-linux-3.10.0.ova provides in OVA format a virtual machine which contains a SimpleFlow kernel along with a CentOS 7 installation. Some useful SimpleFlow-related commands include:

getfattr -n security.simple-flow.confidential -v true PATH: Set the confidential flag on the file at PATH.
getfattr -x security.simple-flow.confidential PATH: Remove the confidential flag from the file at PATH.
getfattr -n security.simple-flow.trusted -v true PATH: Set the trusted flag on the program at PATH.
getfattr -x security.simple-flow.trusted PATH: Remove the trusted flag from the program at PATH.
ps auxZ: Enumerate the running processes, including whether they are tainted.
echo 1 > /proc/PID/attr/current: Taint the process matching PID.
echo 0 > /proc/PID/attr/current: Untaint the process matching PID.
dmesg -w: Watch SimpleFlow (and other kernel) events.

Studying Naive Users and the Insider Threat with SimpleFlow

Ryan Johnson, Jessie Lass, W. Michael Petullo

PDF Cite

Downloads

The SimpleFlow project is also available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/simple-flow-kernel -b v3.10-simpleflow

speak

Thu, 12 Mar 2020 09:02:58 -0400

Speak provides a simple interface to Festival, a speech synthesis package. The script attempts to detect when EsounD is running and takes advantage of it. Otherwise, speak uses the computer's sound device directly. Speak can be used for tasks such as reading incoming email.

TunesConvert

Thu, 12 Mar 2020 09:02:58 -0400

Overview

TunesConvert is a simple utility that converts an iTunes library into audio files encoded using FLAC. This allows you to move iTunes music to non-Apple devices. TunesConvert is not able to transcode files protected with DRM. For information about iTunes DRM, see the support page on the issue.

TunesConvert uses the GStreamer media framework and relies on plugins provided by the following packages:

gstreamer
gst-plugins-base
gst-plugins-good
gst-plugins-bad

Run TunesConvert, select an output directory, and press “Transcode”.

TunesConvert-0.0.1.tar.gz

VisorFlow

Thu, 12 Mar 2020 09:02:58 -0400

Overview

VisorFlow uses virtual-machine introspection to observe system calls, infer information flow, and control confidential data. Under VisorFlow, the system administrator designates some filesystem objects as confidential and some programs as trusted. Any process not loaded from a trusted program will become tainted upon reading a confidential object. The kernel transfers this taint status from process to process as a result of inter-process communication (e.g., an untainted process reads from a tainted process over a pipe). If a tainted process writes to the network, then the kernel sets the packet’s RFC 3514 evil bit; this permits a variety of filtering or spoofing strategies that might help determine the human intentions involved.

VisorFlow architecture

The figure above depicts the components that make up VisorFlow, including:

the Xen hypervisor;
Linux, running in a Dom0 domain;
one or more DomU domains running Linux or Windows;
the VisorFlow security monitor;
one or more processes running within each DomU;
firewalld;
the VisorFlow network engine;
the VisorFlow Windows authorization engine; and
the VisorFlow Linux authorization engine.

Not pictured here is VisorFlow’s network filter.

Consider process P_n in DomU that invokes a system call (a). The act of invoking a system call normally involves the operating system (b), but here it also involves the hypervisor (c) and the VisorFlow security monitor (d). The VisorFlow security monitor observes such system calls and infers how they allow information to flow between processes, and the security monitor’s operating-system engines use these observations to implement a taint-tracking system that resembles SimpleFlow.

In the case of network system calls, the VisorFlow network engine works with Dom0 and the hypervisor to mark as evil packets originating from tainted processes and to taint processes that receive marked packets. For example, if the Linux engine infers that a system call from a tainted process P_n would result in network traffic, the Linux engine would notify the network engine (e). The network engine in turn adds a network filter rule to the host firewall through firewalld, which has the affect of labeling P_n’s packets as evil (f). The added rule involves instructing NetFilter to rely on VisorFlow to actually set the evil bit using the NFQUEUE interface (g). Later, the Linux engine might infer that P_n exited; when this happens, the Linux engine and network engine will remove the firewall rule that labeled P_n’s packets as evil.

Each operating-system-specific engine implements a different model upon which it relies to make decisions about the system. The models encompass:

which system calls can cause a process to taint,
which system calls can cause an object to become confidential,
which system calls can cause the generation of network packets,
which processes are tainted, and
which objects are confidential (this has to be persistently stored to survive reboots).

This primary advantage of VisorFlow over SimpleFlow is that VisorFlow needs no kernel modifications to operate. This has two important consequences: (1) VisorFlow can mediate closed-source operating systems such as Windows, and (2) VisorFlow avoids difficult-to-maintain modifications to open-source kernels. These advantages come at a performance cost.

By combining aspects of access-control and provenance systems, VisorFlow removes the race conditions found in some provenance systems.

Test VM

After saving the following files to your computer and decompressing them, you can boot the guest using xl create visorflow-guest-linux.cfg. The root password is password.

Disk image: disk.img.gz
Spare disk image: spare.img.gz
Domain configuration (you must modify the paths contained therein to suit your environment): visorflow-guest-linux.cfg

Using VisorFlow to Control Information Flow without Modifying the Operating System Kernel or its Userspace

Matt Shockley, Chris Maixner, Ryan Johnson, Mitch DeRidder, W. Michael Petullo

PDF Cite

Downloads

The VisorFlow project is also available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/visorflow

Projects | Flyn Computing

gowasmdemo

Overview

Downloads

reflectcrud

Overview

Downloads

alpine-build

golatex

Overview

Downloads

safe

Overview

Downloads

wasm

Overview

Downloads

Aquinas

Aquinas dependencies

Obtaining Aquinas

Building Aquinas

Quick check

Full build

Configuring and deploying Aquinas

Writing a project

Project definition

Project instructions

The Aquinas VMs

System inputs

Sudo permissions

aquinas-git

SSH keys

Permitted SSH connections

Component isolation

Firewall rules

Chroot jails

Aquinas administation

Manually fork a repository

Force the grading of a project

Rename a user

Mark a user as a teacher

Related publications

Downloads

beamer-control

Overview

Setup (in the case of the Awesome window manager)

A workflow

Downloads

dmapd

fctk

Overview

Nasty Details

flyn_docs

fmt-ptrn

Overview

Nasty Details

gitstats

guestrace

Limitations

Details

kodi-plugin.audio.grilo

lcdgrilo

Overview

lcdringer

Overview

libdmapsharing

Overview

Links

libtlssep

Overview

openwrt-build

pam_keyring

pam_mount

Related publications

Downloads

pedansee

Pylog

pypvm

SimpleFlow

Overview