EDURange - User contributions [en]

Team Charter

2026-04-03T21:21:40Z

Jwgranville:

change me!

See https://www.pmi.org/learning/library/team-charter-development-5128 !

Also:

* https://www.atlassian.com/work-management/project-collaboration/team-charter
* https://dschool.stanford.edu/tools/design-project-scoping-guide
* https://ocw.mit.edu/courses/1-040-project-management-spring-2009/
* https://www.nasa.gov/reference/4-1-stakeholder-expectations-definition/

Main Page

2026-04-03T20:42:34Z

Jwgranville: /* The EDURange Project */

Team Charter

2026-03-31T19:24:54Z

Jwgranville:

change me!

See https://www.pmi.org/learning/library/team-charter-development-5128 !

Team Charter

2026-03-31T19:23:51Z

Jwgranville: Created page with "change me!"

change me!

New Version Planning

2026-03-28T16:54:48Z

Jwgranville: /* Functional requirements: */

''As we're still getting started, please feel free to insert notes and comments where you like - just try to avoid changing or deleting things you yourself didn't write. We'll come up with a shared structure as we go. Also consider using the "discussion" tab at the top if you aren't sure where to comment or want to have a dialogue.''

These items at the top are on the agenda for discussion, but don't have a clear place they belong yet:
* POST handler/API reachability
* Chat capability
* Containers
* NSJail, chroot?
* Physical systems: controlled via ordinary SSH, provisioned with PXE or other net boot methods?
* How to model shared resources and contention?
* Staged/prerequisite content in guide/scenario
* How to refer to observation/logging instruments
* How do we assess correctness/domain truth in a model of learning objectives?
** Navigating a filesystem:
*** "Can a student navigate the filesystem?"
**** "Can the student compose an absolute path?"
***** "Does the student use / to begin an absolute path?"
***** "Does the student refer to directories present at the root of the filesystem?"
**** "Do they correctly use find?"
**** "Does the student map correctly between paths and the purposes of the file hierarchy?"
***** "Does the student look for binaries in /bin/?"
**** "Does the student use ~ to refer to their home directory?"
*** What artifacts help to assess this?
*Sample learning objectives:
**Hierarchically: course/domain; module/unit; learning objective; concept/skill cluster; knowledge components; tasks
**Scenario (course): Getting Started
***A learning objective: Students will be able to navigate the filesystem
****Compose paths
****Navigate directories
****Aware of working directory
****Understand path substitutions (~, ., etc.)
****etc...
***A more specific learning objective (or, alternately, a skill cluster): Student will be able to recognize (name) and locate a hidden file in a known directory
****Give filename of the file in question
****Identify the path of the file in question
****Source and provide information about the file, content in the file
****Differentiate between a file that is and isn't hidden
***Task (independent, but linked to learning objectives and knowledge components):
****Find all the files that end in ".gif" using the find command
***Knowledge component (independent, linked to tasks):
****Student uses 'find" when searching files
****Student uses 'ls' to list and examine available files
****Student appropriately applies path prefix (absolute or relative)
****Student composes valid pattern for file extension
*Quality of life:
**Authentication/account naming is a system-wide standard/service
***How does this behave in designs where students are meant to seize other identities?

=== Functional requirements: ===

* 20-300 students simultaneously? Semi-simultaneously? ~150 concurrently, 500+ at large institutions?
* Telemetry layer for instrument/orchestration health
* Students are provided a learning environment that is safe to explore/attack without threatening the application host infrastructure
* Two weeks unattended uptime
* Per-user resource caps configurable per host (if not per-scenario or finer-grained)

