Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a policy page and move instructions to join the infra #125

Closed
wants to merge 1 commit into from
Closed

Create a policy page and move instructions to join the infra #125

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions content/join/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
---
title: Joining the infrastructure
nav_order: 7
has_children: true
---

# Joining the infrastructure
10 changes: 5 additions & 5 deletions content/faq/join_infrastructure.md → content/join/instructions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
---
title: Joining the SCIONLab infrastructure
parent: Frequently Asked Questions
nav_order: 10
title: Instructions
parent: Joining the infrastructure
nav_order: 20
---

# Joining the SCIONLab infrastructure
# Instructions

If you are part of an organization and/or you are committed to do research with SCION, and using user ASes is not enough for your plans, then you could join SCIONLab with a dedicated host. We have compiled a short guide to document the requirements.
You can join the SCIONLab network as an infrastructure AS with one or more machines, or you can start as small as dedicating only a simple commodity PC.
Expand All @@ -15,7 +15,7 @@ This page is supposed to give you a general overview over joining as a part of t

## Procedure

1. [Get in contact with us](../../#contact) telling you want to join the infrastructure.
1. Read [the policy](policy.html) and [get in contact with us](../../#contact) letting us know you want to join the infrastructure.
2. Once the node(s) are ready on your side, create a `scionlab` user with full `sudo` rights and access for the SCIONLab team.
3. The SCIONLab admins will perform measurements to find the most appropriate neighbors to your AS. We will notify you of the result.
4. Once the neighboring ASes have been decided, the administrators will install SCION services and configure monitoring for the node(s).
Expand Down
31 changes: 31 additions & 0 deletions content/join/policy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
---
title: Policy
parent: Joining the infrastructure
nav_order: 10
---

# Policy

In order to ensure proper testbed operation and maintenance we require that all sites (external and internal) abide by the policies outlined below.

1. Provide one or more dedicated machines on-site to act as the SCIONLab nodes. The machine should not be used for any other tasks beyond its role as a SCIONLab node.
2. Provide root (or sudo) access to the SCIONLab management institution (currently ETH Zurich).
3. Allow the SCIONLab management institution to install, remove and update SCIONLab-related software as needed for the operation and maintenance of the network.
4. Work with the SCIONLab management institution to solve any firewall and tunneling issues that may arise during the installation, configuration and operation of the SCIONLab node(s).
5. Provide the name, email and telephone information of an easily and quickly reachable site-specific operator who will be the main contact whenever issues arise with the local SCIONLab node(s). A backup operator, while not required, is highly encouraged. Operator email addresses must belong to the institution. All local operators will be required to join and regularly monitor the SCIONLab community mailing list and are required to respond to requests from the testbed management institution in a reasonable time, but no more than 3 working days.
6. Ensure that the machine has limited logins beyond the SCIONLab account. A local operator account is highly encouraged, but general user accounts should not be present on the SCIONLab node. In addition, only SCIONLab-related software should be allowed to run on the machine.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this actually true? Don't we want to allow e.g. active researchers that do stuff with SCIONLab to have access to the machines? (Maybe not, because researchers mess things up :D but if not, then who exactly is the target group for joining the infra?)

Copy link
Contributor Author

@mkowalski mkowalski Dec 4, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is very true. If they want to play with the machine, they should be using user AS. I do not trust any of this dudes to do anything inside this machine and not breaking stuff

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, but:

  • we say "[blablabla] you are committed to do research with SCION, and using user ASes is not enough for your plans" in instructions.md
  • we say "Connecting to the testbed for the sake of being connected is a violation of the current policies" in policy.md

So that sounds to me like we want people to join the infra when they want to do fancy research with it.

And then we say "limited logins beyond the SCIONLab account" here, so that they cannot do fancy research with it :D

So, it seems to me that these three things together strongly limit who is supposed to be joining the infra and why. The only use case that I can come up with while satisfying all three is just something like "we really really want a local attachment point". Is this actually the only use case? If no, please tell me about another one :D And if yes, should we just say that explicitly at the beginning of instructions.md?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, let me give you a specific example. We have a SCIONLab node somewhere in Austria (I believe TU Vienna), where some "Charlie dude" logs into the machine and changes configuration of the SCION services to something super dumb, making the services fail hard during the start-up. As this is not transparent for the rest of the network, I do not want him to be allowed to misconfigure stuff. By this I mean the configuration of the infrastructure should be stable and deterministic and someone ssh-ing and modifying random files contradicts both these points.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me give you a second example. We used to have a node in Israel which was not used by anyone for an unknown amount of time. Once this node has died (i.e. went no-contact without anybody informing us) it took these guys more than 3 months to reply to Juan's email. I need a mechanism to enforce a strong reaction in these cases as I do not want SCIONLab to become a graveyard of machines which used to work once and nothing more.

7. The machine may be a dedicated physical box or a virtual machine with a publicly routable IP address (i.e., should not be behind a NAT). The local operators should ensure that if the machine has usage limits or other restrictions (for example VMs on cloud services), those will not interfere with proper testbed operation.
8. In case more than one machine is being provided by the institution, it is allowed if only one of them has a publicly routable IP address whereas the others use private static IP.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to cover the following use case

  • multi-host AS
  • border router has a public static IP for the uplink connectivity
  • services inside AS talk with each other using static private IPs (because public are not needed as long as inside-AS connectivity works)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about having having multiple border routers for uplink?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a valid scenario, we should then write something closer to "machines hosting border routers must have a public static IPv4 address"

9. All SCIONLab nodes will run the same operating system, i.e. Ubuntu LTS release. Updates to the operating system will be managed by the SCIONLab network operations team. The local operator at a site will be responsible for the initial operating system installation. Specific instructions for that installation will be made available.
10. Suggested Hardware: 4 CPUs, 8 GB of RAM and 40 GB of disk space.
11. Suggested Location: SCIONLab node should reside in a machine room in a rack.
12. Suggested Network Connectivity: There is no minimum bandwidth requirement for SCIONLab nodes; however, higher network speeds are both recommended and desirable.
13. Participating institutions may disconnect from the testbed upon giving appropriate (at least 24 hours) notice to the SCIONLab testbed management institution. The same policy applies if the participating institution wishes to turn off the machine for maintenance and/or hardware upgrades. Early notification will allow the testbed management institution to take any actions necessary to prevent unnecessary disruption of service to the testbed.
14. We strongly discourage and will not accept requests to join the SCIONLab testbed if there is no intention to use it for productive research. Connecting to the testbed for the sake of being connected is a violation of the current policies.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(does this mean that like half of our nodes are in violation of the current policies? :D)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to make it clear, this does not mean we are removing half of the nodes from day 1. This only means once we have a node which obviously misbehaves and no one reacts in a reasonable amount of time, we have a CYA to throw at them and enforce an action (this being either cooperation or removal).

15. The SCIONLab testbed management institution reserves the right to refuse or disconnect from the testbed any node that is found not to comply with the above policies, engages in abusive behavior, has non-responsive operators, and in general is deemed to either add no value or be a detriment to the general testbed operation.

If the above policies cannot be met, we still encourage new institutions to [contact the SCIONLab team](../../#contact) to discuss connection with the testbed. Connection approval lies solely with the SCIONLab testbed management institution, but every effort will be made to accommodate connection requests.

{% include alert type="note" content="
The policy is based on the [Policies for Connecting Nodes to the NDN Testbed](https://named-data.net/ndn-testbed/policies-connecting-nodes-ndn-testbed/)
" %}