nsfarm issueshttps://gitlab.nic.cz/turris/nsfarm/-/issues2022-03-15T14:38:49+01:00https://gitlab.nic.cz/turris/nsfarm/-/issues/35Basic firewall testing2022-03-15T14:38:49+01:00Karel KociBasic firewall testingWe should test firewall.
* [ ] Zone separation and forwarding
* [ ] Port forwarding
* [ ] Block and accept network rule
* [ ] MasquaradeWe should test firewall.
* [ ] Zone separation and forwarding
* [ ] Port forwarding
* [ ] Block and accept network rule
* [ ] Masquaradehttps://gitlab.nic.cz/turris/nsfarm/-/issues/24Farm rack preparation2021-09-08T10:13:37+02:00Karel KociFarm rack preparationWe now have nice shining (ok not shining) rack to put nsfarm in to. These are steps to get it available to all of us.
![IMG_20191114_153245](/uploads/7bd7316d60068006ef008b81568d7331/IMG_20191114_153245.jpg)
* [x] mount two remaining s...We now have nice shining (ok not shining) rack to put nsfarm in to. These are steps to get it available to all of us.
![IMG_20191114_153245](/uploads/7bd7316d60068006ef008b81568d7331/IMG_20191114_153245.jpg)
* [x] mount two remaining shelf to rack
* [x] get velcro strip to attach the Turris Omnia boxes
* [x] buy 1 m long patch cables (20 pieces) in blue and grey colors (OFC preffered)
* [x] attach the power supplies to the bottom of the shelves
* [ ] move PC to bottom of rack
* [x] install Debian unstable to PC
* ansible PC
* [x] Install and configure LXD for NSFarm
* [x] Create users (at least kkoci and jbetik)
* [x] grand those users access to LXD and to serial devices (groups lxd and dialout)
* [ ] make server accessible trough turris domain (possibly `nsfarm.turris.cz`?)
* [ ] generate central configuration for nsfarm (`/etc/nsfarm.yml`) (blocked by https://gitlab.labs.nic.cz/turris/nsfarm/issues/7)
* [ ] connect and configure both omnias we have so farLukas JelinekLukas Jelinek2020-10-23https://gitlab.nic.cz/turris/nsfarm/-/issues/6Setup utilities for all fixtures to use2022-02-15T18:14:07+01:00Karel KociSetup utilities for all fixtures to useMost of the work done in fixtures is some sort of configuration done. Every fixture have to later revert its changes (otherwise it taints environment). To make it clean as much as possible we should simplify common configuration tasks. T...Most of the work done in fixtures is some sort of configuration done. Every fixture have to later revert its changes (otherwise it taints environment). To make it clean as much as possible we should simplify common configuration tasks. The idea is to have objects with ability to track changes and reverting them on context leave. Imagine for example following code:
```python
with nsfarm.setup.Setup() as setup:
setup.preserve("/etc/passwd")
board_serial.run('echo root:"{}" | chpasswd'.format(password))
yield
```
This is going to set root password but preserves content of `/etc/passwd` so when fixture is teared down it restores original content (note that this is not a good idea but rather just an example).
We should have basic general setups handling following areas
* [x] Preserve files content (for arbitrary file)
* [x] Preserve path existence/non-existence (for directories)
* [ ] UCI
More specific setups:
* [x] root password setup
* [ ] local time setup
* [x] various uplink setups
* [x] static IP
* [x] DHCP
* [x] PPPOE
* [x] updater setup (target branch/version/build)