=== Ubiquitous language: ===
(See [https://agilealliance.org/glossary/ubiquitous-language/ What is Ubiquitous Language? | Agile Alliance], [https://www.cosmicpython.com/book/preface.html Cosmic Python] or [https://www.domainlanguage.com/ddd/ DDD Resources - Domain Language])
* Scenario
* Learning objectives
** e.g.
*** "Students will be able to use ls to list the contents of a directory"
*** "Students will be able to log in to the exercise via SSH"
** Milestone
*** Do these have sufficient resolution to see why/how students arrived at a correct answer?
** What are indicators of student progress on learning objectives?
*** How do events (such as those matched by milestones) correlate with questions?
**** What are students asking about in help requests?
**** Can we select semantics from log data (commands, chat, questions)?
** How do we know tangibly that a student is completing learning-related tasks?
* Questions (are exercises distinct?)
* Guide
** Guide section
* Student
* Instructor
* Hint
* Intervention
* Prediction
* Learning environment
** Underlying system state?
*** What denotes/distinguishes a command?
* Observability/instrumentation? (Name?)

=== User stories: ===
(Supported use cases, written in terms of the ubiquitous language above)
* '''Instructors''' make '''Scenarios''' available to '''Students'''
* '''Scenarios''' configure the '''Learning Environment''' to support '''Learning Objectives'''
* '''Scenarios''' may include a '''Guide''' to support exercises and tasks in the '''Learning Objectives'''
* The '''Learning Environment''' can offer '''Interventions''' based on '''Student''' performance
* '''Students''' start and stop the '''Learning Environment''' of '''Scenarios''' made accessible to them (the '''Learning Environment''' does not consume resources when not in use)

New Version Planning

2026-03-28T16:52:24Z

Jwgranville: /* User stories: */

''As we're still getting started, please feel free to insert notes and comments where you like - just try to avoid changing or deleting things you yourself didn't write. We'll come up with a shared structure as we go. Also consider using the "discussion" tab at the top if you aren't sure where to comment or want to have a dialogue.''

These items at the top are on the agenda for discussion, but don't have a clear place they belong yet:
* POST handler/API reachability
* Chat capability
* Containers
* NSJail, chroot?
* Physical systems: controlled via ordinary SSH, provisioned with PXE or other net boot methods?
* How to model shared resources and contention?
* Staged/prerequisite content in guide/scenario
* How to refer to observation/logging instruments
* How do we assess correctness/domain truth in a model of learning objectives?
** Navigating a filesystem:
*** "Can a student navigate the filesystem?"
**** "Can the student compose an absolute path?"
***** "Does the student use / to begin an absolute path?"
***** "Does the student refer to directories present at the root of the filesystem?"
**** "Do they correctly use find?"
**** "Does the student map correctly between paths and the purposes of the file hierarchy?"
***** "Does the student look for binaries in /bin/?"
**** "Does the student use ~ to refer to their home directory?"
*** What artifacts help to assess this?
*Sample learning objectives:
**Hierarchically: course/domain; module/unit; learning objective; concept/skill cluster; knowledge components; tasks
**Scenario (course): Getting Started
***A learning objective: Students will be able to navigate the filesystem
****Compose paths
****Navigate directories
****Aware of working directory
****Understand path substitutions (~, ., etc.)
****etc...
***A more specific learning objective (or, alternately, a skill cluster): Student will be able to recognize (name) and locate a hidden file in a known directory
****Give filename of the file in question
****Identify the path of the file in question
****Source and provide information about the file, content in the file
****Differentiate between a file that is and isn't hidden
***Task (independent, but linked to learning objectives and knowledge components):
****Find all the files that end in ".gif" using the find command
***Knowledge component (independent, linked to tasks):
****Student uses 'find" when searching files
****Student uses 'ls' to list and examine available files
****Student appropriately applies path prefix (absolute or relative)
****Student composes valid pattern for file extension
*Quality of life:
**Authentication/account naming is a system-wide standard/service
***How does this behave in designs where students are meant to seize other identities?

=== Functional requirements: ===

* 20-300 students simultaneously? Semi-simultaneously? ~150 concurrently, 500+ at large institutions?
* Telemetry layer for instrument/orchestration health
* Students are provided a learning environment that is safe to explore/attack without threatening the application host infrastructure
* Two weeks unattended uptime
* Per-user resource caps configurable per host (if not scenario/finer-grained)

=== Ubiquitous language: ===
(See [https://agilealliance.org/glossary/ubiquitous-language/ What is Ubiquitous Language? | Agile Alliance], [https://www.cosmicpython.com/book/preface.html Cosmic Python] or [https://www.domainlanguage.com/ddd/ DDD Resources - Domain Language])
* Scenario
* Learning objectives
** e.g.
*** "Students will be able to use ls to list the contents of a directory"
*** "Students will be able to log in to the exercise via SSH"
** Milestone
*** Do these have sufficient resolution to see why/how students arrived at a correct answer?
** What are indicators of student progress on learning objectives?
*** How do events (such as those matched by milestones) correlate with questions?
**** What are students asking about in help requests?
**** Can we select semantics from log data (commands, chat, questions)?
** How do we know tangibly that a student is completing learning-related tasks?
* Questions (are exercises distinct?)
* Guide
** Guide section
* Student
* Instructor
* Hint
* Intervention
* Prediction
* Learning environment
** Underlying system state?
*** What denotes/distinguishes a command?
* Observability/instrumentation? (Name?)

=== User stories: ===
(Supported use cases, written in terms of the ubiquitous language above)
* '''Instructors''' make '''Scenarios''' available to '''Students'''
* '''Scenarios''' configure the '''Learning Environment''' to support '''Learning Objectives'''
* '''Scenarios''' may include a '''Guide''' to support exercises and tasks in the '''Learning Objectives'''
* The '''Learning Environment''' can offer '''Interventions''' based on '''Student''' performance
* '''Students''' start and stop the '''Learning Environment''' of '''Scenarios''' made accessible to them (the '''Learning Environment''' does not consume resources when not in use)

New Version Planning

2026-03-28T16:46:22Z

Jwgranville: /* User stores: */

''As we're still getting started, please feel free to insert notes and comments where you like - just try to avoid changing or deleting things you yourself didn't write. We'll come up with a shared structure as we go. Also consider using the "discussion" tab at the top if you aren't sure where to comment or want to have a dialogue.''

These items at the top are on the agenda for discussion, but don't have a clear place they belong yet:
* POST handler/API reachability
* Chat capability
* Containers
* NSJail, chroot?
* Physical systems: controlled via ordinary SSH, provisioned with PXE or other net boot methods?
* How to model shared resources and contention?
* Staged/prerequisite content in guide/scenario
* How to refer to observation/logging instruments
* How do we assess correctness/domain truth in a model of learning objectives?
** Navigating a filesystem:
*** "Can a student navigate the filesystem?"
**** "Can the student compose an absolute path?"
***** "Does the student use / to begin an absolute path?"
***** "Does the student refer to directories present at the root of the filesystem?"
**** "Do they correctly use find?"
**** "Does the student map correctly between paths and the purposes of the file hierarchy?"
***** "Does the student look for binaries in /bin/?"
**** "Does the student use ~ to refer to their home directory?"
*** What artifacts help to assess this?
*Sample learning objectives:
**Hierarchically: course/domain; module/unit; learning objective; concept/skill cluster; knowledge components; tasks
**Scenario (course): Getting Started
***A learning objective: Students will be able to navigate the filesystem
****Compose paths
****Navigate directories
****Aware of working directory
****Understand path substitutions (~, ., etc.)
****etc...
***A more specific learning objective (or, alternately, a skill cluster): Student will be able to recognize (name) and locate a hidden file in a known directory
****Give filename of the file in question
****Identify the path of the file in question
****Source and provide information about the file, content in the file
****Differentiate between a file that is and isn't hidden
***Task (independent, but linked to learning objectives and knowledge components):
****Find all the files that end in ".gif" using the find command
***Knowledge component (independent, linked to tasks):
****Student uses 'find" when searching files
****Student uses 'ls' to list and examine available files
****Student appropriately applies path prefix (absolute or relative)
****Student composes valid pattern for file extension
*Quality of life:
**Authentication/account naming is a system-wide standard/service
***How does this behave in designs where students are meant to seize other identities?

=== Functional requirements: ===

* 20-300 students simultaneously? Semi-simultaneously? ~150 concurrently, 500+ at large institutions?
* Telemetry layer for instrument/orchestration health
* Students are provided a learning environment that is safe to explore/attack without threatening the application host infrastructure
* Two weeks unattended uptime
* Per-user resource caps configurable per host (if not scenario/finer-grained)

=== Ubiquitous language: ===
(See [https://agilealliance.org/glossary/ubiquitous-language/ What is Ubiquitous Language? | Agile Alliance], [https://www.cosmicpython.com/book/preface.html Cosmic Python] or [https://www.domainlanguage.com/ddd/ DDD Resources - Domain Language])
* Scenario
* Learning objectives
** e.g.
*** "Students will be able to use ls to list the contents of a directory"
*** "Students will be able to log in to the exercise via SSH"
** Milestone
*** Do these have sufficient resolution to see why/how students arrived at a correct answer?
** What are indicators of student progress on learning objectives?
*** How do events (such as those matched by milestones) correlate with questions?
**** What are students asking about in help requests?
**** Can we select semantics from log data (commands, chat, questions)?
** How do we know tangibly that a student is completing learning-related tasks?
* Questions (are exercises distinct?)
* Guide
** Guide section
* Student
* Instructor
* Hint
* Intervention
* Prediction
* Learning environment
** Underlying system state?
*** What denotes/distinguishes a command?
* Observability/instrumentation? (Name?)

=== User stories: ===

* '''Instructors''' make '''Scenarios''' available to '''Students'''
* '''Scenarios''' configure the '''Learning Environment''' to support '''Learning Objectives'''
* '''Scenarios''' may include a '''Guide''' to support exercises and tasks in the '''Learning Objectives'''
* The '''Learning Environment''' can offer '''Interventions''' based on '''Student''' performance
* '''Students''' start and stop the '''Learning Environment''' of '''Scenarios''' made accessible to them (the '''Learning Environment''' does not consume resources when not in use)

New Version Planning

2026-03-27T22:01:33Z

Jwgranville:

''As we're still getting started, please feel free to insert notes and comments where you like - just try to avoid changing or deleting things you yourself didn't write. We'll come up with a shared structure as we go. Also consider using the "discussion" tab at the top if you aren't sure where to comment or want to have a dialogue.''

These items at the top are on the agenda for discussion, but don't have a clear place they belong yet:
* POST handler/API reachability
* Chat capability
* Containers
* NSJail, chroot?
* Physical systems: controlled via ordinary SSH, provisioned with PXE or other net boot methods?
* How to model shared resources and contention?
* Staged/prerequisite content in guide/scenario
* How to refer to observation/logging instruments
* How do we assess correctness/domain truth in a model of learning objectives?
** Navigating a filesystem:
*** "Can a student navigate the filesystem?"
**** "Can the student compose an absolute path?"
***** "Does the student use / to begin an absolute path?"
***** "Does the student refer to directories present at the root of the filesystem?"
**** "Do they correctly use find?"
**** "Does the student map correctly between paths and the purposes of the file hierarchy?"
***** "Does the student look for binaries in /bin/?"
**** "Does the student use ~ to refer to their home directory?"
*** What artifacts help to assess this?
*Sample learning objectives:
**Hierarchically: course/domain; module/unit; learning objective; concept/skill cluster; knowledge components; tasks
**Scenario (course): Getting Started
***A learning objective: Students will be able to navigate the filesystem
****Compose paths
****Navigate directories
****Aware of working directory
****Understand path substitutions (~, ., etc.)
****etc...
***A more specific learning objective (or, alternately, a skill cluster): Student will be able to recognize (name) and locate a hidden file in a known directory
****Give filename of the file in question
****Identify the path of the file in question
****Source and provide information about the file, content in the file
****Differentiate between a file that is and isn't hidden
***Task (independent, but linked to learning objectives and knowledge components):
****Find all the files that end in ".gif" using the find command
***Knowledge component (independent, linked to tasks):
****Student uses 'find" when searching files
****Student uses 'ls' to list and examine available files
****Student appropriately applies path prefix (absolute or relative)
****Student composes valid pattern for file extension
*Quality of life:
**Authentication/account naming is a system-wide standard/service
***How does this behave in designs where students are meant to seize other identities?

=== Functional requirements: ===

* 20-300 students simultaneously? Semi-simultaneously? ~150 concurrently, 500+ at large institutions?
* Telemetry layer for instrument/orchestration health
* Students are provided a learning environment that is safe to explore/attack without threatening the application host infrastructure
* Two weeks unattended uptime
* Per-user resource caps configurable per host (if not scenario/finer-grained)

=== Ubiquitous language: ===
(See [https://agilealliance.org/glossary/ubiquitous-language/ What is Ubiquitous Language? | Agile Alliance], [https://www.cosmicpython.com/book/preface.html Cosmic Python] or [https://www.domainlanguage.com/ddd/ DDD Resources - Domain Language])
* Scenario
* Learning objectives
** e.g.
*** "Students will be able to use ls to list the contents of a directory"
*** "Students will be able to log in to the exercise via SSH"
** Milestone
*** Do these have sufficient resolution to see why/how students arrived at a correct answer?
** What are indicators of student progress on learning objectives?
*** How do events (such as those matched by milestones) correlate with questions?
**** What are students asking about in help requests?
**** Can we select semantics from log data (commands, chat, questions)?
** How do we know tangibly that a student is completing learning-related tasks?
* Questions (are exercises distinct?)
* Guide
** Guide section
* Student
* Instructor
* Hint
* Intervention
* Prediction
* Learning environment
** Underlying system state?
*** What denotes/distinguishes a command?
* Observability/instrumentation? (Name?)

=== User stores: ===

* '''Instructors''' make '''Scenarios''' available to '''Students'''
* '''Scenarios''' configure the '''Learning Environment''' to support '''Learning Objectives'''
* '''Scenarios''' may include a '''Guide''' to support exercises and tasks in the '''Learning Objectives'''
* The '''Learning Environment''' can offer '''Interventions''' based on '''Student''' performance
* '''Students''' start and stop the '''Learning Environment''' of '''Scenarios''' made accessible to them (the '''Learning Environment''' does not consume resources when not in use)

New Version Planning

2026-03-27T22:00:35Z

Jwgranville:

''As we're still getting started, please feel free to insert notes and comments where you like - just try to avoid changing or deleting things you yourself didn't write. We'll come up with a shared structure as we go. Also consider using the "discussion" tab at the top if you aren't sure where to comment or want to have a dialogue.''

These items at the top are on the agenda for discussion, but don't have a clear place they belong yet:
* POST handler/API reachability
* Chat capability
* Containers
* NSJail, chroot?
* Physical systems: controlled via ordinary SSH, provisioned with PXE or other net boot methods?
* How to model shared resources and contention?
* Staged/prerequisite content in guide/scenario
* How to refer to observation/logging instruments
* How do we assess correctness/domain truth in a model of learning objectives?
** Navigating a filesystem:
*** "Can a student navigate the filesystem?"
**** "Can the student compose an absolute path?"
***** "Does the student use / to begin an absolute path?"
***** "Does the student refer to directories present at the root of the filesystem?"
**** "Do they correctly use find?"
**** "Does the student map correctly between paths and the purposes of the file hierarchy?"
***** "Does the student look for binaries in /bin/?"
**** "Does the student use ~ to refer to their home directory?"
*** What artifacts help to assess this?
*Sample learning objectives:
**Hierarchically: course/domain; module/unit; learning objective; concept/skill cluster; knowledge components; tasks
**Scenario (course): Getting Started
***A learning objective: Students will be able to navigate the filesystem
****Compose paths
****Navigate directories
****Aware of working directory
****Understand path substitutions (~, ., etc.)
****etc...
***A more specific learning objective: Student will be able to recognize (name) and locate a hidden file in a known directory
****Give filename of the file in question
****Identify the path of the file in question
****Source and provide information about the file, content in the file
****Differentiate between a file that is and isn't hidden
***Task (independent, but linked to learning objectives and knowledge components):
****Find all the files that end in ".gif" using the find command
***Knowledge component (independent, linked to tasks):
****Student uses 'find" when searching files
****Student uses 'ls' to list and examine available files
****Student appropriately applies path prefix (absolute or relative)
****Student composes valid pattern for file extension
*Quality of life:
**Authentication/account naming is a system-wide standard/service
***How does this behave in designs where students are meant to seize other identities?

=== Functional requirements: ===

* 20-300 students simultaneously? Semi-simultaneously? ~150 concurrently, 500+ at large institutions?
* Telemetry layer for instrument/orchestration health
* Students are provided a learning environment that is safe to explore/attack without threatening the application host infrastructure
* Two weeks unattended uptime
* Per-user resource caps configurable per host (if not scenario/finer-grained)

=== Ubiquitous language: ===
(See [https://agilealliance.org/glossary/ubiquitous-language/ What is Ubiquitous Language? | Agile Alliance], [https://www.cosmicpython.com/book/preface.html Cosmic Python] or [https://www.domainlanguage.com/ddd/ DDD Resources - Domain Language])
* Scenario
* Learning objectives
** e.g.
*** "Students will be able to use ls to list the contents of a directory"
*** "Students will be able to log in to the exercise via SSH"
** Milestone
*** Do these have sufficient resolution to see why/how students arrived at a correct answer?
** What are indicators of student progress on learning objectives?
*** How do events (such as those matched by milestones) correlate with questions?
**** What are students asking about in help requests?
**** Can we select semantics from log data (commands, chat, questions)?
** How do we know tangibly that a student is completing learning-related tasks?
* Questions (are exercises distinct?)
* Guide
** Guide section
* Student
* Instructor
* Hint
* Intervention
* Prediction
* Learning environment
** Underlying system state?
*** What denotes/distinguishes a command?
* Observability/instrumentation? (Name?)

=== User stores: ===

* '''Instructors''' make '''Scenarios''' available to '''Students'''
* '''Scenarios''' configure the '''Learning Environment''' to support '''Learning Objectives'''
* '''Scenarios''' may include a '''Guide''' to support exercises and tasks in the '''Learning Objectives'''
* The '''Learning Environment''' can offer '''Interventions''' based on '''Student''' performance
* '''Students''' start and stop the '''Learning Environment''' of '''Scenarios''' made accessible to them (the '''Learning Environment''' does not consume resources when not in use)

New Version Planning

2026-03-24T20:04:25Z

Jwgranville: /* User stores: */

New Version Planning

2026-03-24T20:01:53Z

Jwgranville: /* User stores: */

New Version Planning

2026-03-24T20:01:17Z

Jwgranville: /* User stores: */

New Version Planning

2026-03-24T19:58:35Z

Jwgranville: /* Ubiquitous language: */

Main Page

2026-02-22T19:01:26Z

Jwgranville: Remove derelict/unpopulated pages and miscategorized/orphaned content

New Version Planning

2026-02-17T19:10:39Z

Jwgranville: /* Functional requirements: */

New Version Planning

2026-01-24T01:34:52Z

Jwgranville: /* Functional requirements: */

New Version Planning

2026-01-24T01:31:05Z

Jwgranville: /* Ubiquitous language: */

New Version Planning

2026-01-24T01:28:38Z

Jwgranville: /* Functional requirements: */

New Version Planning

2026-01-24T01:21:43Z

Jwgranville: /* Ubiquitous language: */

Main Page

2026-01-24T01:18:05Z

Jwgranville: /* Developer Links */

Welcome to the EDURange Wiki. This is less of a formal documentation as it is a living document.

I think that if it's a choice between losing track of people's contributions and having a messy wiki, I'd much prefer a messy wiki. It's my hope that we can gather all of our notes, thoughts, and loosely related ephemera here, rather than having it scattered across correspondence and various sharing platforms.

We don't have many conventions yet. Please follow the Golden Rule and treat others as you would be treated. Put your name on your changes. Consider posting to the discussion tab or appending to a page rather than overwriting it. Try not to overwrite the personal work of others.

If it's installable/runnable/code of any sort, put it on GitHub as well - preferably under the edurange organization so that our future contributors will have seamless access to it too.

Thanks for your time.

~Joe G

== The EDURange Project ==
[[:Category:Project History and Roadmaps|Project History and Roadmaps]]

== Developer Links ==
!!! [[New Version Planning]] !!!

[[Style Guidelines and Developer Tools]]

[[Reference Materials]]

[[:Category:Demonstrations|Demonstrations]]

[[Design Stories (OLD)]]

[[Interface Design]]

[[Scenario Creation Guide]]

[[Terraform Design]]

[[Hosting Requirements]]

[[Domain Modeling]]

We're still figuring out Media Wiki, so I kept the following...

== Orphaned Default Media Wiki Content ==
<strong>Welcome to the EDURange Wiki</strong>

Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.

== Getting started with Media Wiki ==
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

New Version Planning

2026-01-24T00:54:52Z

Jwgranville:

New Version Planning

2026-01-24T00:48:55Z

Jwgranville:

New Version Planning

2026-01-23T21:30:06Z

Jwgranville:

* POST handler/API reachability
* Chat capability
* Containers
* NSJail, chroot?
* How to model shared resources and contention?
* Staged/prerequisite content in guide/scenario
* How to refer to observation/logging instruments

=== Functional requirements: ===

* 20-300 students simultaneously? Semi-simultaneously? ~150 concurrently
* Telemetry layer for instrument/orchestration help

=== Ubiquitous language: ===

* Scenario
* Learning objectives
** e.g.
*** "Students will be able to use ls to list the contents of a directory"
*** "Student can log in to the exercise via SSH"
** Milestone
* Questions (are exercises distinct?)
* Guide
** Guide section
* Student
* Instructor
* Hint
* Intervention
* Prediction
* Learning environment
* Observability/instrumentation? (Name?)

=== User stores: ===

New Version Planning

2026-01-23T21:18:26Z

Jwgranville:

* POST handler/API reachability
* Chat capability
* Containers
* NSJail, chroot?
* How to model shared resources and contention?
* Staged/prerequisite content in guide/scenario
* How to refer to observation/logging instruments

=== Functional requirements: ===

* 20-300 students simultaneously? Semi-simultaneously? ~150 concurrently
* Telemetry layer for instrument/orchestration help

=== Ubiquitous language: ===

* Scenario
* Learning objectives
** "Students will be able to use ls to list the contents of a directory"
** "Student can log in to the exercise via SSH"
** Milestone
* Questions (are exercises distinct?)
* Guide
** Guide section
* Student
* Instructor
* Hint
* Intervention
* Prediction
* Learning environment
* Observability/instrumentation? (Name?)

=== User stores: ===

New Version Planning

2026-01-23T21:16:48Z

Jwgranville: /* Ubiquitous language: */

* POST handler/API reachability
* Chat capability
* Containers
* NSJail, chroot?
* How to model shared resources and contention?
* Staged/prerequisite content in guide/scenario
* How to refer to observation/logging instruments

=== Functional requirements: ===

* 20-300 students simultaneously? Semi-simultaneously? ~150 concurrently

=== Ubiquitous language: ===

* Scenario
* Learning objectives
** "Students will be able to use ls to list the contents of a directory"
** "Student can log in to the exercise via SSH"
** Milestone
* Questions (are exercises distinct?)
* Guide
** Guide section
* Student
* Instructor
* Hint
* Intervention
* Prediction
* Learning environment
* Observability/instrumentation? (Name?)

=== User stores: ===

New Version Planning

2026-01-23T21:13:42Z

Jwgranville:

* POST handler/API reachability
* Chat capability
* Containers
* NSJail, chroot?
* How to model shared resources and contention?
* Staged/prerequisite content in guide/scenario

=== Functional requirements: ===

* 20-300 students simultaneously? Semi-simultaneously? ~150 concurrently

=== Ubiquitous language: ===

* Scenario
* Learning objectives
** "Students will be able to use ls to list the contents of a directory"
** "Student can log in to the exercise via SSH"
** Milestone
* Questions (are exercises distinct?)
* Guide
** Guide section
* Student
* Instructor
* Hint
* Intervention
* Prediction
* Learning environment

=== User stores: ===

New Version Planning

2026-01-23T21:09:47Z

Jwgranville: Add learning objective examples

* POST handler/API reachability
* Chat capability
* Containers
* NSJail, chroot?
* How to model shared resources and contention?

=== Functional requirements: ===

* 20-300 students simultaneously? Semi-simultaneously? ~150 concurrently

=== Ubiquitous language: ===

* Scenario
* Learning objectives
** "Students will be able to use ls to list the contents of a directory"
** "Student can log in to the exercise via SSH"
** Milestone
* Questions (are exercises distinct?)
* Guide
** Guide section
* Student
* Instructor
* Hint
* Intervention
* Prediction
* Learning environment

=== User stores: ===

New Version Planning

2026-01-23T20:59:49Z

Jwgranville: Starting page

* POST handler/API reachability
* Chat capability
* Containers
* NSJail, chroot?
* How to model shared resources and contention?

=== Functional requirements: ===

* 20-300 students simultaneously? Semi-simultaneously? ~150 concurrently

=== Ubiquitous language: ===

* Scenario
* Learning objectives
** Milestone
* Questions (are exercises distinct?)
* Guide
** Guide section
* Student
* Instructor
* Hint
* Intervention
* Prediction
* Learning environment

=== User stores: ===

TTY Logging with BPF

2025-08-20T02:23:53Z

Jwgranville:

[[Category:Demonstrations]]
See https://github.com/edurange/demo-bpf-tty-logger.

Demonstrates how to capture TTY activity using BPF kernel probes.

== Instructions ==
To run it one needs to have superuser privileges (for kernel access). The probes intercept all TTY activity on the host system - both inside and outside of containers. If the script is printing to a TTY device the prints themselves will also be observed, creating a feedback loop that will quickly consume the kernel buffers. As such the output should be redirected to a file. I recommend redirecting both STDOUT and STDERR as follows:
sudo python3 [https://github.com/edurange/demo-bpf-tty-logger/blob/main/parrotty.py parrotty.py] &> log

== Explanation ==
[https://github.com/edurange/demo-bpf-tty-logger/blob/main/parrotty.py parrotty.py] is compact but there's a lot going on. Unlike [https://ttylog.sourceforge.net ttylog] and [https://github.com/edurange/edurange3/blob/main/scenarios/global_scripts/analyze.py analyze.py], which it would replace, [https://github.com/edurange/demo-bpf-tty-logger/blob/main/parrotty.py parrotty.py] does not rely on changing or proxying the TTY device itself. Rather, it utilizes [[wikipedia:Berkeley_Packet_Filter|Berkeley Packet Filters]], a kernel-level interface for hooking code into system calls; see also https://www.kernel.org/doc/html/latest/bpf/index.html for a specific implementation of the BPF interface. Instead of intercepting at the point of the TTY connection, we tamper with and tap the kernel calls that provide TTY services system-wide.

=== Berkeley Packet Filter ===
BPF links compiled object code into the kernel. Newer extensions to BPF support using pre-compiled code payloads, but typically the code is loaded at runtime from C, with a tool such as [https://root.cern/cling/ cling]. It looks odd by Python standards, but the common practice is to embed a one-file C program as a string in the Python file, then send it to be compiled and linked in through the BPF API.

The main area of interest are the functions injected into the kernel, called probes - kprobe__tty_write() and kprobe__n_tty_receive_buf_common(). The prefix "kprobe__" tells BPF to use these functions as probes automatically (but it's possible to use arbitrary functions, with an additional call to identify them.)

tty_write() and tty_receive_buf_common() are used to copy data in and out of kernel memory, as user-land processes talk to the physical device drivers represented in software by the TTY resource. In its basic usage, BPF calls the probe with the same parameters that the system call received. We use this to read the data buffers as TTY devices transmit and receive.

To safely permit alterations to the kernel, BPF enforces safety checks above and beyond normal C language requirements. As such, the kernel probe code may appear pedantic in the amount of guards used. These are necessary for approval by the BPF checker.

=== Timing ===
BPF lacks a wall clock time source. In other words, all of the time values available in the kernel under BPF are based on the system's uptime clock, not a time source synced to time of day. The uptime clocks have some unusual behavior compared to typical clocks. When the host system is halted or put to sleep, the clocks stop. From the perspective of software running on the host system, the system clocks move forward at a smooth rate, but the wall clock time jumps forward unpredictably whenever the system wakes from sleep.

To account for this, first the raw time values must be captured as close to the actual TTY event as possible - preferably, as the first instruction in the probe. We note the system time as part of the record of the TTY event, which is then exfiltrated from the kernel using a shared memory buffer provided by BPF.

In user space a handler function in the outer Python script reads events from the BPF buffer. There we have full access to wall clock time. Measuring the difference between system uptime and wall clock time is as simple as capturing both values, but it may occasionally jump as a result of changes to the offset value used to calibrate it - such as when the system receives a time update via network time protocol, which can occur quite frequently on modern operating systems.

To watch for drift in the clock offset, we take the difference between the current system-wide wall clock time and the time extrapolated by adding our offset estimate to the most recent timestamp. If the drift between the two time sources exceeds some small threshhold, we calculate a new offset value. We also recalibrate the offset value on a regular interval, even if it doesn't exceed the drift limit. In our implementation we chose a drift threshold of one thousandth of a second, and a refresh timeout of one minute.

The timing values are captured in a closure to avoid reliance on mutable global variables. calibratetimefactory() encloses the timing values with the method that updates them. API consumers need only call the resulting calibratetime() function to receive updated timing information, while being discouraged from tampering with the internal representation and underlying algorithm.

=== Event Attributes ===
As mentioned, because this code runs in the kernel whenever the relevant system calls are invoked, it sees all TTY activity - from all processes and all users. Unlike ttylog, we are not attached to one particular TTY device. To distinguish between calls made by different services on behalf of different endpoints, we must record additional data about each system call event.

In the order that they appear in the code, not necessarily by relevance:

- `rawtime`: The raw value of the system uptime clock when the event was captured. Represented as nanoseconds of CPU runtime since boot up. A "monotonic clock" in hardware design terminology.

- `cgid`: The "**C**ontrol **G**roup **ID**" (sometimes shortened "Cgroup") is a Linux mechanism for grouping processes and other resources heirarchically. It can be used in some circumstances to identify processes as belonging to containers. Cgroups are a Linux kernel feature that do not have a direct analog on other POSIX systems, but so is BPF, so while I'd like to stick to POSIX compatibility where possible that's just not relevant in this context.

- `inode`: The "**i**ndex **node**" refers to the file-like object associated with the TTY device or psuedoterminal that is transmitting/receiving. This is a primary source of identifying information for our purposes, but there are some circumstances where it isn't available, and there are also cases where inode values will differ but we want to associate the data together anyways, such as when we see the same student log in on more than one terminal.

- `pidtgid`: This encodes two values which come from BPF packed into a single variable - PID, the "**p**rocess **ID**" of the main thread, and TGID, the "**t**hread **g**roup **ID**", which may contain a different ID for the current thread if the process has more than just a main thread.

- `nsid`: This contains the "**n**ame**s**pace **ID**" of the calling process, which can help to identify containerized processes in some circumstances where CGID and PID/TGID leave ambiguity.

- `comm`: This is the "**comm**and name", a fixed-length 15-character identifier of the calling process. It is often not unique, and sometimes truncated and/or mangled, but may provide additional context in some situations and enhances the human readability of events.

- `buf`: This is the "**buf**fer". This is the C byte array that the kernel received from the caller, representing the data being communicated. It may be as long as a kernel page, which is 4kB on contemporary systems, and may or may not be null-terminated. The buffer contains raw bytes that have not been interpreted according to any text encoding, and in some cases the buffer will not be decodable by itself - multi-byte characters (like from Unicode) are not guaranteed to be complete and may be split between two buffer flushes. What this means is that text needs to be assembled and decoded at a higher level than we are working at while just capturing the data.

- `len`: The number of bytes in the buffer. Not the same as the characters represented in the buffer. Definitely not the same as the number of characters that will show up on the terminal.

- `event`: This indicates the directionality of the event, from the perspective of the host system. INPUT events indicate data received from the student's terminal or client process. OUTPUT events indicate data being transmitted to the student or client.

In the Python output, there are some derived values which are not recorded in the BPF probes, but calculated in the outer Python handler:

- `pid` is derived from the upper 4 bytes of the combined `pidtgid` value, by shifting out the lower bytes.

- `tgid` is derived by masking off the lower 4 bytes of the combined `pidtgid` value.

- `time` is derived by adding the aforementioned clock offset calculation to the `rawtime` value.

== Example Output ==
When <code>echo Hello World!\n</code> was written to TTY, the following activity was captured:
<INPUT pid=2579 tid=2579 time=1751051966371111181 rawtime=203335230775 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'e'
<OUTPUT pid=67 tid=67 time=1751051966372044241 rawtime=203336163835 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'e'
<INPUT pid=2580 tid=2580 time=1751051966372190646 rawtime=203336310240 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'e'
<OUTPUT pid=67 tid=67 time=1751051966372639326 rawtime=203336759469 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'e'
<INPUT pid=2579 tid=2579 time=1751051968089522310 rawtime=205053641539 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'c'
<OUTPUT pid=67 tid=67 time=1751051968089690488 rawtime=205053809717 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'c'
<INPUT pid=2580 tid=2580 time=1751051968089802828 rawtime=205053922397 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'c'
<OUTPUT pid=67 tid=67 time=1751051968089833388 rawtime=205053952388 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'c'
<INPUT pid=2579 tid=2579 time=1751051968250835993 rawtime=205214954887 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'h'
<OUTPUT pid=67 tid=67 time=1751051968250966010 rawtime=205215084904 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'h'
<INPUT pid=2580 tid=2580 time=1751051968251302359 rawtime=205215421253 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'h'
<OUTPUT pid=67 tid=67 time=1751051968251330720 rawtime=205215449614 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'h'
<INPUT pid=2579 tid=2579 time=1751051969762481565 rawtime=206726601086 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051969762631118 rawtime=206726750639 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2580 tid=2580 time=1751051969762777304 rawtime=206726896825 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051969762801534 rawtime=206726921161 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2579 tid=2579 time=1751051970952290018 rawtime=207916408780 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b' '
<OUTPUT pid=67 tid=67 time=1751051970952415054 rawtime=207916533816 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b' '
<INPUT pid=2580 tid=2580 time=1751051970952582323 rawtime=207916701085 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b' '
<OUTPUT pid=67 tid=67 time=1751051970952645255 rawtime=207916764825 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b' '
<INPUT pid=2579 tid=2579 time=1751051971611934058 rawtime=208576052862 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'H'
<OUTPUT pid=67 tid=67 time=1751051971612097568 rawtime=208576216372 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'H'
<INPUT pid=2580 tid=2580 time=1751051971612342263 rawtime=208576461926 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'H'
<OUTPUT pid=67 tid=67 time=1751051971612367333 rawtime=208576487354 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'H'
<INPUT pid=2579 tid=2579 time=1751051971808898991 rawtime=208773018069 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'e'
<OUTPUT pid=67 tid=67 time=1751051971809014928 rawtime=208773134006 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'e'
<INPUT pid=2580 tid=2580 time=1751051971809320248 rawtime=208773439326 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'e'
<OUTPUT pid=67 tid=67 time=1751051971809351426 rawtime=208773471241 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'e'
<INPUT pid=2579 tid=2579 time=1751051971964705058 rawtime=208928823985 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051971964878073 rawtime=208928997000 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2580 tid=2580 time=1751051971965206444 rawtime=208929325371 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051971965235901 rawtime=208929355554 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2579 tid=2579 time=1751051972143167788 rawtime=209107286648 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051972143292895 rawtime=209107411755 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2580 tid=2580 time=1751051972143459449 rawtime=209107578309 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051972143483528 rawtime=209107602911 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2579 tid=2579 time=1751051972318556514 rawtime=209282675286 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051972318681585 rawtime=209282800357 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2580 tid=2580 time=1751051972318875590 rawtime=209282995496 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051972318899197 rawtime=209283018165 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2579 tid=2579 time=1751051972587453662 rawtime=209551572401 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b','
<OUTPUT pid=67 tid=67 time=1751051972587621515 rawtime=209551740254 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b','
<INPUT pid=2580 tid=2580 time=1751051972587734382 rawtime=209551853121 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b','
<OUTPUT pid=67 tid=67 time=1751051972587758332 rawtime=209551878383 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b','
<INPUT pid=2579 tid=2579 time=1751051972700061714 rawtime=209664180622 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b' '
<OUTPUT pid=67 tid=67 time=1751051972700188164 rawtime=209664307072 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b' '
<INPUT pid=2580 tid=2580 time=1751051972700536831 rawtime=209664655739 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b' '
<OUTPUT pid=67 tid=67 time=1751051972700565465 rawtime=209664684373 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b' '
<INPUT pid=2579 tid=2579 time=1751051972892415567 rawtime=209856535138 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'W'
<OUTPUT pid=67 tid=67 time=1751051972892541864 rawtime=209856661435 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'W'
<INPUT pid=2580 tid=2580 time=1751051972892748515 rawtime=209856868086 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'W'
<OUTPUT pid=67 tid=67 time=1751051972892776412 rawtime=209856895983 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'W'
<INPUT pid=2579 tid=2579 time=1751051973053552503 rawtime=210017672160 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051973053768028 rawtime=210017887685 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2580 tid=2580 time=1751051973053883021 rawtime=210018002678 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051973053908007 rawtime=210018027638 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2579 tid=2579 time=1751051973140155837 rawtime=210104274616 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'r'
<OUTPUT pid=67 tid=67 time=1751051973140277309 rawtime=210104396088 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'r'
<INPUT pid=2580 tid=2580 time=1751051973140428835 rawtime=210104547614 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'r'
<OUTPUT pid=67 tid=67 time=1751051973140452038 rawtime=210104571622 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'r'
<INPUT pid=2579 tid=2579 time=1751051973250867779 rawtime=210214986547 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051973250993810 rawtime=210215112578 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2580 tid=2580 time=1751051973251331050 rawtime=210215449818 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051973251361348 rawtime=210215480116 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2579 tid=2579 time=1751051973335770189 rawtime=210299889755 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'd'
<OUTPUT pid=67 tid=67 time=1751051973335937186 rawtime=210300056752 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'd'
<INPUT pid=2580 tid=2580 time=1751051973336218966 rawtime=210300338532 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'd'
<OUTPUT pid=67 tid=67 time=1751051973336246835 rawtime=210300366528 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'd'
<INPUT pid=2579 tid=2579 time=1751051973665644437 rawtime=210629763107 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'!'
<OUTPUT pid=67 tid=67 time=1751051973665786687 rawtime=210629905357 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'!'
<INPUT pid=2580 tid=2580 time=1751051973666070698 rawtime=210630189368 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'!'
<OUTPUT pid=67 tid=67 time=1751051973666097902 rawtime=210630217539 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'!'
<INPUT pid=2579 tid=2579 time=1751051974226180674 rawtime=211190299600 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'\r'
<OUTPUT pid=67 tid=67 time=1751051974226348069 rawtime=211190466995 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'\r'
<INPUT pid=2580 tid=2580 time=1751051974226417647 rawtime=211190536573 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'\n'
<OUTPUT pid=67 tid=67 time=1751051974226440318 rawtime=211190559951 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=2>
b'\r\n'
<INPUT pid=2580 tid=2580 time=1751051974226501433 rawtime=211190620594 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=9>
b'\x1b[?2004l\r'
<OUTPUT pid=67 tid=67 time=1751051974226556167 rawtime=211190675351 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=9>
b'\x1b[?2004l\r'
<INPUT pid=2580 tid=2580 time=1751051974227307873 rawtime=211191426669 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=14>
b'Hello, World!\n'
<INPUT pid=2580 tid=2580 time=1751051974227857480 rawtime=211191976447 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=8>
b'\x1b[?2004h'
<INPUT pid=2580 tid=2580 time=1751051974227952968 rawtime=211192071701 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=52>
b'\x1b]0;joe@bpf: ~\x07\x1b[01;32mjoe@bpf\x1b[00m:\x1b[01;34m~\x1b[00m$ '
<OUTPUT pid=67 tid=67 time=1751051974227997645 rawtime=211192116397 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=75>
b'Hello, World!\r\n\x1b[?2004h\x1b]0;joe@bpf: ~\x07\x1b[01;32mjoe@bpf\x1b[00m:\x1b[01;34m~\x1b[00m$ '

TTY Logging with BPF

2025-08-19T20:06:03Z

Jwgranville: Added some additional details that didn't make it in before pages were frozen to deal with bots

Category:Project History and Roadmaps

2025-07-11T23:26:33Z

Jwgranville: /* Instructions */

This is a page to collect our history, accomplishments, needs, goals and wishlist items.

The idea is to document all of the high-level material we've produced, such as publications, major code releases and trial results. This collection can then be used as a timeline of our work and trajectory.

As this content is developed we may want to adopt standards for how things are organized - particularly to distinguish between proposed goals, agreed-upon plans and retired items that are reference only.

When making pages for a code release or academic paper it would be great to include working permalinks to the resource in question, especially full text for literature. A brief statement including additional details would also be helpful - such as who contributed to it and when, and a description of the state of the project at the time.

Perhaps we could also include short biographical pages for contributors that care to share their information, but I'll wait to see what the group thinks of that before jumping in myself. ~Joe G

== Project Timeline ==
This list may not stay accurate as it grows. Verify any inferences with human sources.

* [[The Conception of EDURange]] [2011]: Conceptually, EDURange started around 2011 when Jens, Michael Locasto, and Richard started talking about creating exercises for cybersecurity courses. The idea was generated at a dinner with Michael, Sergey Bratus, Brian Fite, and Richard. Brian was packet master for a competition called PacketWars, and he was looking for a way to be a player and not the one running the competition. ... - Richard
== Instructions ==
Do not write individual items here; this page is just for indexing and coordinating the entries under this category.

* First create a page with a title appropriate for your item. There's no hard convention yet, but strive for readability/searchability.
* In the source of that page, add the following on the first line: <code><nowiki>[[Category:Project History and Roadmap]]</nowiki></code>
* Your page will be automatically indexed into this category. You can also add an entry in the timeline below.

=== Page contents ===
Please include context for your items, as future contributors may use these accounts for research. Readers should not need to rely on edit history to determine the date and author. At a minimum, the page should include:

* Your identity as the writer.
* The date of the original post.
* The timespan, if the post refers to something that has already happened or has a concrete goal date.

=== Timeline entries ===
Please try to keep timeline entries to a brief paragraph. Include the name of the page, the time in question, and your name as author.

Do not add future items to this main timeline. Future goals that don't come to pass may need to be edited after the fact to avoid confusing readers - let's put such content in a dedicated place where it doesn't clutter up more reliable information.

Category:Project History and Roadmaps

2025-07-11T23:25:02Z

Jwgranville:

This is a page to collect our history, accomplishments, needs, goals and wishlist items.

The idea is to document all of the high-level material we've produced, such as publications, major code releases and trial results. This collection can then be used as a timeline of our work and trajectory.

As this content is developed we may want to adopt standards for how things are organized - particularly to distinguish between proposed goals, agreed-upon plans and retired items that are reference only.

When making pages for a code release or academic paper it would be great to include working permalinks to the resource in question, especially full text for literature. A brief statement including additional details would also be helpful - such as who contributed to it and when, and a description of the state of the project at the time.

Perhaps we could also include short biographical pages for contributors that care to share their information, but I'll wait to see what the group thinks of that before jumping in myself. ~Joe G

== Project Timeline ==
This list may not stay accurate as it grows. Verify any inferences with human sources.

* [[The Conception of EDURange]] [2011]: Conceptually, EDURange started around 2011 when Jens, Michael Locasto, and Richard started talking about creating exercises for cybersecurity courses. The idea was generated at a dinner with Michael, Sergey Bratus, Brian Fite, and Richard. Brian was packet master for a competition called PacketWars, and he was looking for a way to be a player and not the one running the competition. ... - Richard
== Instructions ==
Do not write individual items here; this page is just for indexing and coordinating the entries under this category.

* First create a page with a title appropriate for your item. There's no hard convention yet, but strive for readability/searchability.
* In the source of that page, add the following on the first line: <code><nowiki>[[Category:Project History and Roadmap]]</nowiki></code>
* Your page will be automatically indexed into the category. You can also add an entry in the timeline below.

=== Page contents ===
Please include context for your items, as future contributors may use these accounts for research. Readers should not need to rely on edit history to determine the date and author. At a minimum, the page should include:

* Your identity as the writer.
* The date of the original post.
* The timespan, if the post refers to something that has already happened or has a concrete goal date.

=== Timeline entries ===
Please try to keep timeline entries to a brief paragraph. Include the name of the page, the time in question, and your name as author.

Do not add future items to this main timeline. Future goals that don't come to pass may need to be edited after the fact to avoid confusing readers - let's put such content in a dedicated place where it doesn't clutter up more reliable information.

TTY Logging with BPF

2025-06-30T20:22:34Z

Jwgranville:

[[Category:Demonstrations]]
See https://github.com/edurange/demo-bpf-tty-logger.

Demonstrates how to capture TTY activity using BPF kernel probes.

== Instructions ==
To run it one needs to have superuser privileges (for kernel access). The probes intercept all TTY activity on the host system - both inside and outside of containers. If the script is printing to a TTY device the prints themselves will also be observed, creating a feedback loop that will quickly consume the kernel buffers. As such the output should be redirected to a file. I recommend redirecting both STDOUT and STDERR as follows:
sudo python3 [https://github.com/edurange/demo-bpf-tty-logger/blob/main/parrotty.py parrotty.py] &> log

== Explanation ==
[https://github.com/edurange/demo-bpf-tty-logger/blob/main/parrotty.py parrotty.py] is compact but there's a lot going on. Unlike [https://ttylog.sourceforge.net ttylog] and [https://github.com/edurange/edurange3/blob/main/scenarios/global_scripts/analyze.py analyze.py], which it would replace, [https://github.com/edurange/demo-bpf-tty-logger/blob/main/parrotty.py parrotty.py] does not rely on changing or proxying the TTY device itself. Rather, it utilizes [[wikipedia:Berkeley_Packet_Filter|Berkeley Packet Filters]], a kernel-level interface for hooking code into system calls; see also https://www.kernel.org/doc/html/latest/bpf/index.html for a specific implementation of the BPF interface. Instead of intercepting at the point of the TTY connection, we tamper with and tap the kernel calls that provide TTY services system-wide.

=== Berkeley Packet Filter ===
BPF links compiled object code into the kernel. Newer extensions to BPF support using pre-compiled code payloads, but typically the code is loaded at runtime from C, with a tool such as [https://root.cern/cling/ cling]. It looks odd by Python standards, but the common practice is to embed a one-file C program as a string in the Python file, then send it to be compiled and linked in through the BPF API.

The main area of interest are the functions injected into the kernel, called probes - kprobe__tty_write() and kprobe__n_tty_receive_buf_common(). The prefix "kprobe__" tells BPF to use these functions as probes automatically (but it's possible to use arbitrary functions, with an additional call to identify them.)

tty_write() and tty_receive_buf_common() are used to copy data in and out of kernel memory, as user-land processes talk to the physical device drivers represented in software by the TTY resource. In its basic usage, BPF calls the probe with the same parameters that the system call received. We use this to read the data buffers as TTY devices transmit and receive.

To safely permit alterations to the kernel, BPF enforces safety checks above and beyond normal C language requirements. As such, the kernel probe code may appear pedantic in the amount of guards used. These are necessary for approval by the BPF checker.

=== Timing ===
BPF lacks a wall clock time source. In other words, all of the time values available in the kernel under BPF are based on the system's uptime clock, not a time source synced to time of day. The uptime clocks have some unusual behavior compared to typical clocks. When the host system is halted or put to sleep, the clocks stop. From the perspective of software running on the host system, the system clocks move forward at a smooth rate, but the wall clock time jumps forward unpredictably whenever the system wakes from sleep.

To account for this, first the raw time values must be captured as close to the actual TTY event as possible - preferably, as the first instruction in the probe. We note the system time as part of the record of the TTY event, which is then exfiltrated from the kernel using a shared memory buffer provided by BPF.

In Python, a handler function reads events out of the buffer. In user space we have full access to wall clock time. Measuring the difference between system uptime and wall clock time is simple, but it may jump as a result of changes to the offset value used to calibrate it - such as when the system receives a time update via NTP

== Example Output ==
When <code>echo Hello World!\n</code> was written to TTY, the following activity was captured:
<INPUT pid=2579 tid=2579 time=1751051966371111181 rawtime=203335230775 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'e'
<OUTPUT pid=67 tid=67 time=1751051966372044241 rawtime=203336163835 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'e'
<INPUT pid=2580 tid=2580 time=1751051966372190646 rawtime=203336310240 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'e'
<OUTPUT pid=67 tid=67 time=1751051966372639326 rawtime=203336759469 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'e'
<INPUT pid=2579 tid=2579 time=1751051968089522310 rawtime=205053641539 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'c'
<OUTPUT pid=67 tid=67 time=1751051968089690488 rawtime=205053809717 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'c'
<INPUT pid=2580 tid=2580 time=1751051968089802828 rawtime=205053922397 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'c'
<OUTPUT pid=67 tid=67 time=1751051968089833388 rawtime=205053952388 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'c'
<INPUT pid=2579 tid=2579 time=1751051968250835993 rawtime=205214954887 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'h'
<OUTPUT pid=67 tid=67 time=1751051968250966010 rawtime=205215084904 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'h'
<INPUT pid=2580 tid=2580 time=1751051968251302359 rawtime=205215421253 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'h'
<OUTPUT pid=67 tid=67 time=1751051968251330720 rawtime=205215449614 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'h'
<INPUT pid=2579 tid=2579 time=1751051969762481565 rawtime=206726601086 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051969762631118 rawtime=206726750639 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2580 tid=2580 time=1751051969762777304 rawtime=206726896825 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051969762801534 rawtime=206726921161 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2579 tid=2579 time=1751051970952290018 rawtime=207916408780 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b' '
<OUTPUT pid=67 tid=67 time=1751051970952415054 rawtime=207916533816 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b' '
<INPUT pid=2580 tid=2580 time=1751051970952582323 rawtime=207916701085 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b' '
<OUTPUT pid=67 tid=67 time=1751051970952645255 rawtime=207916764825 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b' '
<INPUT pid=2579 tid=2579 time=1751051971611934058 rawtime=208576052862 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'H'
<OUTPUT pid=67 tid=67 time=1751051971612097568 rawtime=208576216372 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'H'
<INPUT pid=2580 tid=2580 time=1751051971612342263 rawtime=208576461926 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'H'
<OUTPUT pid=67 tid=67 time=1751051971612367333 rawtime=208576487354 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'H'
<INPUT pid=2579 tid=2579 time=1751051971808898991 rawtime=208773018069 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'e'
<OUTPUT pid=67 tid=67 time=1751051971809014928 rawtime=208773134006 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'e'
<INPUT pid=2580 tid=2580 time=1751051971809320248 rawtime=208773439326 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'e'
<OUTPUT pid=67 tid=67 time=1751051971809351426 rawtime=208773471241 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'e'
<INPUT pid=2579 tid=2579 time=1751051971964705058 rawtime=208928823985 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051971964878073 rawtime=208928997000 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2580 tid=2580 time=1751051971965206444 rawtime=208929325371 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051971965235901 rawtime=208929355554 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2579 tid=2579 time=1751051972143167788 rawtime=209107286648 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051972143292895 rawtime=209107411755 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2580 tid=2580 time=1751051972143459449 rawtime=209107578309 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051972143483528 rawtime=209107602911 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2579 tid=2579 time=1751051972318556514 rawtime=209282675286 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051972318681585 rawtime=209282800357 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2580 tid=2580 time=1751051972318875590 rawtime=209282995496 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051972318899197 rawtime=209283018165 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2579 tid=2579 time=1751051972587453662 rawtime=209551572401 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b','
<OUTPUT pid=67 tid=67 time=1751051972587621515 rawtime=209551740254 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b','
<INPUT pid=2580 tid=2580 time=1751051972587734382 rawtime=209551853121 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b','
<OUTPUT pid=67 tid=67 time=1751051972587758332 rawtime=209551878383 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b','
<INPUT pid=2579 tid=2579 time=1751051972700061714 rawtime=209664180622 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b' '
<OUTPUT pid=67 tid=67 time=1751051972700188164 rawtime=209664307072 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b' '
<INPUT pid=2580 tid=2580 time=1751051972700536831 rawtime=209664655739 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b' '
<OUTPUT pid=67 tid=67 time=1751051972700565465 rawtime=209664684373 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b' '
<INPUT pid=2579 tid=2579 time=1751051972892415567 rawtime=209856535138 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'W'
<OUTPUT pid=67 tid=67 time=1751051972892541864 rawtime=209856661435 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'W'
<INPUT pid=2580 tid=2580 time=1751051972892748515 rawtime=209856868086 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'W'
<OUTPUT pid=67 tid=67 time=1751051972892776412 rawtime=209856895983 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'W'
<INPUT pid=2579 tid=2579 time=1751051973053552503 rawtime=210017672160 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051973053768028 rawtime=210017887685 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2580 tid=2580 time=1751051973053883021 rawtime=210018002678 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051973053908007 rawtime=210018027638 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2579 tid=2579 time=1751051973140155837 rawtime=210104274616 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'r'
<OUTPUT pid=67 tid=67 time=1751051973140277309 rawtime=210104396088 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'r'
<INPUT pid=2580 tid=2580 time=1751051973140428835 rawtime=210104547614 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'r'
<OUTPUT pid=67 tid=67 time=1751051973140452038 rawtime=210104571622 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'r'
<INPUT pid=2579 tid=2579 time=1751051973250867779 rawtime=210214986547 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051973250993810 rawtime=210215112578 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2580 tid=2580 time=1751051973251331050 rawtime=210215449818 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051973251361348 rawtime=210215480116 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2579 tid=2579 time=1751051973335770189 rawtime=210299889755 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'd'
<OUTPUT pid=67 tid=67 time=1751051973335937186 rawtime=210300056752 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'd'
<INPUT pid=2580 tid=2580 time=1751051973336218966 rawtime=210300338532 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'd'
<OUTPUT pid=67 tid=67 time=1751051973336246835 rawtime=210300366528 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'd'
<INPUT pid=2579 tid=2579 time=1751051973665644437 rawtime=210629763107 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'!'
<OUTPUT pid=67 tid=67 time=1751051973665786687 rawtime=210629905357 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'!'
<INPUT pid=2580 tid=2580 time=1751051973666070698 rawtime=210630189368 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'!'
<OUTPUT pid=67 tid=67 time=1751051973666097902 rawtime=210630217539 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'!'
<INPUT pid=2579 tid=2579 time=1751051974226180674 rawtime=211190299600 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'\r'
<OUTPUT pid=67 tid=67 time=1751051974226348069 rawtime=211190466995 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'\r'
<INPUT pid=2580 tid=2580 time=1751051974226417647 rawtime=211190536573 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'\n'
<OUTPUT pid=67 tid=67 time=1751051974226440318 rawtime=211190559951 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=2>
b'\r\n'
<INPUT pid=2580 tid=2580 time=1751051974226501433 rawtime=211190620594 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=9>
b'\x1b[?2004l\r'
<OUTPUT pid=67 tid=67 time=1751051974226556167 rawtime=211190675351 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=9>
b'\x1b[?2004l\r'
<INPUT pid=2580 tid=2580 time=1751051974227307873 rawtime=211191426669 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=14>
b'Hello, World!\n'
<INPUT pid=2580 tid=2580 time=1751051974227857480 rawtime=211191976447 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=8>
b'\x1b[?2004h'
<INPUT pid=2580 tid=2580 time=1751051974227952968 rawtime=211192071701 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=52>
b'\x1b]0;joe@bpf: ~\x07\x1b[01;32mjoe@bpf\x1b[00m:\x1b[01;34m~\x1b[00m$ '
<OUTPUT pid=67 tid=67 time=1751051974227997645 rawtime=211192116397 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=75>
b'Hello, World!\r\n\x1b[?2004h\x1b]0;joe@bpf: ~\x07\x1b[01;32mjoe@bpf\x1b[00m:\x1b[01;34m~\x1b[00m$ '
<INPUT pid=2579 tid=2579 time=1751051998831792273 rawtime=235795910526 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>

TTY Logging with BPF

2025-06-30T19:21:52Z

Jwgranville:

[[Category:Demonstrations]]
See https://github.com/edurange/demo-bpf-tty-logger.

Demonstrates how to capture TTY activity using BPF kernel probes.

== Instructions ==
To run it one needs to have superuser privileges (for kernel access). The probes intercept all TTY activity on the host system - both inside and outside of containers. If the script is printing to a TTY device the prints themselves will also be observed, creating a feedback loop that will quickly consume the kernel buffers. As such the output should be redirected to a file. I recommend redirecting both STDOUT and STDERR as follows:
sudo python3 [https://github.com/edurange/demo-bpf-tty-logger/blob/main/parrotty.py parrotty.py] &> log

== Explanation ==
[https://github.com/edurange/demo-bpf-tty-logger/blob/main/parrotty.py parrotty.py] is compact but there's a lot going on. Unlike [https://ttylog.sourceforge.net ttylog] and [https://github.com/edurange/edurange3/blob/main/scenarios/global_scripts/analyze.py analyze.py], which it would replace, [https://github.com/edurange/demo-bpf-tty-logger/blob/main/parrotty.py parrotty.py] does not rely on changing or proxying the TTY device itself. Rather, it utilizes [[wikipedia:Berkeley_Packet_Filter|Berkeley Packet Filters]], a kernel-level interface for hooking code into system calls; see also https://www.kernel.org/doc/html/latest/bpf/index.html for a specific implementation of the BPF interface. Instead of intercepting at the point of the TTY connection, we tamper with and tap the kernel calls that provide TTY services system-wide.

=== Berkeley Packet Filter ===
BPF links compiled object code into the kernel. Newer extensions to BPF support using pre-compiled code payloads, but typically the code is loaded at runtime from C, with a tool such as [https://root.cern/cling/ cling]. It looks odd by Python standards, but the common practice is to embed a one-file C program as a string in the Python file, then send it to be compiled and linked in through the BPF API.

The main area of interest are the functions injected into the kernel, called probes - kprobe__tty_write() and kprobe__n_tty_receive_buf_common(). The prefix "kprobe__" tells BPF to use these functions as probes automatically (but it's possible to use arbitrary functions, with an additional call to identify them.)

tty_write() and tty_receive_buf_common() are used to copy data in and out of kernel memory, as user-land processes talk to the physical device drivers represented in software by the TTY resource. In its basic usage, BPF calls the probe with the same parameters that the system call received. We use this to read the data buffers as TTY devices transmit and receive.

== Example Output ==
When <code>echo Hello World!\n</code> is written to TTY, the following activity is captured:
<INPUT pid=2579 tid=2579 time=1751051966371111181 rawtime=203335230775 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'e'
<OUTPUT pid=67 tid=67 time=1751051966372044241 rawtime=203336163835 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'e'
<INPUT pid=2580 tid=2580 time=1751051966372190646 rawtime=203336310240 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'e'
<OUTPUT pid=67 tid=67 time=1751051966372639326 rawtime=203336759469 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'e'
<INPUT pid=2579 tid=2579 time=1751051968089522310 rawtime=205053641539 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'c'
<OUTPUT pid=67 tid=67 time=1751051968089690488 rawtime=205053809717 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'c'
<INPUT pid=2580 tid=2580 time=1751051968089802828 rawtime=205053922397 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'c'
<OUTPUT pid=67 tid=67 time=1751051968089833388 rawtime=205053952388 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'c'
<INPUT pid=2579 tid=2579 time=1751051968250835993 rawtime=205214954887 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'h'
<OUTPUT pid=67 tid=67 time=1751051968250966010 rawtime=205215084904 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'h'
<INPUT pid=2580 tid=2580 time=1751051968251302359 rawtime=205215421253 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'h'
<OUTPUT pid=67 tid=67 time=1751051968251330720 rawtime=205215449614 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'h'
<INPUT pid=2579 tid=2579 time=1751051969762481565 rawtime=206726601086 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051969762631118 rawtime=206726750639 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2580 tid=2580 time=1751051969762777304 rawtime=206726896825 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051969762801534 rawtime=206726921161 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2579 tid=2579 time=1751051970952290018 rawtime=207916408780 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b' '
<OUTPUT pid=67 tid=67 time=1751051970952415054 rawtime=207916533816 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b' '
<INPUT pid=2580 tid=2580 time=1751051970952582323 rawtime=207916701085 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b' '
<OUTPUT pid=67 tid=67 time=1751051970952645255 rawtime=207916764825 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b' '
<INPUT pid=2579 tid=2579 time=1751051971611934058 rawtime=208576052862 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'H'
<OUTPUT pid=67 tid=67 time=1751051971612097568 rawtime=208576216372 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'H'
<INPUT pid=2580 tid=2580 time=1751051971612342263 rawtime=208576461926 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'H'
<OUTPUT pid=67 tid=67 time=1751051971612367333 rawtime=208576487354 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'H'
<INPUT pid=2579 tid=2579 time=1751051971808898991 rawtime=208773018069 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'e'
<OUTPUT pid=67 tid=67 time=1751051971809014928 rawtime=208773134006 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'e'
<INPUT pid=2580 tid=2580 time=1751051971809320248 rawtime=208773439326 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'e'
<OUTPUT pid=67 tid=67 time=1751051971809351426 rawtime=208773471241 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'e'
<INPUT pid=2579 tid=2579 time=1751051971964705058 rawtime=208928823985 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051971964878073 rawtime=208928997000 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2580 tid=2580 time=1751051971965206444 rawtime=208929325371 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051971965235901 rawtime=208929355554 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2579 tid=2579 time=1751051972143167788 rawtime=209107286648 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051972143292895 rawtime=209107411755 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2580 tid=2580 time=1751051972143459449 rawtime=209107578309 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051972143483528 rawtime=209107602911 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2579 tid=2579 time=1751051972318556514 rawtime=209282675286 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051972318681585 rawtime=209282800357 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2580 tid=2580 time=1751051972318875590 rawtime=209282995496 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051972318899197 rawtime=209283018165 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2579 tid=2579 time=1751051972587453662 rawtime=209551572401 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b','
<OUTPUT pid=67 tid=67 time=1751051972587621515 rawtime=209551740254 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b','
<INPUT pid=2580 tid=2580 time=1751051972587734382 rawtime=209551853121 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b','
<OUTPUT pid=67 tid=67 time=1751051972587758332 rawtime=209551878383 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b','
<INPUT pid=2579 tid=2579 time=1751051972700061714 rawtime=209664180622 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b' '
<OUTPUT pid=67 tid=67 time=1751051972700188164 rawtime=209664307072 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b' '
<INPUT pid=2580 tid=2580 time=1751051972700536831 rawtime=209664655739 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b' '
<OUTPUT pid=67 tid=67 time=1751051972700565465 rawtime=209664684373 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b' '
<INPUT pid=2579 tid=2579 time=1751051972892415567 rawtime=209856535138 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'W'
<OUTPUT pid=67 tid=67 time=1751051972892541864 rawtime=209856661435 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'W'
<INPUT pid=2580 tid=2580 time=1751051972892748515 rawtime=209856868086 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'W'
<OUTPUT pid=67 tid=67 time=1751051972892776412 rawtime=209856895983 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'W'
<INPUT pid=2579 tid=2579 time=1751051973053552503 rawtime=210017672160 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051973053768028 rawtime=210017887685 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2580 tid=2580 time=1751051973053883021 rawtime=210018002678 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'o'
<OUTPUT pid=67 tid=67 time=1751051973053908007 rawtime=210018027638 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'o'
<INPUT pid=2579 tid=2579 time=1751051973140155837 rawtime=210104274616 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'r'
<OUTPUT pid=67 tid=67 time=1751051973140277309 rawtime=210104396088 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'r'
<INPUT pid=2580 tid=2580 time=1751051973140428835 rawtime=210104547614 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'r'
<OUTPUT pid=67 tid=67 time=1751051973140452038 rawtime=210104571622 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'r'
<INPUT pid=2579 tid=2579 time=1751051973250867779 rawtime=210214986547 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051973250993810 rawtime=210215112578 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2580 tid=2580 time=1751051973251331050 rawtime=210215449818 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'l'
<OUTPUT pid=67 tid=67 time=1751051973251361348 rawtime=210215480116 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'l'
<INPUT pid=2579 tid=2579 time=1751051973335770189 rawtime=210299889755 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'd'
<OUTPUT pid=67 tid=67 time=1751051973335937186 rawtime=210300056752 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'd'
<INPUT pid=2580 tid=2580 time=1751051973336218966 rawtime=210300338532 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'd'
<OUTPUT pid=67 tid=67 time=1751051973336246835 rawtime=210300366528 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'd'
<INPUT pid=2579 tid=2579 time=1751051973665644437 rawtime=210629763107 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'!'
<OUTPUT pid=67 tid=67 time=1751051973665786687 rawtime=210629905357 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'!'
<INPUT pid=2580 tid=2580 time=1751051973666070698 rawtime=210630189368 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'!'
<OUTPUT pid=67 tid=67 time=1751051973666097902 rawtime=210630217539 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'!'
<INPUT pid=2579 tid=2579 time=1751051974226180674 rawtime=211190299600 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>
b'\r'
<OUTPUT pid=67 tid=67 time=1751051974226348069 rawtime=211190466995 cgid=1 inode=0 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=1>
b'\r'
<INPUT pid=2580 tid=2580 time=1751051974226417647 rawtime=211190536573 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=1>
b'\n'
<OUTPUT pid=67 tid=67 time=1751051974226440318 rawtime=211190559951 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=2>
b'\r\n'
<INPUT pid=2580 tid=2580 time=1751051974226501433 rawtime=211190620594 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=9>
b'\x1b[?2004l\r'
<OUTPUT pid=67 tid=67 time=1751051974226556167 rawtime=211190675351 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=9>
b'\x1b[?2004l\r'
<INPUT pid=2580 tid=2580 time=1751051974227307873 rawtime=211191426669 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=14>
b'Hello, World!\n'
<INPUT pid=2580 tid=2580 time=1751051974227857480 rawtime=211191976447 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=8>
b'\x1b[?2004h'
<INPUT pid=2580 tid=2580 time=1751051974227952968 rawtime=211192071701 cgid=7827 inode=3 pidtgid=11081015626260 nsid=12616466428 comm=b'bash' len=52>
b'\x1b]0;joe@bpf: ~\x07\x1b[01;32mjoe@bpf\x1b[00m:\x1b[01;34m~\x1b[00m$ '
<OUTPUT pid=67 tid=67 time=1751051974227997645 rawtime=211192116397 cgid=1 inode=7863412966886368629 pidtgid=287762808899 nsid=12616466428 comm=b'kworker/u10:5' len=75>
b'Hello, World!\r\n\x1b[?2004h\x1b]0;joe@bpf: ~\x07\x1b[01;32mjoe@bpf\x1b[00m:\x1b[01;34m~\x1b[00m$ '
<INPUT pid=2579 tid=2579 time=1751051998831792273 rawtime=235795910526 cgid=7827 inode=89 pidtgid=11076720658963 nsid=12616466428 comm=b'sshd' len=1>

Category:Project History and Roadmaps

2025-06-30T17:15:09Z

Jwgranville: /* Project Timeline */

This is a page to collect our history, accomplishments, needs, goals and wishlist items.

The idea is to document all of the high-level material we've produced, such as publications, major code releases and trial results. This collection can then be used as a timeline of our work and trajectory.

As this content is developed we may want to adopt standards for how things are organized - particularly to distinguish between proposed goals, agreed-upon plans and retired items that are reference only.

When making pages for a code release or academic paper it would be great to include working permalinks to the resource in question, especially full text for literature. A brief statement including additional details would also be helpful - such as who contributed to it and when, and a description of the state of the project at the time.

Perhaps we could also include short biographical pages for contributors that care to share their information, but I'll wait to see what the group thinks of that before jumping in myself. ~Joe G

== Instructions ==
Do not write individual items here; this page is just for indexing and coordinating the entries under this category.

* First create a page with a title appropriate for your item. There's no hard convention yet, but strive for readability/searchability.
* In the source of that page, add the following on the first line: <code><nowiki>[[Category:Project History and Roadmap]]</nowiki></code>
* Your page will be automatically indexed into the category. You can also add an entry in the timeline below.

=== Page contents ===
Please include context for your items, as future contributors may use these accounts for research. Readers should not need to rely on edit history to determine the date and author. At a minimum, the page should include:

* Your identity as the writer.
* The date of the original post.
* The timespan, if the post refers to something that has already happened or has a concrete goal date.

=== Timeline entries ===
Please try to keep timeline entries to a brief paragraph. Include the name of the page, the time in question, and your name as author.

Do not add future items to this main timeline. Future goals that don't come to pass may need to be edited after the fact to avoid confusing readers - let's put such content in a dedicated place where it doesn't clutter up more reliable information.

== Project Timeline ==
This list may not stay accurate as it grows. Verify any inferences with human sources.

* [[The Conception of EDURange]] [2011]: Conceptually, EDURange started around 2011 when Jens, Michael Locasto, and Richard started talking about creating exercises for cybersecurity courses. The idea was generated at a dinner with Michael, Sergey Bratus, Brian Fite, and Richard. Brian was packet master for a competition called PacketWars, and he was looking for a way to be a player and not the one running the competition. ... - Richard

Category:Project History and Roadmaps

2025-06-30T17:14:41Z

Jwgranville: /* Timeline entries */

This is a page to collect our history, accomplishments, needs, goals and wishlist items.

The idea is to document all of the high-level material we've produced, such as publications, major code releases and trial results. This collection can then be used as a timeline of our work and trajectory.

As this content is developed we may want to adopt standards for how things are organized - particularly to distinguish between proposed goals, agreed-upon plans and retired items that are reference only.

When making pages for a code release or academic paper it would be great to include working permalinks to the resource in question, especially full text for literature. A brief statement including additional details would also be helpful - such as who contributed to it and when, and a description of the state of the project at the time.

Perhaps we could also include short biographical pages for contributors that care to share their information, but I'll wait to see what the group thinks of that before jumping in myself. ~Joe G

== Instructions ==
Do not write individual items here; this page is just for indexing and coordinating the entries under this category.

* First create a page with a title appropriate for your item. There's no hard convention yet, but strive for readability/searchability.
* In the source of that page, add the following on the first line: <code><nowiki>[[Category:Project History and Roadmap]]</nowiki></code>
* Your page will be automatically indexed into the category. You can also add an entry in the timeline below.

=== Page contents ===
Please include context for your items, as future contributors may use these accounts for research. Readers should not need to rely on edit history to determine the date and author. At a minimum, the page should include:

* Your identity as the writer.
* The date of the original post.
* The timespan, if the post refers to something that has already happened or has a concrete goal date.

=== Timeline entries ===
Please try to keep timeline entries to a brief paragraph. Include the name of the page, the time in question, and your name as author.

Do not add future items to this main timeline. Future goals that don't come to pass may need to be edited after the fact to avoid confusing readers - let's put such content in a dedicated place where it doesn't clutter up more reliable information.

== Project Timeline ==
This list may not stay accurate as it grows. Verify any inferences with human sources.

* [[The Conception of EDURange]] [time?]: Conceptually, EDURange started around 2011 when Jens, Michael Locasto, and Richard started talking about creating exercises for cybersecurity courses. The idea was generated at a dinner with Michael, Sergey Bratus, Brian Fite, and Richard. Brian was packet master for a competition called PacketWars, and he was looking for a way to be a player and not the one running the competition. ... - Richard

Category:Project History and Roadmaps

2025-06-30T17:12:17Z

Jwgranville: Added instructions

This is a page to collect our history, accomplishments, needs, goals and wishlist items.

The idea is to document all of the high-level material we've produced, such as publications, major code releases and trial results. This collection can then be used as a timeline of our work and trajectory.

As this content is developed we may want to adopt standards for how things are organized - particularly to distinguish between proposed goals, agreed-upon plans and retired items that are reference only.

When making pages for a code release or academic paper it would be great to include working permalinks to the resource in question, especially full text for literature. A brief statement including additional details would also be helpful - such as who contributed to it and when, and a description of the state of the project at the time.

Perhaps we could also include short biographical pages for contributors that care to share their information, but I'll wait to see what the group thinks of that before jumping in myself. ~Joe G

== Instructions ==
Do not write individual items here; this page is just for indexing and coordinating the entries under this category.

* First create a page with a title appropriate for your item. There's no hard convention yet, but strive for readability/searchability.
* In the source of that page, add the following on the first line: <code><nowiki>[[Category:Project History and Roadmap]]</nowiki></code>
* Your page will be automatically indexed into the category. You can also add an entry in the timeline below.

=== Page contents ===
Please include context for your items, as future contributors may use these accounts for research. Readers should not need to rely on edit history to determine the date and author. At a minimum, the page should include:

* Your identity as the writer.
* The date of the original post.
* The timespan, if the post refers to something that has already happened or has a concrete goal date.

=== Timeline entries ===
Do not add future items to this main timeline. Future goals that don't come to pass may need to be edited after the fact to avoid confusing readers - let's put such content in a dedicated place where it doesn't clutter up more reliable information.

Please try to keep timeline entries to a brief paragraph. Include the name of the page, the time in question, and your name as author.

== Project Timeline ==
This list may not stay accurate as it grows. Verify any inferences with human sources.

* [[The Conception of EDURange]] [time?]: Conceptually, EDURange started around 2011 when Jens, Michael Locasto, and Richard started talking about creating exercises for cybersecurity courses. The idea was generated at a dinner with Michael, Sergey Bratus, Brian Fite, and Richard. Brian was packet master for a competition called PacketWars, and he was looking for a way to be a player and not the one running the competition. ... - Richard

The Conception of EDURange

2025-06-30T16:43:35Z

Jwgranville:

[[Category:Project History and Roadmaps]]

Conceptually, EDURange started around 2011 when Jens, Michael Locasto, and Richard started talking about creating exercises for cybersecurity courses. The idea was generated at a dinner with Michael, Sergey Bratus, Brian Fite, and Richard. Brian was packet master for a competition called PacketWars, and he was looking for a way to be a player and not the one running the competition. He had a number of innovative ideas. He wanted a way to specify competition environments, so that they could be replicated in different frameworks and they would be comparable, i.e. a standardization methodology for attack-defense competitions.

Michael was interested in the question of what makes a great cybersecurity expert. Someone who not only knows the tools but also how to apply them in innovative ways. For Michael, this was captured by the concept of analysis skills. It is the ability to see patterns in large complex data or systems. There were only a few frameworks available at the time: SEED labs, The Rave, and DeterLab. In our view, their exercises did not emphasize analysis, and the problem was that we could not modify them to create ones that did. A vision we had was that analysis takes time and doesn’t fit into a 2 hour slot. Sometimes you need to think about a problem for days before a breakthrough happens. Our idea was that you needed repeatable exercises that students could come back to. The closest we have come to that is the last challenge in SSH Inception, where as soon as bash runs, it logs the user out. The tension is that students want something that they can complete in a fixed short amount of time. Perhaps we need that for introductory exercises but can move away from that in the more advanced ones. Also, there are different ways to implement such an open-ended approach. It could be that the scenario can be suspended and re-started, or there would be multiple levels within the scenario, or there would be multiple versions of the scenario that require the same type of analysis.

- Richard

2025-06-29

Main Page

2025-06-30T16:35:57Z

Jwgranville: /* Developer Links */

Welcome to the EDURange Wiki. This is less of a formal documentation as it is a living document.

I think that if it's a choice between losing track of people's contributions and having a messy wiki, I'd much prefer a messy wiki. It's my hope that we can gather all of our notes, thoughts, and loosely related ephemera here, rather than having it scattered across correspondence and various sharing platforms.

We don't have many conventions yet. Please follow the Golden Rule and treat others as you would be treated. Put your name on your changes. Consider posting to the discussion tab or appending to a page rather than overwriting it. Try not to overwrite the personal work of others.

If it's installable/runnable/code of any sort, put it on GitHub as well - preferably under the edurange organization so that our future contributors will have seamless access to it too.

Thanks for your time.

~Joe G

== The EDURange Project ==
[[:Category:Project History and Roadmaps|Project History and Roadmaps]]

== Developer Links ==
[[Style Guidelines and Developer Tools]]

[[Reference Materials]]

[[:Category:Demonstrations|Demonstrations]]

[[Design Stories (OLD)]]

[[Interface Design]]

[[Scenario Creation Guide]]

[[Terraform Design]]

[[Hosting Requirements]]

[[Domain Modeling]]

We're still figuring out Media Wiki, so I kept the following...

== Orphaned Default Media Wiki Content ==
<strong>Welcome to the EDURange Wiki</strong>

Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.

== Getting started with Media Wiki ==
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

Category:Project History and Roadmaps

2025-06-30T16:34:17Z

Jwgranville: Created page with "This is a page to collect our history, accomplishments, needs, goals and wishlist items. The idea is to document all of the high-level material we've produced, such as publications, major code releases and trial results. This collection can then be used as a timeline of our work and trajectory. As this content is developed we may want to adopt standards for how things are organized - particularly to distinguish between proposed goals, agreed-upon plans and retired item..."

The Conception of EDURange

2025-06-30T16:32:05Z

Jwgranville: Created page with "Category:Project History and Roadmaps Conceptually, EDURange started around 2011 when Jens, Michael Locasto, and Richard started talking about creating exercises for cybersecurity courses. The idea was generated at a dinner with Michael, Sergey Bratus, Brian Fite, and Richard. Brian was packet master for a competition called PacketWars, and he was looking for a way to be a player and not the one running the competition. He had a number of innovative ideas. He wanted..."

Keystroke Observers

2025-06-26T22:15:24Z

Jwgranville: Disambiguated terms in explanation

[[Category:Demonstrations]]
See https://github.com/edurange/demo-keystroke-observers.

Demonstrates a one-writer-multiple-reader message topology for log processing.

== Instructions ==
To run it one can start:
./[https://github.com/edurange/demo-keystroke-observers/blob/main/toy_logger_tcp_0_1_3.py toy_logger_tcp_0_1_3.py]
Then, connect to local port 5554 and 5555 with a TTY utility such as [https://netcat.sourceforge.net netcat]:
nc 127.0.0.1 5554
5554 mocks the behavior of ttylog and analyzes the input received. 5555 demonstrates that another interface, such as the guide or web GUI, could be simultaneously monitored and handled by different behavior.

== Explanation ==
This is a proposal for a new communication strategy in the log pipeline. This would exist in a place analogous to the space between [https://github.com/edurange/edurange3/blob/main/scenarios/global_scripts/ttylog ttylog], [https://github.com/edurange/edurange3/blob/main/scenarios/global_scripts/analyze.py analyze.py] and [https://github.com/edurange/edurange3/blob/main/scenarios/global_scripts/milestone-lbl.pl milestone-lbl.pl] in the current implementation; see also https://github.com/edurange/edurange3/tree/main/scenarios/global_scripts.

LineByLineTotalizer buffers incoming data until a newline character is observed, similar to analyze.py used in previous versions. There has previously been interest in the timing not just between newlines, but all keystrokes. But analyze.py does not record this.

ImmediateTotalizer, FixedIntervalTotalizer and DynamicIntervalTotalizer demonstrate alternative policies for how often to count and potentially timestamp the contents of the input buffer. These classes implement the [[wikipedia:Observer_pattern|Observer]] pattern as a Python [https://typing.python.org/en/latest/spec/protocol.html protocol] (update()), allowing them to respond to messages broadcast from Subject instances. See observerdemo_0_1_1.py.

By broadcasting log events to all Observer instances, every log processor can have equal access to the original log data without resource conflicts or individual synchronization. See toy_logger_tcp_0_1_3.py.

Rather than continue to modify and grow the features/responsibilities of analyze.py, I propose this method of creating a data pipeline that obeys the [[wikipedia:Open–closed_principle|Open-Closed Principle]], meaning that it is closed to code changes, but open to behavior extension by means of a pluggable interface; in this example, Subject.attach(). See observerdemo_0_1_1.py.

Main Page

2025-06-26T21:25:09Z

Jwgranville:

Welcome to the EDURange Wiki. This is less of a formal documentation as it is a living document.

I think that if it's a choice between losing track of people's contributions and having a messy wiki, I'd much prefer a messy wiki. It's my hope that we can gather all of our notes, thoughts, and loosely related ephemera here, rather than having it scattered across correspondence and various sharing platforms.

We don't have many conventions yet. Please follow the Golden Rule and treat others as you would be treated. Put your name on your changes. Consider posting to the discussion tab or appending to a page rather than overwriting it. Try not to overwrite the personal work of others.

If it's installable/runnable/code of any sort, put it on GitHub as well - preferably under the edurange organization so that our future contributors will have seamless access to it too.

Thanks for your time.

~Joe G

== The EDURange Project ==
[[Project History and Roadmaps]]

== Developer Links ==
[[Style Guidelines and Developer Tools]]

[[Reference Materials]]

[[:Category:Demonstrations|Demonstrations]]

[[Design Stories (OLD)]]

[[Interface Design]]

[[Scenario Creation Guide]]

[[Terraform Design]]

[[Hosting Requirements]]

[[Domain Modeling]]

We're still figuring out Media Wiki, so I kept the following...

== Orphaned Default Media Wiki Content ==
<strong>Welcome to the EDURange Wiki</strong>

Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.

== Getting started with Media Wiki ==
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

Reference Materials

2025-06-26T21:23:42Z

Jwgranville:

I have hard copies of many of these titles available to borrow. ~Joe G
* Manifesto for Agile Software Development
** Available free online at https://agilemanifesto.org/
* Agile Software Development: Principles, Patterns, and Practices by Robert Martin
* Architecture Patterns with Python: Enabling Test-Driven Development, Domain-Driven Design, and Event-Driven Microservices by Harry Percival, Bob Gregory
** Available free online at http://cosmicpython.com/
* Test-Driven Development with Python: Obey the Testing Goat: Using Django, Selenium, and JavaScript by Harry Percival
** Available free online at http://www.obeythetestinggoat.com/
* Domain-Driven Design by Eric Evans
* Implementing Domain-Driven Design by Vaughn Vernon
* Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma et al
* Agile Software Development with Scrum by Ken Schwaber, Mike Beedle
* The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt, David Thomas
* Extreme Programming Explained: Embrace Change by Kent Beck, Cynthia Andres
* Test Driven Development: By Example by Kent Beck
* Articulating Design Decisions by Tom Greever
* Python Testing with pytest by Brian Okken
* Unit Testing: Principles, Practices and Patterns by Vladimir Khorikov
* Effective Python by Brett Slatkin
* Robust Python: Write Clean and Maintainable Code by Patrick Viafore
* Python in Practice: Create Better Programs Using Concurrency, Libraries, and Patterns by Mark Summerfield
* Fluent Python: Clear, Concise, and Effective Programming by Luciano Ramalho
* Growing Object-Oriented Software, Guided by Tests by Steve Freeman, Nat Pryce
* Essential Software Architecture by Ian Gorton
* Refactoring: Improving the Design of Existing Code by Paul Becker, Martin Fowler, Kent Beck
* Practical UNIX by Steve Moritsugu
* Unix in a Nutshell: System V Edition by Arnold Robbins
* Unix System V: A Practical Guide by Mark G Sobell
* The Design of the UNIX Operating System by Maurice Bach
* The UNIX Programming Environment by Brian W Kernighan
* Programming Perl by Tom Christiansen, Brian Foy, Larry Wall
* The New Hacker's Dictionary by Guy L. Steele
* The Algorithm Design Manual by Steven Skeina
* Structure and Interpretation of Computer Programs by Harold Abelson, Jay Sussman, Julie Sussman

Main Page

2025-06-26T21:00:50Z

Jwgranville: Add link for new category: project history

Welcome to the EDURange Wiki. This is less of a formal documentation as it is a living document.

I think that if it's a choice between losing track of people's contributions and having a messy wiki, I'd much prefer a messy wiki. It's my hope that we can gather all of our notes, thoughts, and loosely related ephemera here, rather than having it scattered across correspondence and various sharing platforms.

We don't have many conventions yet. Please follow the Golden Rule and treat others as you would be treated. Put your name on your changes. Consider posting to the discussion tab or appending to a page rather than overwriting it. Try not to overwrite the personal work of others.

If it's installable/runnable/code of any sort, put it on GitHub as well - preferably under the edurange organization so that our future contributors will have seamless access to it too.

Thanks for your time.

~Joe G

== The EDURange Project ==
[[Project History and Roadmaps]]

== Developer Links ==
[[Style Guidelines and Developer Tools]]

[[Reference Materials]]

[[:Category:Demonstrations|Demonstrations]]

[[Design Stories (OLD)]]

[[Interface Design]]

[[Scenario Creation Guide]]

[[Terraform Design]]

[[Hosting Requirements]]

[[Domain Modeling]]

== Orphaned Default Media Wiki Content ==
<strong>Welcome to the EDURange Wiki</strong>

Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.

== Getting started with Media Wiki ==
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

TTY Logging with BPF

2025-06-20T20:32:32Z

Jwgranville: /* Instructions */

Category:Demonstrations

2025-06-20T19:01:37Z

Jwgranville: /* Demo Projects */ Fixed wrong URL

Let's collect self-contained examples and demos here. I'm imagining this to be a space for demos that don't link to the main software stack, and focus on implementing a single feature or concept at a time.

Preferably, they should use no external dependencies, or have only a single external dependency. They should be easy to install and run without extra knowledge - the main usage method should be readily apparent and the code should follow documentation conventions.

Most importantly, these should be short and easy to read, because their purpose is to teach the group. It would be great if we could demonstrate, discuss and come to understand these projects within one or two group meetings.

== Demo Projects ==
These demonstrate or introduce new concepts, conventions, libraries, patterns, etc.

* [[Namedpipe Log Writer]] - https://github.com/edurange/demo-namedpipe-log-writer
* [[Keystroke Observers]] - https://github.com/edurange/demo-keystroke-observers
* [[TTY Logging with BPF]] - https://github.com/edurange/demo-bpf-tty-logger/

Category:Demonstrations

2025-06-20T18:56:24Z

Jwgranville: /* Demo Projects */ Add TTY Logging with BPF demo

TTY Logging with BPF

2025-06-20T18:55:22Z

Jwgranville: Created page with "Category:Demonstrations See https://github.com/edurange/demo-bpf-tty-logger. Demonstrates how to capture TTY activity using BPF kernel probes. == Instructions == To run it one needs to have superuser privileges (for kernel access). The probes intercept all TTY activity on the host system - both inside and outside of containers. If the script is printing to a TTY device the prints will also be observed, creating a feedback loop that will quickly consume the kernel b..."

Keystroke Observers

2025-06-20T18:53:47Z

Jwgranville: Touch up style

[[Category:Demonstrations]]
See https://github.com/edurange/demo-keystroke-observers.

Demonstrates a one-writer-multiple-reader message topology for log processing.

== Instructions ==
To run it one can start:
./[https://github.com/edurange/demo-keystroke-observers/blob/main/toy_logger_tcp_0_1_3.py toy_logger_tcp_0_1_3.py]
Then, connect to local port 5554 and 5555 with a TTY utility such as [https://netcat.sourceforge.net netcat]:
nc 127.0.0.1 5554
5554 mocks the behavior of ttylog and analyzes the input received. 5555 demonstrates that another interface, such as the guide or web GUI, could be simultaneously monitored and handled by different behavior.

== Explanation ==
This is a proposal for a new communication strategy in the log pipeline. This would exist in a place analogous to the space between [https://github.com/edurange/edurange3/blob/main/scenarios/global_scripts/ttylog ttylog], [https://github.com/edurange/edurange3/blob/main/scenarios/global_scripts/analyze.py analyze.py] and [https://github.com/edurange/edurange3/blob/main/scenarios/global_scripts/milestone-lbl.pl milestone-lbl.pl] in the current implementation; see also https://github.com/edurange/edurange3/tree/main/scenarios/global_scripts.

LineByLineTotalizer buffers incoming data until a newline character is observed, similar to analyze.py used in previous versions. There has previously been interest in the timing not just between newlines, but all keystrokes. But analyze.py does not record this.

ImmediateTotalizer, FixedIntervalTotalizer and DynamicIntervalTotalizer demonstrate alternative policies for how often to count and potentially timestamp the contents of the input buffer. These classes implement the [[wikipedia:Observer_pattern|Observer]] [https://typing.python.org/en/latest/spec/protocol.html protocol] (update()), allowing them to respond to messages broadcast from Subject instances. See observerdemo_0_1_1.py.

By broadcasting log events to all Observer instances, every log processor can have equal access to the original log data without resource conflicts or individual synchronization. See toy_logger_tcp_0_1_3.py.

Rather than continue to modify and grow the features/responsibilities of analyze.py, I propose this method of creating a data pipeline that obeys the [[wikipedia:Open–closed_principle|Open-Closed Principle]], meaning that it is closed to code changes, but open to behavior extension by means of a pluggable interface; in this example, Subject.attach(). See observerdemo_0_1_1.py.