pivilion/README.md

74 lines
3.9 KiB
Markdown
Raw Normal View History

2016-11-29 01:24:59 +00:00
[Manual](https://gitlab.com/hacklab01/pivilion/wikis/pivilion-manual-setup)
2016-11-26 11:01:28 +00:00
2022-06-30 21:55:29 +00:00
Pivilion is a decentralizing open source darknet web server project and gallery management software for the creation of autonomous & uncensored digital media art online galleries. It runs on low cost Raspberry Pi hardware and is built on top of Raspbian GNU/Linux with a server and Tor networking built in, utilizing the Tor network to host exhibitions out of the box.
2016-11-25 00:19:44 +01:00
2022-06-30 21:55:29 +00:00
Each Pivilion device receives a Tor onion domain automatically the first time its activated. The system provides the user with a CMS for publishing multimedia or websites within a gallery. Its designed so that the author-curator can use any network (even public networks behind firewalls) to host an online exhibition.
2016-11-25 00:19:44 +01:00
2022-06-30 21:55:29 +00:00
Pivilion is primarily a long-term, open-ended new media art project propagating autonomous modes of art in the darknet, and is continuously including a large number of artists and cultural workers in its creation.
2016-11-25 00:19:44 +01:00
2022-06-30 21:55:29 +00:00
The documentation and the announcement of global #pivilion_dot events are available via the central website, hosted both on clearnet and as a hidden service on the Tor network, while the entire open source system is available via git.
2016-11-25 00:19:44 +01:00
2022-06-30 21:55:29 +00:00
Project website: [pivilion.net](https://pivilion.net/)
2016-11-25 00:19:44 +01:00
Required hardware:
2022-06-30 22:03:23 +00:00
- Raspberry Pi with WiFi
2016-11-24 23:25:07 +00:00
- min 8 GB SD card
2022-06-30 21:55:29 +00:00
- battery or power adapter
## Installation on current Raspberry Pi OS
Pivilion supports Raspberry Pi OS Bullseye, Bookworm, and Trixie. Bookworm and
newer systems use NetworkManager automatically; Bullseye installations using
`dhcpcd` use the legacy hostapd backend. The repository layout and the original
commands are preserved on both backends.
On a fresh Raspberry Pi OS Lite installation:
```sh
git clone https://gitlab.com/hacklab01/pivilion.git
cd pivilion
sudo ./install.sh
sudo reboot
```
The installer performs preflight checks, backs up managed configuration under
`/var/backups/pivilion`, validates the deployed services, and restores the
previous configuration if deployment fails. Additional maintenance modes are:
```sh
./install.sh --dry-run # read-only preflight and proposed actions
sudo ./install.sh --check # validate an existing installation
sudo ./install.sh --repair # repeat deployment without replacing gallery content
```
The installer defaults to the user that invoked `sudo`, not to a hard-coded
`pi` account. To customize paths, startup mode, hotspot SSID, or Wi-Fi
interface, copy `pivilion.conf.example` to `/boot/firmware/pivilion.conf` (or
`/etc/pivilion.conf`) and edit it before installing. The hotspot is intentionally
open and passwordless.
Use `pikey` to save upstream Wi-Fi credentials, then `onion` and reboot to host
through Tor. Use `hotspot` and reboot to run the local captive gallery at
`http://10.1.1.1/`. HTTPS interception is intentionally not attempted because a
local captive portal cannot present valid certificates for arbitrary sites.
If a phone joins but does not open its captive-login window, run
`pivilion diagnose` on the Pi to verify DHCP/DNS, Apache rewrite handling,
nftables, and the common Android, Apple, and Microsoft HTTP probes.
`pivilion status` distinguishes the requested next-boot mode from the last
verified active mode and reports degraded activation. `pivilion diagnose
--json` provides the same health checks for monitoring. The legacy
`pivilion-diagnose` command remains an alias.
2026-06-29 23:08:56 +02:00
On the physical TTY, Pivilion appends its current IP, ASCII logo, and system
status through `/etc/issue.d/90-pivilion.issue`; Raspberry Pi OS retains its
normal Debian/hostname/TTY heading. The banner appears before `login:` rather
than among systemd boot messages. SSH sessions receive the same status once
after authentication.
Diagnostic exit codes are stable: `10` invalid configuration, `11` missing or
unsupported hardware, `12` service/port conflict, `13` core service failure,
`14` captive portal failure, `15` Tor/onion failure, and `20` installer failure.