|
|
The [APUs](https://www.pcengines.ch/apu2.htm) are neat little devices from [PC Engines](https://www.pcengines.ch/). We use
|
|
|
them as jump hosts and, generally, low-power servers where we need
|
|
|
them.
|
|
|
|
|
|
This documentation was written with a [APU3D4](https://www.pcengines.ch/apu3d4.htm), some details may
|
|
|
vary with other models.
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
# Tutorial
|
|
|
|
|
|
# How to
|
|
|
|
|
|
## Console access
|
|
|
|
|
|
The APU comes with a DB-9 serial port. You can connect to that port
|
|
|
using, typically, a [null modem cable](https://en.wikipedia.org/wiki/Null_modem) and a serial-to-USB
|
|
|
adapter. Once properly connected, the device will show up as
|
|
|
`/dev/ttyUSB0` on Linux. You can connect to it with [GNU screen](https://www.gnu.org/software/screen/)
|
|
|
with:
|
|
|
|
|
|
screen /dev/ttyUSB0 115200
|
|
|
|
|
|
... or with plain [cu(1)](https://manpages.debian.org/cu):
|
|
|
|
|
|
cu -l /dev/ttyUSB0 -s 115200
|
|
|
|
|
|
On boot, you should be able to see the APU's BIOS on the serial
|
|
|
console.
|
|
|
|
|
|
## Memory test
|
|
|
|
|
|
The boot menu (<kbd>F10</kbd>) provides a built-in memory test which
|
|
|
runs Memtest86 5.01+ and looks something like this:
|
|
|
|
|
|
Memtest86+ 5.01 coreboot 001| AMD GX-412TC SOC
|
|
|
CLK: 998.3MHz (X64 Mode) | Pass 6% ##
|
|
|
L1 Cache: 32K 15126 MB/s | Test 67% ##########################
|
|
|
L2 Cache: 2048K 5016 MB/s | Test #5 [Moving inversions, 8 bit pattern]
|
|
|
L3 Cache: None | Testing: 2048M - 3584M 1536M of 4079M
|
|
|
Memory : 4079M 1524 MB/s | Pattern: dfdfdfdf | Time: 0:03:49
|
|
|
------------------------------------------------------------------------------
|
|
|
Core#: 0 (SMP: Disabled) | CPU Temp | RAM: 666 MHz (DDR3-1333) - BCLK: 100
|
|
|
State: - Running... | 48 C | Timings: CAS 9-9-10-24 @ 64-bit Mode
|
|
|
Cores: 1 Active / 1 Total (Run: All) | Pass: 0 Errors: 0
|
|
|
------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PC Engines APU3
|
|
|
(ESC)exit (c)configuration (SP)scroll_lock (CR)scroll_unlock (l)refresh
|
|
|
|
|
|
## Pager playbook
|
|
|
|
|
|
<!-- information about common errors from the monitoring system and -->
|
|
|
<!-- how to deal with them. this should be easy to follow: think of -->
|
|
|
<!-- your future self, in a stressful situation, tired and hungry. -->
|
|
|
|
|
|
## Disaster recovery
|
|
|
|
|
|
<!-- what to do if all goes to hell. e.g. restore from backups? -->
|
|
|
<!-- rebuild from scratch? not necessarily those procedures (e.g. see -->
|
|
|
<!-- "Installation" below but some pointers. -->
|
|
|
|
|
|
# Reference
|
|
|
|
|
|
<!-- this section is a more in-depth review of how this service works, -->
|
|
|
<!-- how it's setup. day-to-day operation should be covered in -->
|
|
|
<!-- tutorial or how-to, this is more in-depth -->
|
|
|
|
|
|
<!-- a good guide to "audit" an existing project's design: -->
|
|
|
<!-- https://bluesock.org/~willkg/blog/dev/auditing_projects.html -->
|
|
|
<!-- the following sections are partially based on that -->
|
|
|
|
|
|
## Installation
|
|
|
|
|
|
<!-- how to setup the service from scratch -->
|
|
|
|
|
|
## Upgrades
|
|
|
|
|
|
<!-- how upgrades are performed. preferably automated through Debian -->
|
|
|
<!-- packages, otherwise document how upgrades are performed. see also -->
|
|
|
<!-- the Testing section below -->
|
|
|
|
|
|
## SLA
|
|
|
|
|
|
<!-- this describes an acceptable level of service for this service -->
|
|
|
|
|
|
## Design and architecture
|
|
|
|
|
|
<!-- how this is built -->
|
|
|
<!-- should reuse and expand on the "proposed solution" discussed in -->
|
|
|
<!-- a previous RFC or the Discussion section below. it's a -->
|
|
|
<!-- "as-built" documented, whereas the "Proposed solution" is an -->
|
|
|
<!-- "architectural" document, which the final result might differ -->
|
|
|
<!-- from, sometimes significantly -->
|
|
|
|
|
|
## Services
|
|
|
|
|
|
<!-- open ports, daemons, cron jobs -->
|
|
|
|
|
|
## Storage
|
|
|
|
|
|
<!-- databases? plain text file? the frigging blockchain? memory? -->
|
|
|
|
|
|
## Queues
|
|
|
|
|
|
<!-- email queues, job queues, schedulers -->
|
|
|
|
|
|
## Interfaces
|
|
|
|
|
|
<!-- e.g. web APIs, commandline clients, etc -->
|
|
|
|
|
|
## Authentication
|
|
|
|
|
|
<!-- SSH? LDAP? standalone? -->
|
|
|
|
|
|
## Implementation
|
|
|
|
|
|
<!-- programming languages, frameworks, versions, license -->
|
|
|
|
|
|
## Related services
|
|
|
|
|
|
<!-- dependent services (e.g. authenticates against LDAP, or requires -->
|
|
|
<!-- git pushes) -->
|
|
|
|
|
|
## Issues
|
|
|
|
|
|
<!-- such projects are never over. add a pointer to well-known issues -->
|
|
|
<!-- and show how to report problems. usually a link to the -->
|
|
|
<!-- issue tracker. consider creating a new Label to regroup the -->
|
|
|
<!-- issues if using the general tracker. see also TPA-RFC-19. -->
|
|
|
|
|
|
There is no issue tracker specifically for this project, [File][] or
|
|
|
[search][] for issues in the [team issue tracker][search] with the
|
|
|
label ~Foo.
|
|
|
|
|
|
[File]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/new
|
|
|
[search]: https://gitlab.torproject.org/tpo/tpa/team/-/issues?label_name%5B%5D=Foo
|
|
|
|
|
|
## Maintainer
|
|
|
|
|
|
<!-- document who deployed and operates this service, the team and -->
|
|
|
<!-- ideally the person inside that team -->
|
|
|
|
|
|
## Users
|
|
|
|
|
|
<!-- who the main users are, how they use the service. possibly reuse -->
|
|
|
<!-- the Personas section in the RFC, if available. -->
|
|
|
|
|
|
## Upstream
|
|
|
|
|
|
<!-- who the upstreams are, if they are still active, -->
|
|
|
<!-- collaborative, how do we keep up to date, support channels, see -->
|
|
|
<!-- also the "Issues" section above -->
|
|
|
|
|
|
## Monitoring and metrics
|
|
|
|
|
|
<!-- describe how this service is monitored, how security issues and -->
|
|
|
<!-- upgrades are tracked, see also "Upgrades" above. -->
|
|
|
|
|
|
## Tests
|
|
|
|
|
|
<!-- how the service can be tested, for example after major changes -->
|
|
|
<!-- like IP address changes or upgrades. describe CI, test suites, linting -->
|
|
|
|
|
|
## Logs
|
|
|
|
|
|
<!-- where are the logs? how long are they kept? any PII? -->
|
|
|
<!-- what about performance metrics? same questions -->
|
|
|
|
|
|
## Backups
|
|
|
|
|
|
<!-- does this service need anything special in terms of backups? -->
|
|
|
<!-- e.g. locking a database? special recovery procedures? -->
|
|
|
|
|
|
## Other documentation
|
|
|
|
|
|
<!-- references to upstream documentation, if relevant -->
|
|
|
|
|
|
# Discussion
|
|
|
|
|
|
<!-- the "discussion" section is where you put any longer conversation -->
|
|
|
<!-- about the project that you will not need in a casual -->
|
|
|
<!-- review. history of the project, why it was done the way it was -->
|
|
|
<!-- (as opposed to how), alternatives, and other proposals are -->
|
|
|
<!-- relevant here. -->
|
|
|
|
|
|
<!-- this at least partly overlaps with the TPA-RFC process (see -->
|
|
|
<!-- policy.md), but in general should defer to proposals when -->
|
|
|
<!-- available -->
|
|
|
|
|
|
## Overview
|
|
|
|
|
|
<!-- describe the overall project. should include a link to a ticket -->
|
|
|
<!-- that has a launch checklist -->
|
|
|
|
|
|
<!-- if this is an old project being documented, summarize the known -->
|
|
|
<!-- issues with the project. -->
|
|
|
|
|
|
## Security and risk assessment
|
|
|
|
|
|
<!--
|
|
|
|
|
|
5. When was the last security review done on the project? What was
|
|
|
the outcome? Are there any security issues currently? Should it
|
|
|
have another security review?
|
|
|
|
|
|
6. When was the last risk assessment done? Something that would cover
|
|
|
risks from the data stored, the access required, etc.
|
|
|
|
|
|
-->
|
|
|
|
|
|
## Technical debt and next steps
|
|
|
|
|
|
<!--
|
|
|
|
|
|
7. Are there any in-progress projects? Technical debt cleanup?
|
|
|
Migrations? What state are they in? What's the urgency? What's the
|
|
|
next steps?
|
|
|
|
|
|
8. What urgent things need to be done on this project?
|
|
|
|
|
|
-->
|
|
|
|
|
|
## Proposed Solution
|
|
|
|
|
|
<!-- Link to RFC -->
|
|
|
|
|
|
## Other alternatives
|
|
|
|
|
|
There are many single board computers out there. In our initial
|
|
|
research ([tpo/tpa/team#41058](https://gitlab.torproject.org/tpo/tpa/team/-/issues/41058)) we also found:
|
|
|
|
|
|
* [SolidRun Honeycomb](https://www.solid-run.com/arm-servers-networking-platforms/honeycomb-servers-workstation/#1u-server): can fit two ARM servers in a 1U case, SFP
|
|
|
ports, 64GB RAM, 16-core NXP 2GHz, a bit overkill
|
|
|
* [Turris Shield](https://www.turris.com/en/shield/specifications/): SOHO firewall appliance, not sure about Debian
|
|
|
compatibility
|
|
|
|
|
|
We also considered a [full 1U case](https://corpshadow.biz/alix-apu-enclosures) but that seemed really
|
|
|
costly. We have also considered a [HDD enclosure](https://store.rack-matrix.com/en/cases/324-pc-engines-alix-2d22d32d13-apu1apu2-case-with-hdd-wifi-black-3700667301379.html) but that didn't
|
|
|
seem necessary either. |