Soma-notes - User contributions [en]

DistOS 2021F Experience 2

2021-11-29T17:08:48Z

Housedhorse: Clarify question 3

= Introduction =

In this experience, you will be playing with a multi-node Kubernetes cluster simulated using <code>minikube</code>, running the [https://docs.cilium.io/en/v1.10/ Cilium CNI], a replicated [https://cassandra.apache.org/doc/latest/ Apache Cassandra] database and an updated version of our beloved “printerfacts” service that consumes facts stored in the Cassandra database. As usual, you may wish to consult the relevant documentation if you get stuck. Links to documentation will be provided along with hints later on in this document.

With the exception of Part 2, completing this experience shouldn’t take more than a couple of hours. Feel free to collaborate with other students if you get stuck. However, '''you must acknowledge any collaboration'''. Additionally, '''copying and pasting or simply “changing up” each other’s answers will be treated as an academic integrity violation'''.

== Submissions ==

Your experience report should be submitted as a PDF file on Brightspace, written in '''paragraph form'''. Code snippets or screenshots are allowed to augment your prose but are not required. We will post a submission link on Brightspace within the next few days.

The official due date for the experience report is December 10th (the last day of class), but we will continue to accept submissions up until the date of the final exam if you need extra time.

== Receiving Your Grade ==

This experience is broken up into three parts:

# A series of easy tasks designed to get you familiar Cilium, Cassandra, and a multi-node K8s cluster.
# A harder challenge that involves programming a client to interact with the Cassandra database and writing a custom Cilium security policy to lock down your cluster.
# An opportunity to reflect on this experience and make connections to overall themes in the course.

Students are expected to complete Part 1 and Part 3 to get a grade of at most a B+. '''Part 2 is optional''', but must be completed to receive a grade of A- or higher. Marks will be deducted for insufficient explanations or answers that demonstrate a lack of effort. By this logic, you should have a fairly clear idea of what grade you will receive when you submit this experience, based on how much effort you put in.

== Setting Up Your Environment ==

For this experience, a new VM image has been provided for you. It has a larger disk size, more RAM, and a batteries-included installation of the [https://github.com/cilium/cilium-cli Cilium] and [https://github.com/cilium/hubble Hubble] CLI. First, '''delete your old instance''' using the OpenStack web console, then create a new one. You can follow the [https://homeostasis.scs.carleton.ca/wiki/index.php/DistOS_2021F:_Using_Openstack same instructions as before], except replace the <code>COMP4000-studentvm-v1</code> image with <code>COMP4000-studentvm-v2</code>. When selecting your flavour, make sure you pick the flavour with '''16GiB of disk space and 8GB of RAM'''.

Once your VM is set up, SSH into it using your preferred SSH client. You should probably be working with at least 2 terminals for the rest of this experience. After SSHing into your instance, run the following command to spin up a multi-node k8s cluster: <code>minikube start -n3 --cni=cilium</code>. This might take a few minutes to run to completion.

Verify your cluster has started correctly using <code>minikube status</code>. You should see something like the following:

<pre>minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

minikube-m02
type: Worker
host: Running
kubelet: Running

minikube-m03
type: Worker
host: Running
kubelet: Running</pre>
=== Cilium and Hubble ===

Once your cluster is running, you can configure the cluster to use Cilium and Hubble. Due to some minikube and Cilium quirks, we need to uninstall the default version of Cilium installed by minikube and reinstall it using the Cilium CLI. You can do so with the following commands:

<pre>cilium uninstall && cilium install && cilium hubble enable</pre>
This may take a few minutes to run to completion.

You can run the command <code>cilium status</code> to check the status of your Cilium installation. Once everything has installed correctly, you should see something like the following when running <code>cilium status</code>:

<pre>student@alpine:~$ cilium status
/¯¯\
/¯¯\__/¯¯\ Cilium: OK
\__/¯¯\__/ Operator: OK
/¯¯\__/¯¯\ Hubble: OK
\__/¯¯\__/ ClusterMesh: disabled
\__/

Deployment cilium-operator Desired: 1, Ready: 1/1, Available: 1/1
Deployment hubble-relay Desired: 1, Ready: 1/1, Available: 1/1
DaemonSet cilium Desired: 3, Ready: 3/3, Available: 3/3
Containers: cilium Running: 3
cilium-operator Running: 1
hubble-relay Running: 1
Cluster Pods: 2/2 managed by Cilium
Image versions cilium quay.io/cilium/cilium:v1.10.5: 3
cilium-operator quay.io/cilium/operator-generic:v1.10.5: 1
hubble-relay quay.io/cilium/hubble-relay:v1.10.5: 1</pre>
=== Cassandra ===

We will be using the <code>helm</code> package manger to install Cassandra in our k8s cluster. To do so, run the following commands:

<pre>wget https://homeostasis.scs.carleton.ca/~will/cassandra.yml
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install cassandra bitnami/cassandra -f cassandra.yml</pre>
You can verify the status of your Cassandra installation using <code>kubectl get pods --watch</code>. Wait until both <code>cassandra-0</code> and <code>cassandra-1</code> show <code>1/1</code> under <code>READY</code>. This might take a few minutes. The output should look something like this:

<pre>student@alpine:~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 4m2s
cassandra-1 1/1 Running 0 2m8s</pre>
=== Printerfacts ===

The printerfacts service from last experience has received an upgrade to work with our new Cassandra database. First, run the migrations (provided as a batch job) to initialize the Cassandra database and populate it with some facts about printers:

<pre>wget https://homeostasis.scs.carleton.ca/~will/migrations.yml
kubectl apply -f migrations.yml</pre>
After applying the migrations, you’re ready to deploy the printerfacts service:

<pre>wget https://homeostasis.scs.carleton.ca/~will/deploy.yml
kubectl apply -f deploy.yml</pre>
Verify that printerfacts has been correctly deployed with <code>kubectl get pods</code>. You should see something like this:

<pre>student@alpine:~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 31m
cassandra-1 1/1 Running 0 30m
server-85f9f4465b-9vhn9 1/1 Running 0 38m
server-85f9f4465b-b7s2n 1/1 Running 0 38m
server-85f9f4465b-bvgqs 1/1 Running 0 38m
server-85f9f4465b-bwf42 1/1 Running 0 38m
server-85f9f4465b-gn5sm 1/1 Running 0 38m</pre>
Finally, run <code>minikube tunnel</code> in a separate terminal to set up port forwarding for our <code>LoadBalancer</code> API objects. This will enable you to interact with printerfacts from your VM, rather than needing to spin up a client pod like last time.

Verify that it worked correctly by running <code>curl 10.96.0.201</code> (this is the IP you will use to talk to printerfacts). Note that depending on your specific configuration, you may need to SSH into minikube using <code>minikube ssh</code> before you can access the load balancer service. If your curl command hangs forever, this may be the issue.

= Tasks =

== Part 1: Multi-Node Kubernetes, Cilium, and Cassandra (Easy) ==

Follow the instructions for each of the following numbered tasks. Make an effort to answer the accompanying questions, but more importantly please note down all of your observations and describe what you did for each task. You should also feel free to write down whatever questions you may have about a given task.

To achieve the best possible grade in this section, you must demonstrate that you have made an effort to understand the results of each task. (Note that an effort does not strictly mean a full understanding; it is okay to have questions!)

<ol style="list-style-type: decimal;">
<li>Thanks the Cilium CNI, your Kubernetes cluster has been outfitted with new eBPF superpowers. In particular, Cilium installs a series of eBPF programs into your (VM’s) kernel which can be used to monitor traffic between containers, pods, and nodes, as well as enforce L4–L7 security policy. To test out your new superpowers, run <code>cilium hubble port-forward&</code> followed by <code>hubble observe</code>. What is all that output? Can you make sense of any of it?
<ul>
<li>Hint 1: Try checking <code>hubble --help</code> and <code>hubble observe --help</code></li>
<li>Hint 2: [https://docs.cilium.io/en/v1.10/gettingstarted/hubble/ Check out the Hubble docs]</li></ul>
</li>
<li>Unlike last time, our cluster consists of three nodes rather than just one. Try running <code>curl 10.96.0.201</code> a few times and notice that the output now includes a node name in addition to a pod name. Do you notice any patterns in the output? Compare what you see with the output from running <code>kubectl get pods -o wide</code>. Try to come up with an explanation for the distribution of printerfacts pods over the nodes in your cluster.
<ul>
<li>Hint 1: Have a look at the <code>affinity</code> section of <code>deploy.yml</code>.</li>
<li>Hint 2: Have a look at the [https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity relevant documentation].</li>
<li>Hint 3: If you still can’t get it, an educated guess will suffice.</li></ul>
</li>
<li>Printerfacts is now a CRUD app that supports creating, reading, updating, and deleting facts from the Cassandra database. In particular, we now support the following endpoints:
<ul>
<li>GET <code>10.96.0.201/fact</code>: Get a random fact from the database as a JSON object</li>
<li>GET <code>10.96.0.201/fact/keys</code>: Get a list of all fact keys in the database as a JSON object</li>
<li>GET <code>10.96.0.201/fact/<key></code>: Get the fact with the key <key> in the database as a JSON object</li>
<li>POST <code>10.96.0.201/fact</code>: Create a new fact where the request body is a JSON object of the form <code>{ "fact": "Fact Here", "kind": "Kind of fact (e.g. Cat fact)" }</code></li>
<li>PUT <code>10.96.0.201/fact/<key></code>: Modify the fact with key <key> in the database where the request body is a JSON object of the form <code>{ "fact": "Fact Here", "kind": "Kind of fact (e.g. Cat fact)" }</code></li>
<li>DELETE <code>10.96.0.201/fact/<key></code>: Delete the fact with key <key> from the database</li></ul>

Try out each of the printerfacts endpoints. Note that you can specify the HTTP request type using <code>curl -X <type></code> (for example, <code>curl -X POST</code> to send a POST request). You can send a JSON body as a payload by using <code>curl -H 'Content-type: application/json' -d '{"key": "value"}'</code> where you replace the <code>{"key": "value"}</code> part with your JSON object.

Optional: Try restarting the Cassandra pods using <code>kubectl rollout restart statefulset cassandra</code>. While the pods are restarting, watch the output of <code>kubectl get pods --watch</code> and try making requests to the printerfacts service at the same time. Do you notice any downtime?
</li>
<li>Let’s use Cilium and Hubble to observe dataflows between our Cassandra database and the printerfacts service. To do this, run the following Hubble command: <code>hubble observe --label component=server --label component=printerfacts -f</code>. Make a few requests to the printerfacts service, exercising various API endpoints. Try and make sense of some of the network traffic you observe.</li>
<li>In an effort to secure your cluster, you decide to employ a Cilium network policy that locks down the printerfacts service. First, download the example security policy by running <code>wget https://homeostasis.scs.carleton.ca/~will/printerfacts-policy.yml</code>, then run <code>kubectl apply -f policy.yml</code> to apply it. The example policy allows GET requests to <code>/</code>, <code>/fact</code>, <code>/fact/keys</code>, and <code>/fact/<key></code>. Examine the policy file and make sure you understand how it works.
Try out your policy by making a few valid requests followed by some invalid ones. While your policy is applied, try using Hubble to observe the HTTP traffic by running <code>hubble observe --protocol http</code>. Optionally, try extending the policy to make some other valid routes work (e.g. PUT, POST, and DELETE requests).
Hint: You may wish to consult the [https://docs.cilium.io/en/v1.10/gettingstarted/http/ Cilium docs]</li>
<li>Now that you’re familiar with printerfacts, it’s time to simulate a node failure. Since both printerfacts and Cassandra are replicated across multiple nodes in our cluster, taking one of them down should not impact either service.
Let’s first try a planned node disruption. This kind of disruption might occur when a cluster administrator wants to take a node down for maintenance, for example to perform a kernel update. Start by draining node <code>minikube-m02</code> with the command <code>kubectl drain minikube-m02 --ignore-daemonsets</code>. Now try interacting with the printerfacts service as before. Make note of any unusual behaviour and try to come up with a best-guess explanation.
Now you can bring your node back up using <code>kubectl uncordon minikube-m02</code>. Once your node has been uncordoned, it should be ready for scheduling again. Try scaling up the printerfacts deployment to get some pods running on the node again.
Finally, let’s simulate a total node failure. To do this, we will kill the underlying kubelet for our node, which is running on your system as a Docker container. Use the <code>docker ps</code> command to find the container ID that corresponds to your node, then kill it using <code>docker kill</code>. Repeat the same experiments from before, documenting any unusual behaviour you observe.</li></ol>

== Part 2: Interacting with Cassandra (Hard) ==

Note that this part of the experience is only required if you wish to achieve a grade of A- or higher. You can also choose to skip one of the two questions here, but doing so will likely impact your grade.

<ol style="list-style-type: decimal;">
<li>Write a Cilium security policy that allows only SELECT and INSERT queries to the <code>pfacts.facts</code> table in Cassandra. All other queries should be denied. Apply your policy and demonstrate how it works using a few examples queries. You may wish to consult [https://docs.cilium.io/en/v1.10/gettingstarted/cassandra/#how-to-secure-a-cassandra-database the Cilium policy docs].
Hint: You can use this [https://homeostasis.scs.carleton.ca/~will/cassandra-policy.yml policy template] as a starting point.</li>
<li>Write and deploy your own containerized application as a replicated deployment to interact with the Cassandra database in some interesting way. You can choose to extend the printerfacts schema or come up with your own schema, depending on your preference. Be sure to explain how your application deals with Cassandra’s consistency model in a replicated cluster. In order to achieve points for this question, you '''must''' make some meaningful modifications to the database. Just consuming the existing data in a new way is not sufficient.
Hint 1: Cassandra allows the client to choose their consistency level when making queries. Hint 2: Cassandra queries are made in CQL, a NoSQL query language that is similar to but not totally compatible with SQL. Hint 3: You can spawn a <code>cqlsh</code> session to issue test CQL queries like <code>kubectl exec -it cassandra-0 -- cqlsh</code></li></ol>

== Part 3: Reflection ==

Summarize your experience with multi-node Kubernetes, Cilium, and Cassandra in a few paragraphs (both the good and the bad). What concepts do you see reflected here from the research papers we have read thus far? After having some hands on experience with a distributed system technology, have any of your opinions or initial assumptions changed? Feel free to list any other thoughts you have.

= Acknowledgements =

The idea for the printerfacts API comes from Christine Dodrill’s [https://christine.website/blog/dev-printerfact-2021-04-17 wonderful blog post].

DistOS 2021F Experience 2

2021-11-27T16:42:59Z

Housedhorse: Add optional part to question 3

= Introduction =

In this experience, you will be playing with a multi-node Kubernetes cluster simulated using <code>minikube</code>, running the [https://docs.cilium.io/en/v1.10/ Cilium CNI], a replicated [https://cassandra.apache.org/doc/latest/ Apache Cassandra] database and an updated version of our beloved “printerfacts” service that consumes facts stored in the Cassandra database. As usual, you may wish to consult the relevant documentation if you get stuck. Links to documentation will be provided along with hints later on in this document.

With the exception of Part 2, completing this experience shouldn’t take more than a couple of hours. Feel free to collaborate with other students if you get stuck. However, '''you must acknowledge any collaboration'''. Additionally, '''copying and pasting or simply “changing up” each other’s answers will be treated as an academic integrity violation'''.

== Submissions ==

Your experience report should be submitted as a PDF file on Brightspace, written in '''paragraph form'''. Code snippets or screenshots are allowed to augment your prose but are not required. We will post a submission link on Brightspace within the next few days.

The official due date for the experience report is December 10th (the last day of class), but we will continue to accept submissions up until the date of the final exam if you need extra time.

== Receiving Your Grade ==

This experience is broken up into three parts:

# A series of easy tasks designed to get you familiar Cilium, Cassandra, and a multi-node K8s cluster.
# A harder challenge that involves programming a client to interact with the Cassandra database and writing a custom Cilium security policy to lock down your cluster.
# An opportunity to reflect on this experience and make connections to overall themes in the course.

Students are expected to complete Part 1 and Part 3 to get a grade of at most a B+. '''Part 2 is optional''', but must be completed to receive a grade of A- or higher. Marks will be deducted for insufficient explanations or answers that demonstrate a lack of effort. By this logic, you should have a fairly clear idea of what grade you will receive when you submit this experience, based on how much effort you put in.

== Setting Up Your Environment ==

For this experience, a new VM image has been provided for you. It has a larger disk size, more RAM, and a batteries-included installation of the [https://github.com/cilium/cilium-cli Cilium] and [https://github.com/cilium/hubble Hubble] CLI. First, '''delete your old instance''' using the OpenStack web console, then create a new one. You can follow the [https://homeostasis.scs.carleton.ca/wiki/index.php/DistOS_2021F:_Using_Openstack same instructions as before], except replace the <code>COMP4000-studentvm-v1</code> image with <code>COMP4000-studentvm-v2</code>. When selecting your flavour, make sure you pick the flavour with '''16GiB of disk space and 8GB of RAM'''.

Once your VM is set up, SSH into it using your preferred SSH client. You should probably be working with at least 2 terminals for the rest of this experience. After SSHing into your instance, run the following command to spin up a multi-node k8s cluster: <code>minikube start -n3 --cni=cilium</code>. This might take a few minutes to run to completion.

Verify your cluster has started correctly using <code>minikube status</code>. You should see something like the following:

<pre>minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

minikube-m02
type: Worker
host: Running
kubelet: Running

minikube-m03
type: Worker
host: Running
kubelet: Running</pre>
=== Cilium and Hubble ===

Once your cluster is running, you can configure the cluster to use Cilium and Hubble. Due to some minikube and Cilium quirks, we need to uninstall the default version of Cilium installed by minikube and reinstall it using the Cilium CLI. You can do so with the following commands:

<pre>cilium uninstall && cilium install && cilium hubble enable</pre>
This may take a few minutes to run to completion.

You can run the command <code>cilium status</code> to check the status of your Cilium installation. Once everything has installed correctly, you should see something like the following when running <code>cilium status</code>:

<pre>student@alpine:~$ cilium status
/¯¯\
/¯¯\__/¯¯\ Cilium: OK
\__/¯¯\__/ Operator: OK
/¯¯\__/¯¯\ Hubble: OK
\__/¯¯\__/ ClusterMesh: disabled
\__/

Deployment cilium-operator Desired: 1, Ready: 1/1, Available: 1/1
Deployment hubble-relay Desired: 1, Ready: 1/1, Available: 1/1
DaemonSet cilium Desired: 3, Ready: 3/3, Available: 3/3
Containers: cilium Running: 3
cilium-operator Running: 1
hubble-relay Running: 1
Cluster Pods: 2/2 managed by Cilium
Image versions cilium quay.io/cilium/cilium:v1.10.5: 3
cilium-operator quay.io/cilium/operator-generic:v1.10.5: 1
hubble-relay quay.io/cilium/hubble-relay:v1.10.5: 1</pre>
=== Cassandra ===

We will be using the <code>helm</code> package manger to install Cassandra in our k8s cluster. To do so, run the following commands:

<pre>wget https://homeostasis.scs.carleton.ca/~will/cassandra.yml
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install cassandra bitnami/cassandra -f cassandra.yml</pre>
You can verify the status of your Cassandra installation using <code>kubectl get pods --watch</code>. Wait until both <code>cassandra-0</code> and <code>cassandra-1</code> show <code>1/1</code> under <code>READY</code>. This might take a few minutes. The output should look something like this:

<pre>student@alpine:~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 4m2s
cassandra-1 1/1 Running 0 2m8s</pre>
=== Printerfacts ===

The printerfacts service from last experience has received an upgrade to work with our new Cassandra database. First, run the migrations (provided as a batch job) to initialize the Cassandra database and populate it with some facts about printers:

<pre>wget https://homeostasis.scs.carleton.ca/~will/migrations.yml
kubectl apply -f migrations.yml</pre>
After applying the migrations, you’re ready to deploy the printerfacts service:

<pre>wget https://homeostasis.scs.carleton.ca/~will/deploy.yml
kubectl apply -f deploy.yml</pre>
Verify that printerfacts has been correctly deployed with <code>kubectl get pods</code>. You should see something like this:

<pre>student@alpine:~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 31m
cassandra-1 1/1 Running 0 30m
server-85f9f4465b-9vhn9 1/1 Running 0 38m
server-85f9f4465b-b7s2n 1/1 Running 0 38m
server-85f9f4465b-bvgqs 1/1 Running 0 38m
server-85f9f4465b-bwf42 1/1 Running 0 38m
server-85f9f4465b-gn5sm 1/1 Running 0 38m</pre>
Finally, run <code>minikube tunnel</code> in a separate terminal to set up port forwarding for our <code>LoadBalancer</code> API objects. This will enable you to interact with printerfacts from your VM, rather than needing to spin up a client pod like last time.

Verify that it worked correctly by running <code>curl 10.96.0.201</code> (this is the IP you will use to talk to printerfacts). Note that depending on your specific configuration, you may need to SSH into minikube using <code>minikube ssh</code> before you can access the load balancer service. If your curl command hangs forever, this may be the issue.

= Tasks =

== Part 1: Multi-Node Kubernetes, Cilium, and Cassandra (Easy) ==

Follow the instructions for each of the following numbered tasks. Make an effort to answer the accompanying questions, but more importantly please note down all of your observations and describe what you did for each task. You should also feel free to write down whatever questions you may have about a given task.

To achieve the best possible grade in this section, you must demonstrate that you have made an effort to understand the results of each task. (Note that an effort does not strictly mean a full understanding; it is okay to have questions!)

<ol style="list-style-type: decimal;">
<li>Thanks the Cilium CNI, your Kubernetes cluster has been outfitted with new eBPF superpowers. In particular, Cilium installs a series of eBPF programs into your (VM’s) kernel which can be used to monitor traffic between containers, pods, and nodes, as well as enforce L4–L7 security policy. To test out your new superpowers, run <code>cilium hubble port-forward&</code> followed by <code>hubble observe</code>. What is all that output? Can you make sense of any of it?
<ul>
<li>Hint 1: Try checking <code>hubble --help</code> and <code>hubble observe --help</code></li>
<li>Hint 2: [https://docs.cilium.io/en/v1.10/gettingstarted/hubble/ Check out the Hubble docs]</li></ul>
</li>
<li>Unlike last time, our cluster consists of three nodes rather than just one. Try running <code>curl 10.96.0.201</code> a few times and notice that the output now includes a node name in addition to a pod name. Do you notice any patterns in the output? Compare what you see with the output from running <code>kubectl get pods -o wide</code>. Try to come up with an explanation for the distribution of printerfacts pods over the nodes in your cluster.
<ul>
<li>Hint 1: Have a look at the <code>affinity</code> section of <code>deploy.yml</code>.</li>
<li>Hint 2: Have a look at the [https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity relevant documentation].</li>
<li>Hint 3: If you still can’t get it, an educated guess will suffice.</li></ul>
</li>
<li>Printerfacts is now a CRUD app that supports creating, reading, updating, and deleting facts from the Cassandra database. In particular, we now support the following endpoints:
<ul>
<li><code>GET</code> /fact: Get a random fact from the database as a JSON object</li>
<li><code>GET</code> /fact/keys: Get a list of all fact keys in the database as a JSON object</li>
<li><code>GET</code> /fact/<key>: Get the fact with the key <key> in the database as a JSON object</li>
<li><code>POST</code> /fact: Create a new fact where the request body is a JSON object of the form <code>{ "fact": "Fact Here", "kind": "Kind of fact (e.g. Cat fact)" }</code></li>
<li><code>PUT</code> /fact/<key>: Modify the fact with key <key> in the database where the request body is a JSON object of the form <code>{ "fact": "Fact Here", "kind": "Kind of fact (e.g. Cat fact)" }</code></li>
<li><code>DELETE</code> /fact/<key>: Delete the fact with key <key> from the database</li></ul>

Try out each of the printerfacts endpoints. Note that you can specify the HTTP request type using <code>curl -X <type></code> (for example, <code>curl -X POST</code> to send a POST request). You can send a JSON body as a payload by using <code>curl -H 'Content-type: application/json' -d '{"key": "value"}'</code> where you replace the <code>{"key": "value"}</code> part with your JSON object.

Optional: Try restarting the Cassandra pods using <code>kubectl rollout restart statefulset cassandra</code>. While the pods are restarting, watch the output of <code>kubectl get pods --watch</code> and try making requests to the printerfacts service at the same time. Do you notice any downtime?
</li>
<li>Let’s use Cilium and Hubble to observe dataflows between our Cassandra database and the printerfacts service. To do this, run the following Hubble command: <code>hubble observe --label component=server --label component=printerfacts -f</code>. Make a few requests to the printerfacts service, exercising various API endpoints. Try and make sense of some of the network traffic you observe.</li>
<li>In an effort to secure your cluster, you decide to employ a Cilium network policy that locks down the printerfacts service. First, download the example security policy by running <code>wget https://homeostasis.scs.carleton.ca/~will/printerfacts-policy.yml</code>, then run <code>kubectl apply -f policy.yml</code> to apply it. The example policy allows GET requests to <code>/</code>, <code>/fact</code>, <code>/fact/keys</code>, and <code>/fact/<key></code>. Examine the policy file and make sure you understand how it works.
Try out your policy by making a few valid requests followed by some invalid ones. While your policy is applied, try using Hubble to observe the HTTP traffic by running <code>hubble observe --protocol http</code>. Optionally, try extending the policy to make some other valid routes work (e.g. PUT, POST, and DELETE requests).
Hint: You may wish to consult the [https://docs.cilium.io/en/v1.10/gettingstarted/http/ Cilium docs]</li>
<li>Now that you’re familiar with printerfacts, it’s time to simulate a node failure. Since both printerfacts and Cassandra are replicated across multiple nodes in our cluster, taking one of them down should not impact either service.
Let’s first try a planned node disruption. This kind of disruption might occur when a cluster administrator wants to take a node down for maintenance, for example to perform a kernel update. Start by draining node <code>minikube-m02</code> with the command <code>kubectl drain minikube-m02 --ignore-daemonsets</code>. Now try interacting with the printerfacts service as before. Make note of any unusual behaviour and try to come up with a best-guess explanation.
Now you can bring your node back up using <code>kubectl uncordon minikube-m02</code>. Once your node has been uncordoned, it should be ready for scheduling again. Try scaling up the printerfacts deployment to get some pods running on the node again.
Finally, let’s simulate a total node failure. To do this, we will kill the underlying kubelet for our node, which is running on your system as a Docker container. Use the <code>docker ps</code> command to find the container ID that corresponds to your node, then kill it using <code>docker kill</code>. Repeat the same experiments from before, documenting any unusual behaviour you observe.</li></ol>

== Part 2: Interacting with Cassandra (Hard) ==

Note that this part of the experience is only required if you wish to achieve a grade of A- or higher. You can also choose to skip one of the two questions here, but doing so will likely impact your grade.

<ol style="list-style-type: decimal;">
<li>Write a Cilium security policy that allows only SELECT and INSERT queries to the <code>pfacts.facts</code> table in Cassandra. All other queries should be denied. Apply your policy and demonstrate how it works using a few examples queries. You may wish to consult [https://docs.cilium.io/en/v1.10/gettingstarted/cassandra/#how-to-secure-a-cassandra-database the Cilium policy docs].
Hint: You can use this [https://homeostasis.scs.carleton.ca/~will/cassandra-policy.yml policy template] as a starting point.</li>
<li>Write and deploy your own containerized application as a replicated deployment to interact with the Cassandra database in some interesting way. You can choose to extend the printerfacts schema or come up with your own schema, depending on your preference. Be sure to explain how your application deals with Cassandra’s consistency model in a replicated cluster. In order to achieve points for this question, you '''must''' make some meaningful modifications to the database. Just consuming the existing data in a new way is not sufficient.
Hint 1: Cassandra allows the client to choose their consistency level when making queries. Hint 2: Cassandra queries are made in CQL, a NoSQL query language that is similar to but not totally compatible with SQL. Hint 3: You can spawn a <code>cqlsh</code> session to issue test CQL queries like <code>kubectl exec -it cassandra-0 -- cqlsh</code></li></ol>

== Part 3: Reflection ==

Summarize your experience with multi-node Kubernetes, Cilium, and Cassandra in a few paragraphs (both the good and the bad). What concepts do you see reflected here from the research papers we have read thus far? After having some hands on experience with a distributed system technology, have any of your opinions or initial assumptions changed? Feel free to list any other thoughts you have.

= Acknowledgements =

The idea for the printerfacts API comes from Christine Dodrill’s [https://christine.website/blog/dev-printerfact-2021-04-17 wonderful blog post].

DistOS 2021F Experience 2

2021-11-27T01:14:54Z

Housedhorse: /* Part 1: Multi-Node Kubernetes, Cilium, and Cassandra (Easy) */

= Introduction =

In this experience, you will be playing with a multi-node Kubernetes cluster simulated using <code>minikube</code>, running the [https://docs.cilium.io/en/v1.10/ Cilium CNI], a replicated [https://cassandra.apache.org/doc/latest/ Apache Cassandra] database and an updated version of our beloved “printerfacts” service that consumes facts stored in the Cassandra database. As usual, you may wish to consult the relevant documentation if you get stuck. Links to documentation will be provided along with hints later on in this document.

With the exception of Part 2, completing this experience shouldn’t take more than a couple of hours. Feel free to collaborate with other students if you get stuck. However, '''you must acknowledge any collaboration'''. Additionally, '''copying and pasting or simply “changing up” each other’s answers will be treated as an academic integrity violation'''.

== Submissions ==

Your experience report should be submitted as a PDF file on Brightspace, written in '''paragraph form'''. Code snippets or screenshots are allowed to augment your prose but are not required. We will post a submission link on Brightspace within the next few days.

The official due date for the experience report is December 10th (the last day of class), but we will continue to accept submissions up until the date of the final exam if you need extra time.

== Receiving Your Grade ==

This experience is broken up into three parts:

# A series of easy tasks designed to get you familiar Cilium, Cassandra, and a multi-node K8s cluster.
# A harder challenge that involves programming a client to interact with the Cassandra database and writing a custom Cilium security policy to lock down your cluster.
# An opportunity to reflect on this experience and make connections to overall themes in the course.

Students are expected to complete Part 1 and Part 3 to get a grade of at most a B+. '''Part 2 is optional''', but must be completed to receive a grade of A- or higher. Marks will be deducted for insufficient explanations or answers that demonstrate a lack of effort. By this logic, you should have a fairly clear idea of what grade you will receive when you submit this experience, based on how much effort you put in.

== Setting Up Your Environment ==

For this experience, a new VM image has been provided for you. It has a larger disk size, more RAM, and a batteries-included installation of the [https://github.com/cilium/cilium-cli Cilium] and [https://github.com/cilium/hubble Hubble] CLI. First, '''delete your old instance''' using the OpenStack web console, then create a new one. You can follow the [https://homeostasis.scs.carleton.ca/wiki/index.php/DistOS_2021F:_Using_Openstack same instructions as before], except replace the <code>COMP4000-studentvm-v1</code> image with <code>COMP4000-studentvm-v2</code>. When selecting your flavour, make sure you pick the flavour with '''16GiB of disk space and 8GB of RAM'''.

Once your VM is set up, SSH into it using your preferred SSH client. You should probably be working with at least 2 terminals for the rest of this experience. After SSHing into your instance, run the following command to spin up a multi-node k8s cluster: <code>minikube start -n3 --cni=cilium</code>. This might take a few minutes to run to completion.

Verify your cluster has started correctly using <code>minikube status</code>. You should see something like the following:

<pre>minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

minikube-m02
type: Worker
host: Running
kubelet: Running

minikube-m03
type: Worker
host: Running
kubelet: Running</pre>
=== Cilium and Hubble ===

Once your cluster is running, you can configure the cluster to use Cilium and Hubble. Due to some minikube and Cilium quirks, we need to uninstall the default version of Cilium installed by minikube and reinstall it using the Cilium CLI. You can do so with the following commands:

<pre>cilium uninstall && cilium install && cilium hubble enable</pre>
This may take a few minutes to run to completion.

You can run the command <code>cilium status</code> to check the status of your Cilium installation. Once everything has installed correctly, you should see something like the following when running <code>cilium status</code>:

<pre>student@alpine:~$ cilium status
/¯¯\
/¯¯\__/¯¯\ Cilium: OK
\__/¯¯\__/ Operator: OK
/¯¯\__/¯¯\ Hubble: OK
\__/¯¯\__/ ClusterMesh: disabled
\__/

Deployment cilium-operator Desired: 1, Ready: 1/1, Available: 1/1
Deployment hubble-relay Desired: 1, Ready: 1/1, Available: 1/1
DaemonSet cilium Desired: 3, Ready: 3/3, Available: 3/3
Containers: cilium Running: 3
cilium-operator Running: 1
hubble-relay Running: 1
Cluster Pods: 2/2 managed by Cilium
Image versions cilium quay.io/cilium/cilium:v1.10.5: 3
cilium-operator quay.io/cilium/operator-generic:v1.10.5: 1
hubble-relay quay.io/cilium/hubble-relay:v1.10.5: 1</pre>
=== Cassandra ===

We will be using the <code>helm</code> package manger to install Cassandra in our k8s cluster. To do so, run the following commands:

<pre>wget https://homeostasis.scs.carleton.ca/~will/cassandra.yml
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install cassandra bitnami/cassandra -f cassandra.yml</pre>
You can verify the status of your Cassandra installation using <code>kubectl get pods --watch</code>. Wait until both <code>cassandra-0</code> and <code>cassandra-1</code> show <code>1/1</code> under <code>READY</code>. This might take a few minutes. The output should look something like this:

<pre>student@alpine:~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 4m2s
cassandra-1 1/1 Running 0 2m8s</pre>
=== Printerfacts ===

The printerfacts service from last experience has received an upgrade to work with our new Cassandra database. First, run the migrations (provided as a batch job) to initialize the Cassandra database and populate it with some facts about printers:

<pre>wget https://homeostasis.scs.carleton.ca/~will/migrations.yml
kubectl apply -f migrations.yml</pre>
After applying the migrations, you’re ready to deploy the printerfacts service:

<pre>wget https://homeostasis.scs.carleton.ca/~will/deploy.yml
kubectl apply -f deploy.yml</pre>
Verify that printerfacts has been correctly deployed with <code>kubectl get pods</code>. You should see something like this:

<pre>student@alpine:~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 31m
cassandra-1 1/1 Running 0 30m
server-85f9f4465b-9vhn9 1/1 Running 0 38m
server-85f9f4465b-b7s2n 1/1 Running 0 38m
server-85f9f4465b-bvgqs 1/1 Running 0 38m
server-85f9f4465b-bwf42 1/1 Running 0 38m
server-85f9f4465b-gn5sm 1/1 Running 0 38m</pre>
Finally, run <code>minikube tunnel</code> in a separate terminal to set up port forwarding for our <code>LoadBalancer</code> API objects. This will enable you to interact with printerfacts from your VM, rather than needing to spin up a client pod like last time.

Verify that it worked correctly by running <code>curl 10.96.0.201</code> (this is the IP you will use to talk to printerfacts). Note that depending on your specific configuration, you may need to SSH into minikube using <code>minikube ssh</code> before you can access the load balancer service. If your curl command hangs forever, this may be the issue.

= Tasks =

== Part 1: Multi-Node Kubernetes, Cilium, and Cassandra (Easy) ==

Follow the instructions for each of the following numbered tasks. Make an effort to answer the accompanying questions, but more importantly please note down all of your observations and describe what you did for each task. You should also feel free to write down whatever questions you may have about a given task.

To achieve the best possible grade in this section, you must demonstrate that you have made an effort to understand the results of each task. (Note that an effort does not strictly mean a full understanding; it is okay to have questions!)

<ol style="list-style-type: decimal;">
<li>Thanks the Cilium CNI, your Kubernetes cluster has been outfitted with new eBPF superpowers. In particular, Cilium installs a series of eBPF programs into your (VM’s) kernel which can be used to monitor traffic between containers, pods, and nodes, as well as enforce L4–L7 security policy. To test out your new superpowers, run <code>cilium hubble port-forward&</code> followed by <code>hubble observe</code>. What is all that output? Can you make sense of any of it?
<ul>
<li>Hint 1: Try checking <code>hubble --help</code> and <code>hubble observe --help</code></li>
<li>Hint 2: [https://docs.cilium.io/en/v1.10/gettingstarted/hubble/ Check out the Hubble docs]</li></ul>
</li>
<li>Unlike last time, our cluster consists of three nodes rather than just one. Try running <code>curl 10.96.0.201</code> a few times and notice that the output now includes a node name in addition to a pod name. Do you notice any patterns in the output? Compare what you see with the output from running <code>kubectl get pods -o wide</code>. Try to come up with an explanation for the distribution of printerfacts pods over the nodes in your cluster.
<ul>
<li>Hint 1: Have a look at the <code>affinity</code> section of <code>deploy.yml</code>.</li>
<li>Hint 2: Have a look at the [https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity relevant documentation].</li>
<li>Hint 3: If you still can’t get it, an educated guess will suffice.</li></ul>
</li>
<li>Printerfacts is now a CRUD app that supports creating, reading, updating, and deleting facts from the Cassandra database. In particular, we now support the following endpoints:
<ul>
<li><code>GET</code> /fact: Get a random fact from the database as a JSON object</li>
<li><code>GET</code> /fact/keys: Get a list of all fact keys in the database as a JSON object</li>
<li><code>GET</code> /fact/<key>: Get the fact with the key <key> in the database as a JSON object</li>
<li><code>POST</code> /fact: Create a new fact where the request body is a JSON object of the form <code>{ "fact": "Fact Here", "kind": "Kind of fact (e.g. Cat fact)" }</code></li>
<li><code>PUT</code> /fact/<key>: Modify the fact with key <key> in the database where the request body is a JSON object of the form <code>{ "fact": "Fact Here", "kind": "Kind of fact (e.g. Cat fact)" }</code></li>
<li><code>DELETE</code> /fact/<key>: Delete the fact with key <key> from the database</li></ul>

Try out each of the printerfacts endpoints. Note that you can specify the HTTP request type using <code>curl -X <type></code> (for example, <code>curl -X POST</code> to send a POST request). You can send a JSON body as a payload by using <code>curl -H 'Content-type: application/json' -d '{"key": "value"}'</code> where you replace the <code>{"key": "value"}</code> part with your JSON object.</li>
<li>Let’s use Cilium and Hubble to observe dataflows between our Cassandra database and the printerfacts service. To do this, run the following Hubble command: <code>hubble observe --label component=server --label component=printerfacts -f</code>. Make a few requests to the printerfacts service, exercising various API endpoints. Try and make sense of some of the network traffic you observe.</li>
<li>In an effort to secure your cluster, you decide to employ a Cilium network policy that locks down the printerfacts service. First, download the example security policy by running <code>wget https://homeostasis.scs.carleton.ca/~will/printerfacts-policy.yml</code>, then run <code>kubectl apply -f policy.yml</code> to apply it. The example policy allows GET requests to <code>/</code>, <code>/fact</code>, <code>/fact/keys</code>, and <code>/fact/<key></code>. Examine the policy file and make sure you understand how it works.
Try out your policy by making a few valid requests followed by some invalid ones. While your policy is applied, try using Hubble to observe the HTTP traffic by running <code>hubble observe --protocol http</code>. Optionally, try extending the policy to make some other valid routes work (e.g. PUT, POST, and DELETE requests).
Hint: You may wish to consult the [https://docs.cilium.io/en/v1.10/gettingstarted/http/ Cilium docs]</li>
<li>Now that you’re familiar with printerfacts, it’s time to simulate a node failure. Since both printerfacts and Cassandra are replicated across multiple nodes in our cluster, taking one of them down should not impact either service.
Let’s first try a planned node disruption. This kind of disruption might occur when a cluster administrator wants to take a node down for maintenance, for example to perform a kernel update. Start by draining node <code>minikube-m02</code> with the command <code>kubectl drain minikube-m02 --ignore-daemonsets</code>. Now try interacting with the printerfacts service as before. Make note of any unusual behaviour and try to come up with a best-guess explanation.
Now you can bring your node back up using <code>kubectl uncordon minikube-m02</code>. Once your node has been uncordoned, it should be ready for scheduling again. Try scaling up the printerfacts deployment to get some pods running on the node again.
Finally, let’s simulate a total node failure. To do this, we will kill the underlying kubelet for our node, which is running on your system as a Docker container. Use the <code>docker ps</code> command to find the container ID that corresponds to your node, then kill it using <code>docker kill</code>. Repeat the same experiments from before, documenting any unusual behaviour you observe.</li></ol>

== Part 2: Interacting with Cassandra (Hard) ==

Note that this part of the experience is only required if you wish to achieve a grade of A- or higher. You can also choose to skip one of the two questions here, but doing so will likely impact your grade.

<ol style="list-style-type: decimal;">
<li>Write a Cilium security policy that allows only SELECT and INSERT queries to the <code>pfacts.facts</code> table in Cassandra. All other queries should be denied. Apply your policy and demonstrate how it works using a few examples queries. You may wish to consult [https://docs.cilium.io/en/v1.10/gettingstarted/cassandra/#how-to-secure-a-cassandra-database the Cilium policy docs].
Hint: You can use this [https://homeostasis.scs.carleton.ca/~will/cassandra-policy.yml policy template] as a starting point.</li>
<li>Write and deploy your own containerized application as a replicated deployment to interact with the Cassandra database in some interesting way. You can choose to extend the printerfacts schema or come up with your own schema, depending on your preference. Be sure to explain how your application deals with Cassandra’s consistency model in a replicated cluster. In order to achieve points for this question, you '''must''' make some meaningful modifications to the database. Just consuming the existing data in a new way is not sufficient.
Hint 1: Cassandra allows the client to choose their consistency level when making queries. Hint 2: Cassandra queries are made in CQL, a NoSQL query language that is similar to but not totally compatible with SQL. Hint 3: You can spawn a <code>cqlsh</code> session to issue test CQL queries like <code>kubectl exec -it cassandra-0 -- cqlsh</code></li></ol>

== Part 3: Reflection ==

Summarize your experience with multi-node Kubernetes, Cilium, and Cassandra in a few paragraphs (both the good and the bad). What concepts do you see reflected here from the research papers we have read thus far? After having some hands on experience with a distributed system technology, have any of your opinions or initial assumptions changed? Feel free to list any other thoughts you have.

= Acknowledgements =

The idea for the printerfacts API comes from Christine Dodrill’s [https://christine.website/blog/dev-printerfact-2021-04-17 wonderful blog post].

DistOS 2021F Experience 2

2021-11-27T01:08:30Z

Housedhorse: Touch experience 2

= Introduction =

In this experience, you will be playing with a multi-node Kubernetes cluster simulated using <code>minikube</code>, running the [https://docs.cilium.io/en/v1.10/ Cilium CNI], a replicated [https://cassandra.apache.org/doc/latest/ Apache Cassandra] database and an updated version of our beloved “printerfacts” service that consumes facts stored in the Cassandra database. As usual, you may wish to consult the relevant documentation if you get stuck. Links to documentation will be provided along with hints later on in this document.

With the exception of Part 2, completing this experience shouldn’t take more than a couple of hours. Feel free to collaborate with other students if you get stuck. However, '''you must acknowledge any collaboration'''. Additionally, '''copying and pasting or simply “changing up” each other’s answers will be treated as an academic integrity violation'''.

== Submissions ==

Your experience report should be submitted as a PDF file on Brightspace, written in '''paragraph form'''. Code snippets or screenshots are allowed to augment your prose but are not required. We will post a submission link on Brightspace within the next few days.

The official due date for the experience report is December 10th (the last day of class), but we will continue to accept submissions up until the date of the final exam if you need extra time.

== Receiving Your Grade ==

This experience is broken up into three parts:

# A series of easy tasks designed to get you familiar Cilium, Cassandra, and a multi-node K8s cluster.
# A harder challenge that involves programming a client to interact with the Cassandra database and writing a custom Cilium security policy to lock down your cluster.
# An opportunity to reflect on this experience and make connections to overall themes in the course.

Students are expected to complete Part 1 and Part 3 to get a grade of at most a B+. '''Part 2 is optional''', but must be completed to receive a grade of A- or higher. Marks will be deducted for insufficient explanations or answers that demonstrate a lack of effort. By this logic, you should have a fairly clear idea of what grade you will receive when you submit this experience, based on how much effort you put in.

== Setting Up Your Environment ==

For this experience, a new VM image has been provided for you. It has a larger disk size, more RAM, and a batteries-included installation of the [https://github.com/cilium/cilium-cli Cilium] and [https://github.com/cilium/hubble Hubble] CLI. First, '''delete your old instance''' using the OpenStack web console, then create a new one. You can follow the [https://homeostasis.scs.carleton.ca/wiki/index.php/DistOS_2021F:_Using_Openstack same instructions as before], except replace the <code>COMP4000-studentvm-v1</code> image with <code>COMP4000-studentvm-v2</code>. When selecting your flavour, make sure you pick the flavour with '''16GiB of disk space and 8GB of RAM'''.

Once your VM is set up, SSH into it using your preferred SSH client. You should probably be working with at least 2 terminals for the rest of this experience. After SSHing into your instance, run the following command to spin up a multi-node k8s cluster: <code>minikube start -n3 --cni=cilium</code>. This might take a few minutes to run to completion.

Verify your cluster has started correctly using <code>minikube status</code>. You should see something like the following:

<pre>minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

minikube-m02
type: Worker
host: Running
kubelet: Running

minikube-m03
type: Worker
host: Running
kubelet: Running</pre>
=== Cilium and Hubble ===

Once your cluster is running, you can configure the cluster to use Cilium and Hubble. Due to some minikube and Cilium quirks, we need to uninstall the default version of Cilium installed by minikube and reinstall it using the Cilium CLI. You can do so with the following commands:

<pre>cilium uninstall && cilium install && cilium hubble enable</pre>
This may take a few minutes to run to completion.

You can run the command <code>cilium status</code> to check the status of your Cilium installation. Once everything has installed correctly, you should see something like the following when running <code>cilium status</code>:

<pre>student@alpine:~$ cilium status
/¯¯\
/¯¯\__/¯¯\ Cilium: OK
\__/¯¯\__/ Operator: OK
/¯¯\__/¯¯\ Hubble: OK
\__/¯¯\__/ ClusterMesh: disabled
\__/

Deployment cilium-operator Desired: 1, Ready: 1/1, Available: 1/1
Deployment hubble-relay Desired: 1, Ready: 1/1, Available: 1/1
DaemonSet cilium Desired: 3, Ready: 3/3, Available: 3/3
Containers: cilium Running: 3
cilium-operator Running: 1
hubble-relay Running: 1
Cluster Pods: 2/2 managed by Cilium
Image versions cilium quay.io/cilium/cilium:v1.10.5: 3
cilium-operator quay.io/cilium/operator-generic:v1.10.5: 1
hubble-relay quay.io/cilium/hubble-relay:v1.10.5: 1</pre>
=== Cassandra ===

We will be using the <code>helm</code> package manger to install Cassandra in our k8s cluster. To do so, run the following commands:

<pre>wget https://homeostasis.scs.carleton.ca/~will/cassandra.yml
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install cassandra bitnami/cassandra -f cassandra.yml</pre>
You can verify the status of your Cassandra installation using <code>kubectl get pods --watch</code>. Wait until both <code>cassandra-0</code> and <code>cassandra-1</code> show <code>1/1</code> under <code>READY</code>. This might take a few minutes. The output should look something like this:

<pre>student@alpine:~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 4m2s
cassandra-1 1/1 Running 0 2m8s</pre>
=== Printerfacts ===

The printerfacts service from last experience has received an upgrade to work with our new Cassandra database. First, run the migrations (provided as a batch job) to initialize the Cassandra database and populate it with some facts about printers:

<pre>wget https://homeostasis.scs.carleton.ca/~will/migrations.yml
kubectl apply -f migrations.yml</pre>
After applying the migrations, you’re ready to deploy the printerfacts service:

<pre>wget https://homeostasis.scs.carleton.ca/~will/deploy.yml
kubectl apply -f deploy.yml</pre>
Verify that printerfacts has been correctly deployed with <code>kubectl get pods</code>. You should see something like this:

<pre>student@alpine:~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 31m
cassandra-1 1/1 Running 0 30m
server-85f9f4465b-9vhn9 1/1 Running 0 38m
server-85f9f4465b-b7s2n 1/1 Running 0 38m
server-85f9f4465b-bvgqs 1/1 Running 0 38m
server-85f9f4465b-bwf42 1/1 Running 0 38m
server-85f9f4465b-gn5sm 1/1 Running 0 38m</pre>
Finally, run <code>minikube tunnel</code> in a separate terminal to set up port forwarding for our <code>LoadBalancer</code> API objects. This will enable you to interact with printerfacts from your VM, rather than needing to spin up a client pod like last time.

Verify that it worked correctly by running <code>curl 10.96.0.201</code> (this is the IP you will use to talk to printerfacts). Note that depending on your specific configuration, you may need to SSH into minikube using <code>minikube ssh</code> before you can access the load balancer service. If your curl command hangs forever, this may be the issue.

= Tasks =

== Part 1: Multi-Node Kubernetes, Cilium, and Cassandra (Easy) ==

Follow the instructions for each of the following numbered tasks. Make an effort to answer the accompanying questions, but more importantly please note down all of your observations and describe what you did for each task. You should also feel free to write down whatever questions you may have about a given task.

To achieve the best possible grade in this section, you must demonstrate that you have made an effort to understand the results of each task. (Note that an effort does not strictly mean a full understanding; it is okay to have questions!)

<ol style="list-style-type: decimal;">
<li>Thanks the Cilium CNI, your Kubernetes clusters has been outfitted with new eBPF superpowers. In particular, Cilium installs a series of eBPF programs into your (VM’s) kernel which can be used to monitor traffic between containers, pods, and nodes, as well as enforce L4–L7 security policy. To test out your new superpowers, run <code>cilium hubble port-forward&</code> followed by <code>hubble observe</code>. What is all that output? Can you make sense of any of it?
<ul>
<li>Hint 1: Try checking <code>hubble --help</code> and <code>hubble observe --help</code></li>
<li>Hint 2: [https://docs.cilium.io/en/v1.10/gettingstarted/hubble/ Check out the Hubble docs]</li></ul>
</li>
<li>Unlike last time, our cluster consists of three nodes rather than just one. Try running <code>curl 10.96.0.201</code> a few times and notice that the output now includes a node name in addition to a pod name. Do you notice any patterns in the output? Compare what you see with the output from running <code>kubectl get pods -o wide</code>. Try to come up with an explanation for the distribution of printerfacts pods over the nodes in your cluster.
<ul>
<li>Hint 1: Have a look at the <code>affinity</code> section of <code>deploy.yml</code>.</li>
<li>Hint 2: Have a look at the [https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity relevant documentation].</li>
<li>Hint 3: If you still can’t get it, an educated guess will suffice.</li></ul>
</li>
<li>Printerfacts is now a CRUD app that supports creating, reading, updating, and deleting facts from the Cassandra database. In particular, we now support the following endpoints:
<ul>
<li><code>GET</code> /fact: Get a random fact from the database as a JSON object</li>
<li><code>GET</code> /fact/keys: Get a list of all fact keys in the database as a JSON object</li>
<li><code>GET</code> /fact/<key>: Get the fact with the key <key> in the database as a JSON object</li>
<li><code>POST</code> /fact: Create a new fact where the request body is a JSON object of the form <code>{ "fact": "Fact Here", "kind": "Kind of fact (e.g. Cat fact)" }</code></li>
<li><code>PUT</code> /fact/<key>: Modify the fact with key <key> in the database where the request body is a JSON object of the form <code>{ "fact": "Fact Here", "kind": "Kind of fact (e.g. Cat fact)" }</code></li>
<li><code>DELETE</code> /fact/<key>: Delete the fact with key <key> from the database</li></ul>

Try out each of the printerfacts endpoints. Note that you can specify the HTTP request type using <code>curl -X <type></code> (for example, <code>curl -X POST</code> to send a POST request). You can send a JSON body as a payload by using <code>curl -H 'Content-type: application/json' -d '{"key": "value"}'</code> where you replace the <code>{"key": "value"}</code> part with your JSON object.</li>
<li>Let’s use Cilium and Hubble to observe dataflows between our Cassandra database and the printerfacts service. To do this, run the following Hubble command: <code>hubble observe --label component=server --label component=printerfacts -f</code>. Make a few requests to the printerfacts service, exercising various API endpoints. Try and make sense of some of the network traffic you observe.</li>
<li>In an effort to secure your cluster, you decide to employ a Cilium network policy that locks down the printerfacts service. First, download the example security policy by running <code>wget https://homeostasis.scs.carleton.ca/~will/printerfacts-policy.yml</code>, then run <code>kubectl apply -f policy.yml</code> to apply it. The example policy allows GET requests to <code>/</code>, <code>/fact</code>, <code>/fact/keys</code>, and <code>/fact/<key></code>. Examine the policy file and make sure you understand how it works.
Try out your policy by making a few valid requests followed by some invalid ones. While your policy is applied, try using Hubble to observe the HTTP traffic by running <code>hubble observe --protocol http</code>. Optionally, try extending the policy to make some other valid routes work (e.g. PUT, POST, and DELETE requests).
Hint: You may wish to consult the [https://docs.cilium.io/en/v1.10/gettingstarted/http/ Cilium docs]</li>
<li>Now that you’re familiar with printerfacts, it’s time to simulate a node failure. Since both printerfacts and Cassandra are replicated across multiple nodes in our cluster, taking one of them down should not impact either service.
Let’s first try a planned node disruption. This kind of disruption might occur when a cluster administrator wants to take a node down for maintenance, for example to perform a kernel update. Start by draining node <code>minikube-m02</code> with the command <code>kubectl drain minikube-m02 --ignore-daemonsets</code>. Now try interacting with the printerfacts service as before. Make note of any unusual behaviour and try to come up with a best-guess explanation.
Now you can bring your node back up using <code>kubectl uncordon minikube-m02</code>. Once your node has been uncordoned, it should be ready for scheduling again. Try scaling up the printerfacts deployment to get some pods running on the node again.
Finally, let’s simulate a total node failure. To do this, we will kill the underlying kubelet for our node, which is running on your system as a Docker container. Use the <code>docker ps</code> command to find the container ID that corresponds to your node, then kill it using <code>docker kill</code>. Repeat the same experiments from before, documenting any unusual behaviour you observe.</li></ol>

== Part 2: Interacting with Cassandra (Hard) ==

Note that this part of the experience is only required if you wish to achieve a grade of A- or higher. You can also choose to skip one of the two questions here, but doing so will likely impact your grade.

<ol style="list-style-type: decimal;">
<li>Write a Cilium security policy that allows only SELECT and INSERT queries to the <code>pfacts.facts</code> table in Cassandra. All other queries should be denied. Apply your policy and demonstrate how it works using a few examples queries. You may wish to consult [https://docs.cilium.io/en/v1.10/gettingstarted/cassandra/#how-to-secure-a-cassandra-database the Cilium policy docs].
Hint: You can use this [https://homeostasis.scs.carleton.ca/~will/cassandra-policy.yml policy template] as a starting point.</li>
<li>Write and deploy your own containerized application as a replicated deployment to interact with the Cassandra database in some interesting way. You can choose to extend the printerfacts schema or come up with your own schema, depending on your preference. Be sure to explain how your application deals with Cassandra’s consistency model in a replicated cluster. In order to achieve points for this question, you '''must''' make some meaningful modifications to the database. Just consuming the existing data in a new way is not sufficient.
Hint 1: Cassandra allows the client to choose their consistency level when making queries. Hint 2: Cassandra queries are made in CQL, a NoSQL query language that is similar to but not totally compatible with SQL. Hint 3: You can spawn a <code>cqlsh</code> session to issue test CQL queries like <code>kubectl exec -it cassandra-0 -- cqlsh</code></li></ol>

== Part 3: Reflection ==

Summarize your experience with multi-node Kubernetes, Cilium, and Cassandra in a few paragraphs (both the good and the bad). What concepts do you see reflected here from the research papers we have read thus far? After having some hands on experience with a distributed system technology, have any of your opinions or initial assumptions changed? Feel free to list any other thoughts you have.

= Acknowledgements =

The idea for the printerfacts API comes from Christine Dodrill’s [https://christine.website/blog/dev-printerfact-2021-04-17 wonderful blog post].

Distributed OS: Fall 2021

2021-11-26T23:18:43Z

Housedhorse: Update ex2 due date

==Course Outline==

[[Distributed OS: Fall 2021 Course Outline|Here]] is the course outline.

==Experiences==

* [[DistOS 2021F Experience 1|Experience 1]], due November 2, 2021
* [[DistOS 2021F Experience 2|Experience 2]], due December 10, 2021

===Using Openstack===

The experiences (and potentially your project) will involve using the SCS Openstack cluster:
* [[DistOS 2021F: Using Openstack|How to use Openstack (for COMP 4000/5102)]]
* [https://openstack.scs.carleton.ca SCS Openstack web console] (only available from the Carleton network)

==Classes==

More information will be posted here by the first class.

'''Note:''' If you don't have access to the course information on brightspace, please email Prof. Somayaji, you may need to be manually added. (If you're at UofO or you recently added COMP 5102, you probably need to be added manually.) On Brightspace the course should show up as COMP 4000 no matter whether you enrolled in it or COMP 5102.

==Project Help==

To develop a literature review or research proposal, start with a single research paper that you find interesting and that is related to distributed operating systems in some way.

To begin selecting a paper, I suggest that you:
* search on Google Scholar using keywords relating to your interests, and/or
* browse the proceedings of major conferences that publish work related to distributed operating systems.

The main operating system conferences are [https://www.usenix.org/conferences/byname/179 OSDI] and ACM SOSP ([http://sosp.org/ sosp.org],[http://dl.acm.org/event.cfm?id=RE208&CFID=475138068&CFTOKEN=43996267 ACM DL]). Note that not all the work here is on distributed operating systems! Also, many other conferences publish some work related to distributed operating systems, e.g. [https://www.usenix.org/conferences/byname/178 NSDI].

To help you write a literature review or the background of a research paper, read the following:
* Harvey, "What Is a Literature Review?" [http://www.cs.cmu.edu/~missy/WritingaLiteratureReview.doc (DOC)] [http://www.cs.cmu.edu/~missy/Writing_a_Literature_Review.ppt (PPT)]
* [http://www.writing.utoronto.ca/advice/specific-types-of-writing/literature-review Taylor, "The Literature Review: A Few Tips On Conducting It"]

Implementation experiences will depend upon your technical background and personal interests. If you have an idea, please discuss with Anil or William as soon as you can.

==Readings & Classes==

===[[DistOS 2021F 2021-09-09|September 9, 2021]]===

Introduction

===[[DistOS 2021F 2021-09-14|September 14, 2021]]===
UNIX
* [https://www.youtube.com/watch?v=tc4ROCJYbm0 The UNIX System: Making Computers More Productive (1982)], video
* [http://homeostasis.scs.carleton.ca/~soma/distos/fall2008/unix.pdf Dennis M. Ritchie and Ken Thompson, "The UNIX Time-Sharing System" (1974)]
Note that the video covers the main points of the paper.

===[[DistOS 2021F 2021-09-16|September 16, 2021]]===
LOCUS
* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-21/walker-locus.pdf Bruce Walker et al., "The LOCUS Distributed Operating System." (1983)]

===[[DistOS 2021F 2021-09-21|September 21, 2021]]===
NFS
* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/sandberg-nfs.pdf Russel Sandberg et al., "Design and Implementation of the Sun Network Filesystem" (1985)]

===[[DistOS 2021F 2021-09-23|September 23, 2021]]===
Distributed Shared Memory
* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/protic-overview.pdf Jelica Protic et al., "Distributed Shared Memory: Concepts and Systems" (1996)]

===[[DistOS 2021F 2021-09-28|September 28, 2021]]===
Plan 9
* [https://homeostasis.scs.carleton.ca/~soma/distos/2014w/presotto-plan9.pdf Presotto et. al, Plan 9, A Distributed System (1991)]
* [https://homeostasis.scs.carleton.ca/~soma/distos/2014w/pike-plan9.pdf Pike et al., Plan 9 from Bell Labs (1995)]

===[[DistOS 2021F 2021-09-30|September 30, 2021]]===
Solaris Zones
* [https://www.usenix.org/legacy/publications/library/proceedings/lisa04/tech/full_papers/price/price.pdf Price & Tucker, "Solaris Zones: Operating System Support for Consolidating Commercial Workloads" (LISA 2004)]
* [https://www.usenix.org/system/files/login/articles/963-galvin.pdf Galvin, "Solaris 10 Containers" (;LOGIN 2005)]

===[[DistOS 2021F 2021-10-05|October 5, 2021]]===

NASD & GFS
* [https://homeostasis.scs.carleton.ca/~soma/distos/2008-03-10/gibson-nasd.pdf Garth A. Gibson et al., "A Cost-Effective, High-Bandwidth Storage Architecture" (1998)]
* [https://research.google.com/archive/gfs-sosp2003.pdf Sanjay Ghemawat et al., "The Google File System" (SOSP 2003)]

===[[DistOS 2021F 2021-10-07|October 7, 2021]]===

Chubby & ZooKeeper
* [https://www.usenix.org/legacy/events/osdi06/tech/burrows.html Burrows, The Chubby Lock Service for Loosely-Coupled Distributed Systems (OSDI 2006)]
* [http://static.usenix.org/event/atc10/tech/full_papers/Hunt.pdf Hunt et al., "ZooKeeper: Wait-free coordination for Internet-scale systems" (USENIX ATC 2010)] [https://www.usenix.org/legacy/multimedia/atc10hunt (video)]

===[[DistOS 2021F 2021-10-12|October 12, 2021]]===

BigTable & MapReduce
* [https://research.google.com/archive/bigtable-osdi06.pdf Chang et al., "BigTable: A Distributed Storage System for Structured Data" (OSDI 2006)]
* [https://research.google.com/archive/mapreduce.html Dean & Ghemawat, "MapReduce: Simplified Data Processing on Large Clusters" (OSDI 2004)] (be sure to read paper)

===[[DistOS 2021F 2021-10-14|October 14, 2021]]===

Omega & Borg
* [https://research.google/pubs/pub41684.pdf Schwarzkopf et al., "Omega: flexible, scalable schedulers for large compute clusters" (EuroSys 2013)]
* [https://research.google/pubs/pub43438.pdf Verma et al., "Large-scale cluster management at Google with Borg" (EuroSys 2015)]

===[[DistOS 2021F 2021-10-19|October 19, 2021]]===

Midterm Review

===October 21, 2021===

'''Midterm'''

===[[DistOS 2021F 2021-11-02|November 2, 2021]]===

Cassandra & Dynamo
* [http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf Lakshman & Malik, "Cassandra - A Decentralized Structured Storage System" (LADIS 2009)]
* [http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf DeCandia et al., "Dynamo: Amazon’s Highly Available Key-value Store" (SOSP 2007)]

===[[DistOS 2021F 2021-11-04|November 04, 2021]]===

Haystack & F4
* [http://static.usenix.org/legacy/events/osdi10/tech/full_papers/Beaver.pdf Beaver et al., "Finding a needle in Haystack: Facebook’s photo storage" (OSDI 2010)]
* [https://www.usenix.org/conference/osdi14/technical-sessions/presentation/muralidhar Muralidhar et al., "f4: Facebook's Warm BLOB Storage System" (OSDI 2014)]

===[[DistOS 2021F 2021-11-09|November 09, 2021]]===

'''Proposal due by 11:59 PM'''

Spanner & Tensorflow
* [https://www.usenix.org/conference/osdi12/technical-sessions/presentation/corbett Corbett et al., "Spanner: Google’s Globally-Distributed Database" (OSDI 2012)]
* [https://www.usenix.org/conference/osdi16/technical-sessions/presentation/abadi Martin Abadi et al., "TensorFlow: A System for Large-Scale Machine Learning" (OSDI 2016)]

===[[DistOS 2021F 2021-11-11|November 11, 2021]]===

Ceph
* [https://www.usenix.org/events/osdi06/tech/weil.html Weil et al., Ceph: A Scalable, High-Performance Distributed File System (OSDI 2006)].
* [https://homeostasis.scs.carleton.ca/~soma/distos/2021f/papers/weil2006-crush.pdf Weil et al., CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data (SC 2006)]

===[[DistOS 2021F 2021-11-16|November 16, 2021]]===

OceanStore & BOINC
* [https://homeostasis.scs.carleton.ca/~soma/distos/fall2008/oceanstore-sigplan.pdf John Kubiatowicz et al., "OceanStore: An Architecture for Global-Scale Persistent Storage" (SIGPLAN 2000)]
* [https://homeostasis.scs.carleton.ca/~soma/distos/fall2008/fast2003-pond.pdf Sean Rhea et al., "Pond: the OceanStore Prototype" (FAST 2003)]
* [https://homeostasis.scs.carleton.ca/~soma/distos/fall2008/anderson-boinc.pdf Anderson, "BOINC: A System for Public-Resource Computing and Storage" (Grid Computing 2004)]

===[[DistOS 2021F 2021-11-18|November 18, 2021]]===

Tapestry & Delos
* [https://pdos.csail.mit.edu/~strib/docs/tapestry/tapestry_jsac03.pdf Zhao et al, "Tapestry: A Resilient Global-Scale Overlay for Service Deployment" (JSAC 2003)]
* [https://www.usenix.org/system/files/osdi20-balakrishnan.pdf Balakrishnan et al., "Virtual Consensus in Delos" (OSDI 2020)]

Background (optional but helpful):
* [https://en.wikipedia.org/wiki/Distributed_hash_table Wikipedia's article on Distributed Hash Tables]

===[[DistOS 2021F 2021-11-23|November 23, 2021]]===

Cryptocurrency origins
* [https://homeostasis.scs.carleton.ca/~soma/distos/2021f/papers/lamport1982-generals.pdf Lamport et al., "The Byzantine Generals Problem" (TOPLAS 1982)]
* [https://homeostasis.scs.carleton.ca/~soma/distos/2021f/papers/nakamoto2008-bitcoin.pdf Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System" (2008)]
* [https://homeostasis.scs.carleton.ca/~soma/distos/2021f/papers/nakamoto2008-email.pdf Nakamoto, "Re: Bitcoin P2P e-cash paper" (2008)]
* [https://homeostasis.scs.carleton.ca/~soma/distos/2021f/papers/lemieux2013-satoshi.pdf Lemieux, "Who is Satoshi Nakamoto?" (Regulation, Fall 2013)]

===November 25, 2021===

No class, US Thanksgiving

===[[DistOS 2021F 2021-11-30|November 30, 2021]]===

Ethereum & NFTs
* [https://files.gitter.im/ethereum/yellowpaper/VIyt/Paper.pdf Wood, Ethereum: A secure decentralised generalised transaction ledger (2014)]
* [https://arxiv.org/pdf/2105.07447 Wang et al., "Non-Fungible Token (NFT): Overview, Evaluation, Opportunities and Challenges" (2021)]

===[[DistOS 2021F 2021-12-02|December 2, 2021]]===

Ethereum Security & The Future
* [https://dl.acm.org/doi/pdf/10.1145/3391195 Chen et al, "A survey on ethereum systems security: Vulnerabilities, attacks, and defenses" (CSUR 2020)]
* [https://homeostasis.scs.carleton.ca/~soma/pubs/burgess-nspw2018.pdf Burgess & Somayaji, "After the BlockCloud Apocalypse" (NSPW 2018)]

===[[DistOS 2021F 2021-12-07|December 7, 2021]]===

Project Presentations (Informal)

===[[DistOS 2021F 2021-12-09|December 9, 2021]]===

Class wrap up & Exam review

===December 19, 2021===

'''Final Exam''' (Online, 2-5 PM)

DistOS 2021F 2021-10-14

2021-10-14T23:46:07Z

Housedhorse:

==Notes==

=== Big Picture (What the heck is this stuff?) ===

* Think back the beginning of the course:
** Things were really mostly about taking ideas from Unix and making them distributed
** Folks did this at various levels of abstraction
** Some used the Unix kernel, some went off and did their own thing
* Now what are Borg, Omega and K8s doing?
** We’re no longer making Unix distributed – instead, we are distributing Unix
** The unit of computation is now a stripped-down Linux userspace -> containers!

What’s a container?

* It’s just a collection of related processes and their resources
** Often only one process
* The unifying abstractions in the Linux world are:
*# Namespaces
*# Control groups (cgroups) – These were actually invented at Google for Borg/Omega/K8s
* Namespaces provide private resource “mappings”
** So in my PID namespace my PID might be 1, while it might be 12345 in your PID namespace
** Your PID might not even exist in my PID namespace
* Control groups are used for:
** Resource accounting
** Resource management
** Think “quantifiable” resources, like CPU, I/O, memory
** These are often also used to canonically “group” processes together

What’s so special about a container here?

* You get some ''really'' nice emergent properties from containers in a distributed context
* The OS-dependent interface is small (system calls and some system-wide parameters)
* Limited interference (when well-behaved)
* Do Linux containers provide real security benefits on their own? '''NO.''' (At least don't rely on them to isolate anything important on their own)

Abstraction is one of the most important themes in OS design

* Recall the goal of an operating system: We want to turn the computer into something you want to program on
* Containers abstract away the details of the underlying system
** This is super nice for deploying applications
* Pods abstract away the details of orchestrating the containers
** This is super nice for distributing applications
* ''Multiple'' layers of abstraction emerge, beyond the underlying OS kernel (which itself is full of them!)

=== [https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43438.pdf Borg] ===

* What basic problem does Borg try to solve? Google basically had the following end goals in mind:
** We want to distribute our applications
** We want them to use resources efficiently
** We don’t want long-running services to go down, become overwhelmed, or become resource-starved
** We want our applications to be ''hardware-agnostic'' and ''OS-agnostic'' (this means we need abstractions!)
* Kinds of workloads
** Both batch jobs and long-running services
** Prod vs non-prod (latency-sensitive vs not) -> most batch jobs are non-prod while most services are prod
** Long-running services should be prioritized when scheduling – particularly if they are user-facing
* Work loads can be disparate, but run on shared resources
** This improves resource utilization
** Why is that a good thing?
** Time is money! More efficient utilization of computational resources reduces overhead cost
* Evolving internal tooling
** configuring + updating jobs
** predicting resource requirements
** pushing configuration
** service discovery + load balancing
* Tooling wasn’t really unified
** Most of it was developed ad-hoc as needed
** This is great, but the result is that we essentially lack any kind of consistency
** Lack of consistency in turn increases the barrier to entry for deploying new services on Borg
** Probably okay for internal use, but not really well-suited to end users
* Borg architecture:
** Compute clusters are broken into ''cells''
** Each cell can be made up of thousands of ''nodes''
** One Borgmaster per cell
** Many Borglets per cell
** N.B. Google typically only deploys one main cell on a given cluster, possibly with a few smaller cells for specific tasks
* Borgmaster election
** The Borgmaster abstraction presents as a single process
** But it’s actually replicated under the hood
** We choose one node as the ''elected master''
** Paxos allows us to establish consensus, Chubby then advertises who won the election
* Recovery from failure
** Borgmaster checkpoints -> a snapshot + a change log for reconstruction
** Checkpoints live in the Paxos datastore
** Fauxmaster can be used to simulate a real system with checkpoints
** Good for user intervention and capacity planning
* Container orchestration
** IPs are per-host
** Every container gets its own port number (any problems?)
** Workload is broken up into ''jobs'' which have ''tasks'' (just a domain-specific word for containers)
** Jobs and tasks are irrevocably linked together (one cannot exist without the other)

=== [https://storage.googleapis.com/pub-tools-public-publication-data/pdf/41684.pdf Omega] ===

* Built to be a better Borg scheduler
** Architectural improvements
** What were the problems with the original Borg scheduler?
* Storing internal state
** Transaction-oriented data store
** Paxos for consensus, fault-tolerance
** So far this is pretty similar to Borg, but….
** Optimistic concurrency control to handle conflicts
** Different parts of the cluster control plane access the data store
** The store is the ''only'' centralized component!
* How is their approach to internal state better than Borg?
** It enables them to break up the Borgmaster
** No longer a single point of failure
** Easier to scale and modify the control plane as needed
* Monolithic vs Two-Level vs Shared-State schedulers
** monolithic schedulers (generally) have no concurrency
** they use a single scheduling algorithm (it usually has to be both simple and fair)
** two-level schedulers have a component that passes off the resources to other schedulers
** ''two-level'' -> we are “scheduling” our schedulers
** shared state schedulers operate on readily available copies of resources
** some important properties in Omega’s design:
**# lock-free
**# optimistic concurrency control
**# transaction-based
* What does “lock-free” mean?
** A lock-free algorithm guarantees that all cores are able to make progress at any given time – in other words, guaranteed system-wide progress
** A wait-free algorithm has stronger guarantees: no computation will ever be blocked by another computation – in other words, guaranteed per-thread progress
** As you can imagine, wait-free algorithms are very hard to come up with (but the trade-off we get for higher complexity is even better concurrency guarantees)

=== [https://queue.acm.org/detail.cfm?id=2898444 How Does K8s Fit in Here?] ===

* K8s is an Omega designed for end-users
** Google wanted to sell more compute time on their cloud platform
** So they made the cloud more attractive to program on
* Pods
** A higher level abstraction on top of deployment containers
** Pods are containers that encapsulate one or more inner containers
** Pod defines the available resources, inner containers provide the isolation
** (Borg had a similar concept called the “alloc” but this was optional)
* Borg relied on external tooling to handle many of its resource and cluster management needs
* On the other hand, K8s tries to make its API consistent, rather than ad-hoc
** Exposes a set of API objects, each with its own purpose and accompanying metadta
** API objects have a base object metadata, spec, and status
** Spec varies by object type and describes its desired state
** Status describes its current state
** Object metadata then defines a consistent way of labelling objects
* Replication and auto scaling
** K8s decouples these concepts
** Replica controller ensures that a given number of pods of a given type are always running
** The auto scaler then just adjusts the number of desired pods, and the replica controller sees this change
* Separation of concerns between K8s components
** This is the Unix philosophy!
** Composable components that do one thing and do it well
* Different flavours of API object for different purposes, e.g.
** ReplicationController -> runs forever-replicated containers
** DaemonSet -> a single pod instance on every node
** Job -> a controller that can run an arbitrarily-scaled batch job from start to finish
* Reconciliation controllers
** Continually observe state in a loop
** Where discrepancies between current and desired state are detected, take action
** The actual controller is stateless
** This makes it fault-tolerant! If a controller fails, just let someone else pick up the slack
* All store accesses are forced through a centralized API server
** This helps to provide consistency in access
** Centralization makes it easy to enforce consistent semantics and provide abstractions

=== Discussion Questions ===

What is so special about using the container as a unit of computation? Did the papers discuss any particular motivation for this design choice? How does this approach differ from earlier papers we have looked at in this course?

How do the containers described here compare with Solaris Zones? How do both approaches compare with vanilla Unix?

How does Borg compare with Omega in terms of its design and architecture? How do both systems compare with Kubernetes? Which of these systems seems the most user-friendly? Are any of them better-equipped to fill some obvious niche?

Why do you think Google still mostly relied on Borg internally (at the time of these papers), despite admitted shortcomings?

What motivated the design of three different container orchestration frameworks? Why not just modify Borg as needed?

Did any tricky questions come up when reading the papers? Discuss these with your group and try to come up with possible answers to these questions.

Did you have any observations about a particular design choice (good or bad)? Try to reach an agreement as a group on a particular design choice. If you can’t reach an agreement, talk about why your opinions differ.

=== K8s Demo ===

* Cluster setup, Openstack setup, getting ready for experience 1
* Demonstrate some specific parts of experience 1, without giving anything away
* Any specific requests?

DistOS 2021F Experience 1

2021-09-26T17:50:01Z

Housedhorse:

= Introduction =

In this implementation experience, you will be configuring and deploying a simple “hello world” Kubernetes cluster using <code>minikube</code>. While your cluster is not yet truly “distributed”, it behaves just as a real Kubernetes cluster would. For more information on Kubernetes configuration, you may wish to consult the [https://kubernetes.io/docs/concepts/ official documentation]. Links to specific documentation items will also be provided as hints later on in this document.

With the exception of Part 2, completing this experience shouldn’t take more than a couple of hours. Feel free to collaborate with other students if you get stuck. However, '''you must acknowledge any collaboration'''. Additionally, '''copying and pasting or simply “changing up” each other’s answers will be treated as an academic integrity violation'''.

== Submissions ==

Your experience report should be submitted as a PDF file on Brightspace, written in '''paragraph form'''. Code snippets or screen shots are allowed to augment your prose but are not required. We will post a submission link on Brightspace within the next few days.

The experience report is '''due on November 2nd, 2021'''. However, it may be a good idea to get started as quickly as possible, especially if you plan on doing an implementation-focused final project.

== Receiving Your Grade ==

This experience is broken up into three parts:

# A series of easy tasks designed to get you familiar with setting up a simple Kubernetes cluster.
# A harder challenge that involves you deploying your own image in your cluster to interact with a simple API.
# An opportunity to reflect on your experiences with Kubernetes and make connections to overall themes in the course.

Students are expected to complete Part 1 and Part 3 to get a grade of at most a B+. Part 2 is optional, but must be completed to receive a grade of A- or higher. Marks will be deducted for insufficient explanations or answers that demonstrate a lack of effort. By this logic, you should have a fairly clear idea of what grade you will receive when you submit this experience, based on how much effort you put in.

== Setting Up Your Environment ==

To get started, you will need to run a few commands on your OpenStack course VM to set up the environment. If you are not yet on OpenStack, please get set up as quickly as possible. We have a [https://homeostasis.scs.carleton.ca/wiki/index.php/DistOS_2021F:_Using_Openstack detailed setup guide available] if you need assistance.

# SSH into your VM using your preferred SSH client. Remember that your username and password are both <code>student</code> by default.
# If you haven’t already, '''change your password''' with the <code>passwd</code> command.
# Set up a simple minikube cluster using <code>minikube start</code>. After running this command, you should see some information printed to your terminal as minikube sets up your environment. Let the command run to completion.
# Download the <code>deployment.yml</code> file to your VM using <code>wget</code>[https://homeostasis.scs.carleton.ca/~soma/distos/2021f/experiences/deployment.yml <code>https://homeostasis.scs.carleton.ca/~soma/distos/2021f/experiences/deployment.yml</code>].
# Deploy the experience 1 configuration by running <code>kubectl apply -f deployment.yml</code>. This should download some container images and create the necessary Kubernetes API objects to run our simple “distributed” application.

= Tasks =

== Part 1: Getting Started With Kubernetes (Easy) ==

Follow the instructions for each of the following numbered tasks. Make an effort to answer the accompanying questions, but more importantly please note down all of your observations and describe what you did for each task. You should also feel free to write down whatever questions you may have about a given task.

To achieve the best possible grade in this section, you must demonstrate that you have made an effort to understand the results of each task. (Note that an effort does not strictly mean a full understanding; it is okay to have questions!)

<ol style="list-style-type: decimal;">
<li>Kubernetes deploys Linux containers as “Pods”, which form an even higher-level abstraction around the container itself. In addition to Pods, Kubernetes supports several other API objects that abstract over various distributed systems concepts. The simple deployment you have installed uses a few of these API objects. Using <code>kubectl get <object type></code>, <code>kubectl explain <object type></code>, and <code>kubectl describe <object name></code>, identify at least three different kinds of API object that are used in our deployment and briefly describe what they do. You can refer to <code>kubectl --help</code> as needed to explain what these commands do.
Hint 1: Some resources are encapsulated by multiple layers of abstraction. Each “layer” counts as a unique type of object for the purposes of this question.
Hint 2: The command <code>kubectl api-resources</code> will enumerate a full list of all supported API objects. You may also wish to consult [https://kubernetes.io/docs/concepts/workloads/pods/ the relevant documentation] if you are stuck.
Hint 3: You may want to have a look at the contents of the <code>deployment.yml</code> file.</li>
<li>Run <code>kubectl get pods</code> to see a list of the pods that are running in your cluster. You should notice several <code>comp4000server</code> pods and one <code>comp4000client</code> pod. Spawn an interactive shell into the <code>comp4000client</code> pod using <code>kubectl exec comp4000client -it -- /bin/sh</code>. Examine the layout of your container’s filesystem. What files and directories exist? Do you think these files exist on your VM or somewhere else? What commands can you run? Hint: Try running <code>cd ..</code> to leave the empty <code>/client</code> directory.</li>
<li>Our cluster exposes the <code>comp4000server</code> pods using a <code>NodePort</code> service. To find its IP address, start by spawning another terminal by starting another SSH session. (You should probably have ''at least'' two terminals open for the rest of this experience.) In your second terminal, run <code>kubectl get services</code> and copy the <code>CLUSTER-IP</code> next to the <code>NodePort</code> service. From inside your <code>comp4000client</code> container, use <code>curl <IP address here></code> to send a GET request to the <code>NodePort</code> service. Repeat the same command a few different times. What do you notice about the output? Explain.
Hint: Try running <code>kubectl get pods</code> again to refresh your memory about the topology of our cluster.</li>
<li>The simple web server running behind our <code>NodePort</code> service exposes a convenient end point called <code>/crashme</code> that bricks the server. Try calling this end point several times like <code>for i in $(seq 1 20); do curl <IP address here>/crashme; done</code>, then try interacting with the servers after a few moments. Repeat the same experiment, but this time run <code>kubectl get pods -w</code> in another terminal to watch the status of your pods in real time. What do you think is happening? Try to come up with an explanation for the behaviour you see.</li>
<li>Another end point <code>/count</code> returns a count of how many GET requests the server has processed. Try spamming our <code>NodePort</code> with requests to <code>/count</code> like <code>for i in $(seq 1 4000); do curl <IP address here>/count; done</code>. What do you notice about the count for each server? Try to explain what you see. Hint: Think all the way back to the second question.</li>
<li>Try scaling up the replication count of <code>comp4000server</code>. You can do this using <code>kubectl scale deployment comp4000server --replicas <n></code> where <code><n></code> is a number of your choosing. Try this a few different times with different numbers and examine the output of <code>kubectl get pods</code> each time. You might also want to try repeating some of the earlier exercises with your newly scaled deployment.</li></ol>

== Part 2: Deploying a Custom Container Image (Hard) ==

The simple web server for this experience has one last end point: <code>/printerfacts</code>. Making an HTTP GET request to this end point returns some totally non-suspicious facts about printers. Your task is to write a simple client application (in any language of your choosing) to consume the <code>printerfacts</code> API in some way. Feel free to be as creative as you like.

Once you have written your application, containerize it and deploy it to your cluster in any way you see fit. For example, you may wish to replicate it, make it stateful (e.g. persist a simple database), or expose it to the outside world using a <code>LoadBalancer</code> service.

Tell us about what you did and how you did it. In particular, we want to hear about the parts you had difficulty with, any ideas you had that didn’t pan out, what ended up working, and how your deployment fits together with the rest of the cluster.

Points for this question will be awarded based on:

# The sophistication of your deployment. (Challenge yourself!)
# The quality of your explanation.

Here are some hints to help you get started:

# When you are creating your container image, you need to take extra care to ensure Kubernetes uses your local image. To do this, run <code>eval $(minikube docker-env)</code> before running any <code>docker</code> commands in your shell. In your <code>deployment.yml</code>, set <code>imagePullPolicy: Never</code> under the <code>container</code> field to force it to use your local image.
# You can create a new container image by writing a Dockerfile for it and running <code>docker build -t <name> .</code> to build it.
# You can modify the <code>deployment.yml</code> file to create your API object, then re-deploy it by running the same <code>kubectl apply -f</code> command from earlier. Feel free to copy-paste and/or modify any of the existing configuration.

== Part 3: Reflection ==

Summarize your experience with Kubernetes in a few paragraphs (both the good and the bad). What concepts do you see reflected here from the research papers we have read thus far? After having some hands-on experience with a distributed system technology, have any of your opinions or initial assumptions changed? Feel free to list any other thoughts you have.

= Acknowledgements =

The idea for the printerfacts API comes from Christine Dodrill’s [https://christine.website/blog/dev-printerfact-2021-04-17 wonderful blog post].

DistOS 2021F Experience 1

2021-09-26T17:34:58Z

Housedhorse:

= COMP4000 Implementation Experience 1: Getting Started with Kubernetes =

In this implementation experience, you will be configuring and deploying a simple “hello world” Kubernetes cluster using <code>minikube</code>. While your cluster is not yet truly “distributed”, it behaves just as a real Kubernetes cluster would. For more information on Kubernetes configuration, you may wish to consult the [https://kubernetes.io/docs/concepts/ official documentation]. Links to specific documentation items will also be provided as hints later on in this document.

With the exception of Part 2, completing this experience shouldn’t take more than a couple of hours. Feel free to collaborate with other students if you get stuck. However, '''you must acknowledge any collaboration'''. Additionally, '''copying and pasting or simply “changing up” each other’s answers will be treated as an academic integrity violation'''.

== Submissions ==

Your experience report should be submitted as a PDF file on Brightspace, written in '''paragraph form'''. Code snippets or screen shots are allowed to augment your prose but are not required. We will post a submission link on Brightspace within the next few days.

The experience report is '''due on November 2nd, 2021'''. However, it may be a good idea to get started as quickly as possible, especially if you plan on doing an implementation-focused final project.

== Receiving Your Grade ==

This experience is broken up into three parts:

# A series of easy tasks designed to get you familiar with setting up a simple Kubernetes cluster.
# A harder challenge that involves you deploying your own image in your cluster to interact with a simple API.
# An opportunity to reflect on your experiences with Kubernetes and make connections to overall themes in the course.

Students are expected to complete Part 1 and Part 3 to get a grade of at most B. Part 2 is optional, but must be completed to receive a grade of A- or higher. Marks will be deducted for insufficient explanations or answers that demonstrate a lack of effort. By this logic, you should have a fairly clear idea of what grade you will receive when you submit this experience, based on how much effort you put in.

== Getting Started ==

To get started, you will need to run a few commands on your OpenStack course VM to set up the environment. If you are not yet on OpenStack, please get set up as quickly as possible. We have a [https://homeostasis.scs.carleton.ca/wiki/index.php/DistOS_2021F:_Using_Openstack detailed setup guide available] if you need assistance.

# SSH into your VM using your preferred SSH client. Remember that your username and password are both <code>student</code> by default.
# If you haven’t already, '''change your password''' with the <code>passwd</code> command.
# Set up a simple minikube cluster using <code>minikube start</code>. After running this command, you should see some information printed to your terminal as minikube sets up your environment. Let the command run to completion.
# Download the <code>deployment.yml</code> file to your VM using <code>wget https://homeostasis.scs.carleton.ca/~soma/distos/2021f/experiences/deployment.yml</code>.
# Deploy the experience 1 configuration by running <code>kubectl apply -f deployment.yml</code>. This should download some container images and create the necessary Kubernetes API objects to run our simple “distributed” application.

== Part 1 (Easy) ==

Follow the instructions for each of the following numbered tasks. Make an effort to answer the accompanying questions, but more importantly please note down all of your observations and describe what you did for each task. You should also feel free to write down whatever questions you may have about a given task.

To achieve the best possible grade in this section, you must demonstrate that you have made an effort to understand the results of each task. (Note that an effort does not strictly mean a full understanding; it is okay to have questions!)

<ol style="list-style-type: decimal;">
<li>Kubernetes deploys Linux containers as “Pods”, which form an even higher-level abstraction around the container itself. In addition to Pods, Kubernetes supports several other API objects that abstract over various distributed systems concepts. The simple deployment you have installed uses a few of these API objects.
Using <code>kubectl get <object type></code>, <code>kubectl explain <object type></code>, and <code>kubectl describe <object name></code>, identify at least three different kinds of API object that are used in our deployment and briefly describe what they do. You can refer to <code>kubectl --help</code> as needed to explain what these commands do.
Hint 1: Some resources are encapsulated by multiple layers of abstraction. Each “layer” counts as a unique type of object for the purposes of this question.
Hint 2: The command <code>kubectl api-resources</code> will enumerate a full list of all supported API objects. You may also wish to consult [https://kubernetes.io/docs/concepts/workloads/pods/ the relevant documentation] if you are stuck.
Hint 3: You may want to have a look at the contents of the <code>deployment.yml</code> file.</li>
<li>Run <code>kubectl get pods</code> to see a list of the pods that are running in your cluster. You should notice several <code>comp4000server</code> pods and one <code>comp4000client</code> pod. Spawn an interactive shell into the <code>comp4000client</code> pod using <code>kubectl exec comp4000client -it -- /bin/sh</code>. Examine the layout of your container’s filesystem. What files and directories exist? Do you think these files exist on your VM or somewhere else? What commands can you run?
Hint: Try running <code>cd ..</code> to leave the empty <code>/client</code> directory.</li>
<li>Our cluster exposes the <code>comp4000server</code> pods using a <code>NodePort</code> service. To find its IP address, start by spawning another terminal by starting another SSH session. (You should probably have ''at least'' two terminals open for the rest of this experience.) In your second terminal, run <code>kubectl get services</code> and copy the <code>CLUSTER-IP</code> next to the <code>NodePort</code> service.
From inside your <code>comp4000client</code> container, use <code>curl <IP address here></code> to send a GET request to the <code>NodePort</code> service. Repeat the same command a few different times. What do you notice about the output? Explain.
Hint: Try running <code>kubectl get pods</code> again to refresh your memory about the topology of our cluster.</li>
<li>The simple web server running behind our <code>NodePort</code> service exposes a convenient end point called <code>/crashme</code> that bricks the server. Try calling this end point several times like <code>for i in $(seq 1 20); do curl <IP address here>/crashme; done</code>, then try interacting with the servers after a few moments.
Repeat the same experiment, but this time run <code>kubectl get pods -w</code> in another terminal to watch the status of your pods in real time. What do you think is happening? Try to come up with an explanation for the behaviour you see.</li>
<li>Another end point <code>/count</code> returns a count of how many GET requests the server has processed. Try spamming our <code>NodePort</code> with requests to <code>/count</code> like <code>for i in $(seq 1 4000); do curl <IP address here>/count; done</code>. What do you notice about the count for each server? Try to explain what you see.
Hint: Think all the way back to the second question.</li>
<li>Try scaling up the replication count of <code>comp4000server</code>. You can do this using <code>kubectl scale deployment comp4000server --replicas <n></code> where <code><n></code> is a number of your choosing. Try this a few different times with different numbers and examine the output of <code>kubectl get pods</code> each time. You might also want to try repeating some of the earlier exercises with your newly scaled deployment.</li></ol>

== Part 2: Deploying a Custom Container Image (Hard) ==

The simple web server for this experience has one last end point: <code>/printerfacts</code>. Making an HTTP GET request to this end point returns some totally non-suspicious facts about printers. Your task is to write a simple client application (in any language of your choosing) to consume the <code>printerfacts</code> API in some way. Feel free to be as creative as you like.

Once you have written your application, containerize it and deploy it to your cluster in any way you see fit. For example, you may wish to replicate it, make it stateful (e.g. persist a simple database), or expose it to the outside world using a <code>LoadBalancer</code> service.

Tell us about what you did and how you did it. In particular, we want to hear about the parts you had difficulty with, any ideas you had that didn’t pan out, what ended up working, and how your deployment fits together with the rest of the cluster.

Points for this question will be awarded based on:

<ol style="list-style-type: lower-alpha;">
<li>The sophistication of your deployment. (Challenge yourself!)</li>
<li>The quality of your explanation.</li></ol>

Here are some hints to help you get started:

<ol style="list-style-type: lower-alpha;">
<li>When you are creating your container image, you need to take extra care to ensure Kubernetes uses your local image. To do this, run <code>eval $(minikube docker-env)</code> before running any <code>docker</code> commands in your shell. In your <code>deployment.yml</code>, set <code>imagePullPolicy: Never</code> under the <code>container</code> field to force it to use your local image.</li>
<li>You can create a new container image by writing a Dockerfile for it and running <code>docker build -t <name> .</code> to build it.</li>
<li>You can modify the <code>deployment.yml</code> file to create your API object, then re-deploy it by running the same <code>kubectl apply -f</code> command from earlier. Feel free to copy-paste and/or modify any of the existing configuration.</li></ol>

== Part 3: Reflection ==

Summarize your experience with Kubernetes in a few paragraphs (both the good and the bad). What concepts do you see reflected here from the research papers we have read thus far? After having some hands on experience with a distributed system technology, have any of your opinions or initial assumptions changed? Feel free to list any other thoughts you have.

== Acknowledgements ==

The idea for the printerfacts API comes from Christine Dodrill’s [https://christine.website/blog/dev-printerfact-2021-04-17 wonderful blog post].

DistOS 2021F Experience 1

2021-09-26T17:28:31Z

Housedhorse: Add link to deployment manifest

= COMP4000 Implementation Experience 1: Getting Started with Kubernetes =

In this implementation experience, you will be configuring and deploying a simple “hello world” Kubernetes cluster using <code>minikube</code>. While your cluster is not yet truly “distributed”, it behaves just as a real Kubernetes cluster would. For more information on Kubernetes configuration, you may wish to consult the [https://kubernetes.io/docs/concepts/ official documentation]. Links to specific documentation items will also be provided as hints later on in this document.

With the exception of Part 2, completing this experience shouldn’t take more than a couple of hours. Feel free to collaborate with other students if you get stuck. However, '''you must acknowledge any collaboration'''. Additionally, '''copying and pasting or simply “changing up” each other’s answers will be treated as an academic integrity violation'''.

== Submissions ==

Your experience report should be submitted as a PDF file on Brightspace, written in '''paragraph form'''. Code snippets or screen shots are allowed to augment your prose but are not required. We will post a submission link on Brightspace within the next few days.

The experience report is '''due on November 2nd, 2021'''. However, it may be a good idea to get started as quickly as possible, especially if you plan on doing an implementation-focused final project.

== Receiving Your Grade ==

This experience is broken up into three parts:

# A series of easy tasks designed to get you familiar with setting up a simple Kubernetes cluster.
# A harder challenge that involves you deploying your own image in your cluster to interact with a simple API.
# An opportunity to reflect on your experiences with Kubernetes and make connections to overall themes in the course.

Students are expected to complete Part 1 and Part 3 to get a grade of at most B. Part 2 is optional, but must be completed to receive a grade of A- or higher. Marks will be deducted for insufficient explanations or answers that demonstrate a lack of effort. By this logic, you should have a fairly clear idea of what grade you will receive when you submit this experience, based on how much effort you put in.

== Getting Started ==

To get started, you will need to run a few commands on your OpenStack course VM to set up the environment. If you are not yet on OpenStack, please get set up as quickly as possible. We have a [https://homeostasis.scs.carleton.ca/wiki/index.php/DistOS_2021F:_Using_Openstack detailed setup guide available] if you need assistance.

# SSH into your VM using your preferred SSH client. Remember that your username and password are both <code>student</code> by default.
# If you haven’t already, '''change your password''' with the <code>passwd</code> command.
# Set up a simple minikube cluster using <code>minikube start</code>. After running this command, you should see some information printed to your terminal as minikube sets up your environment. Let the command run to completion.
# Download the <code>deployment.yml</code> file to your VM using <code>wget https://homeostasis.scs.carleton.ca/~soma/distos/2021f/experiences/deployment.yml</code>.
# Deploy the experience 1 configuration by running <code>kubectl apply -f deployment.yml</code>. This should download some container images and create the necessary Kubernetes API objects to run our simple “distributed” application.

== Part 1 (Easy) ==

Follow the instructions for each of the following numbered tasks. Make an effort to answer the accompanying questions, but more importantly please note down all of your observations and describe what you did for each task. You should also feel free to write down whatever questions you may have about a given task.

To achieve the best possible grade in this section, you must demonstrate that you have made an effort to understand the results of each task. (Note that an effort does not strictly mean a full understanding; it is okay to have questions!)

<ol style="list-style-type: decimal;">
<li>Kubernetes deploys Linux containers as “Pods”, which form an even higher-level abstraction around the container itself. In addition to Pods, Kubernetes supports several other API objects that abstract over various distributed systems concepts. The simple deployment you have installed uses a few of these API objects.
Using <code>kubectl get <object type></code>, <code>kubectl explain <object type></code>, and <code>kubectl describe <object name></code>, identify at least three different kinds of API object that are used in our deployment and briefly describe what they do. You can refer to <code>kubectl --help</code> as needed to explain what these commands do.
Hint 1: Some resources are encapsulated by multiple layers of abstraction. Each “layer” counts as a unique type of object for the purposes of this question.
Hint 2: The command <code>kubectl api-resources</code> will enumerate a full list of all supported API objects. You may also wish to consult [https://kubernetes.io/docs/concepts/workloads/pods/ the relevant documentation] if you are stuck.
Hint 3: You may want to have a look at the contents of the <code>deployment.yml</code> file.</li>
<li>Run <code>kubectl get pods</code> to see a list of the pods that are running in your cluster. You should notice several <code>comp4000server</code> pods and one <code>comp4000client</code> pod. Spawn an interactive shell into the <code>comp4000client</code> pod using <code>kubectl exec comp4000client -it -- /bin/sh</code>. Examine the layout of your container’s filesystem. What files and directories exist? Do you think these files exist on your VM or somewhere else? What commands can you run?
Hint: Try running <code>cd ..</code> to leave the empty <code>/client</code> directory.</li>
<li>Our cluster exposes the <code>comp4000server</code> pods using a <code>NodePort</code> service. To find its IP address, start by spawning another terminal by starting another SSH session. (You should probably have ''at least'' two terminals open for the rest of this experience.) In your second terminal, run <code>kubectl get services</code> and copy the <code>CLUSTER-IP</code> next to the <code>NodePort</code> service.
From inside your <code>comp4000client</code> container, use <code>curl <IP address here></code> to send a GET request to the <code>NodePort</code> service. Repeat the same command a few different times. What do you notice about the output? Explain.
Hint: Try running <code>kubectl get pods</code> again to refresh your memory about the topology of our cluster.</li>
<li>The simple web server running behind our <code>NodePort</code> service exposes a convenient end point called <code>/crashme</code> that bricks the server. Try calling this end point several times like <code>for i in $(seq 1 20); do curl <IP address here>/crashme; done</code>, then try interacting with the servers after a few moments.
Repeat the same experiment, but this time run <code>kubectl get pods -w</code> in another terminal to watch the status of your pods in real time. What do you think is happening? Try to come up with an explanation for the behaviour you see.</li>
<li>Another end point <code>/count</code> returns a count of how many GET requests the server has processed. Try spamming our <code>NodePort</code> with requests to <code>/count</code> like <code>for i in $(seq 1 10000); do curl <IP address here>/count; done</code>. What do you notice about the count for each server? Try to explain what you see.
Hint: Think all the way back to the second question.</li>
<li>Try scaling up the replication count of <code>comp4000server</code>. You can do this using <code>kubectl scale deployment comp4000server --replicas <n></code> where <code><n></code> is a number of your choosing. Try this a few different times with different numbers and examine the output of <code>kubectl get pods</code> each time. You might also want to try repeating some of the earlier exercises with your newly scaled deployment.</li></ol>

== Part 2: Deploying a Custom Container Image (Hard) ==

The simple web server for this experience has one last end point: <code>/printerfacts</code>. Making an HTTP GET request to this end point returns some totally non-suspicious facts about printers. Your task is to write a simple client application (in any language of your choosing) to consume the <code>printerfacts</code> API in some way. Feel free to be as creative as you like.

Once you have written your application, containerize it and deploy it to your cluster in any way you see fit. For example, you may wish to replicate it, make it stateful (e.g. persist a simple database), or expose it to the outside world using a <code>LoadBalancer</code> service.

Tell us about what you did and how you did it. In particular, we want to hear about the parts you had difficulty with, any ideas you had that didn’t pan out, what ended up working, and how your deployment fits together with the rest of the cluster.

Points for this question will be awarded based on:

<ol style="list-style-type: lower-alpha;">
<li>The sophistication of your deployment. (Challenge yourself!)</li>
<li>The quality of your explanation.</li></ol>

Here are some hints to help you get started:

<ol style="list-style-type: lower-alpha;">
<li>When you are creating your container image, you need to take extra care to ensure Kubernetes uses your local image. To do this, run <code>eval $(minikube docker-env)</code> before running any <code>docker</code> commands in your shell. In your <code>deployment.yml</code>, set <code>imagePullPolicy: Never</code> under the <code>container</code> field to force it to use your local image.</li>
<li>You can create a new container image by writing a Dockerfile for it and running <code>docker build -t <name> .</code> to build it.</li>
<li>You can modify the <code>deployment.yml</code> file to create your API object, then re-deploy it by running the same <code>kubectl apply -f</code> command from earlier. Feel free to copy-paste and/or modify any of the existing configuration.</li></ol>

== Part 3: Reflection ==

Summarize your experience with Kubernetes in a few paragraphs (both the good and the bad). What concepts do you see reflected here from the research papers we have read thus far? After having some hands on experience with a distributed system technology, have any of your opinions or initial assumptions changed? Feel free to list any other thoughts you have.

== Acknowledgements ==

The idea for the printerfacts API comes from Christine Dodrill’s [https://christine.website/blog/dev-printerfact-2021-04-17 wonderful blog post].

DistOS 2021F Experience 1

2021-09-26T17:24:37Z

Housedhorse: Created page with "= COMP4000 Implementation Experience 1: Getting Started with Kubernetes = In this implementation experience, you will be configuring and deploying a simple “hello world”..."

= COMP4000 Implementation Experience 1: Getting Started with Kubernetes =

In this implementation experience, you will be configuring and deploying a simple “hello world” Kubernetes cluster using <code>minikube</code>. While your cluster is not yet truly “distributed”, it behaves just as a real Kubernetes cluster would. For more information on Kubernetes configuration, you may wish to consult the [https://kubernetes.io/docs/concepts/ official documentation]. Links to specific documentation items will also be provided as hints later on in this document.

With the exception of Part 2, completing this experience shouldn’t take more than a couple of hours. Feel free to collaborate with other students if you get stuck. However, '''you must acknowledge any collaboration'''. Additionally, '''copying and pasting or simply “changing up” each other’s answers will be treated as an academic integrity violation'''.

== Submissions ==

Your experience report should be submitted as a PDF file on Brightspace, written in '''paragraph form'''. Code snippets or screen shots are allowed to augment your prose but are not required. We will post a submission link on Brightspace within the next few days.

The experience report is '''due on November 2nd, 2021'''. However, it may be a good idea to get started as quickly as possible, especially if you plan on doing an implementation-focused final project.

== Receiving Your Grade ==

This experience is broken up into three parts:

# A series of easy tasks designed to get you familiar with setting up a simple Kubernetes cluster.
# A harder challenge that involves you deploying your own image in your cluster to interact with a simple API.
# An opportunity to reflect on your experiences with Kubernetes and make connections to overall themes in the course.

Students are expected to complete Part 1 and Part 3 to get a grade of at most B. Part 2 is optional, but must be completed to receive a grade of A- or higher. Marks will be deducted for insufficient explanations or answers that demonstrate a lack of effort. By this logic, you should have a fairly clear idea of what grade you will receive when you submit this experience, based on how much effort you put in.

== Getting Started ==

To get started, you will need to run a few commands on your OpenStack course VM to set up the environment. If you are not yet on OpenStack, please get set up as quickly as possible. We have a [https://homeostasis.scs.carleton.ca/wiki/index.php/DistOS_2021F:_Using_Openstack detailed setup guide available] if you need assistance.

# SSH into your VM using your preferred SSH client. Remember that your username and password are both <code>student</code> by default.
# If you haven’t already, '''change your password''' with the <code>passwd</code> command.
# Set up a simple minikube cluster using <code>minikube start</code>. After running this command, you should see some information printed to your terminal as minikube sets up your environment. Let the command run to completion.
# Deploy the experience 1 configuration by running <code>kubectl apply -f deployment.yml</code>. This should download some container images and create the necessary Kubernetes API objects to run our simple “distributed” application.

== Part 1 (Easy) ==

Follow the instructions for each of the following numbered tasks. Make an effort to answer the accompanying questions, but more importantly please note down all of your observations and describe what you did for each task. You should also feel free to write down whatever questions you may have about a given task.

To achieve the best possible grade in this section, you must demonstrate that you have made an effort to understand the results of each task. (Note that an effort does not strictly mean a full understanding; it is okay to have questions!)

<ol style="list-style-type: decimal;">
<li>Kubernetes deploys Linux containers as “Pods”, which form an even higher-level abstraction around the container itself. In addition to Pods, Kubernetes supports several other API objects that abstract over various distributed systems concepts. The simple deployment you have installed uses a few of these API objects.
Using <code>kubectl get <object type></code>, <code>kubectl explain <object type></code>, and <code>kubectl describe <object name></code>, identify at least three different kinds of API object that are used in our deployment and briefly describe what they do. You can refer to <code>kubectl --help</code> as needed to explain what these commands do.
Hint 1: Some resources are encapsulated by multiple layers of abstraction. Each “layer” counts as a unique type of object for the purposes of this question.
Hint 2: The command <code>kubectl api-resources</code> will enumerate a full list of all supported API objects. You may also wish to consult [https://kubernetes.io/docs/concepts/workloads/pods/ the relevant documentation] if you are stuck.
Hint 3: You may want to have a look at the contents of the <code>deployment.yml</code> file.</li>
<li>Run <code>kubectl get pods</code> to see a list of the pods that are running in your cluster. You should notice several <code>comp4000server</code> pods and one <code>comp4000client</code> pod. Spawn an interactive shell into the <code>comp4000client</code> pod using <code>kubectl exec comp4000client -it -- /bin/sh</code>. Examine the layout of your container’s filesystem. What files and directories exist? Do you think these files exist on your VM or somewhere else? What commands can you run?
Hint: Try running <code>cd ..</code> to leave the empty <code>/client</code> directory.</li>
<li>Our cluster exposes the <code>comp4000server</code> pods using a <code>NodePort</code> service. To find its IP address, start by spawning another terminal by starting another SSH session. (You should probably have ''at least'' two terminals open for the rest of this experience.) In your second terminal, run <code>kubectl get services</code> and copy the <code>CLUSTER-IP</code> next to the <code>NodePort</code> service.
From inside your <code>comp4000client</code> container, use <code>curl <IP address here></code> to send a GET request to the <code>NodePort</code> service. Repeat the same command a few different times. What do you notice about the output? Explain.
Hint: Try running <code>kubectl get pods</code> again to refresh your memory about the topology of our cluster.</li>
<li>The simple web server running behind our <code>NodePort</code> service exposes a convenient end point called <code>/crashme</code> that bricks the server. Try calling this end point several times like <code>for i in $(seq 1 20); do curl <IP address here>/crashme; done</code>, then try interacting with the servers after a few moments.
Repeat the same experiment, but this time run <code>kubectl get pods -w</code> in another terminal to watch the status of your pods in real time. What do you think is happening? Try to come up with an explanation for the behaviour you see.</li>
<li>Another end point <code>/count</code> returns a count of how many GET requests the server has processed. Try spamming our <code>NodePort</code> with requests to <code>/count</code> like <code>for i in $(seq 1 10000); do curl <IP address here>/count; done</code>. What do you notice about the count for each server? Try to explain what you see.
Hint: Think all the way back to the second question.</li>
<li>Try scaling up the replication count of <code>comp4000server</code>. You can do this using <code>kubectl scale deployment comp4000server --replicas <n></code> where <code><n></code> is a number of your choosing. Try this a few different times with different numbers and examine the output of <code>kubectl get pods</code> each time. You might also want to try repeating some of the earlier exercises with your newly scaled deployment.</li></ol>

== Part 2: Deploying a Custom Container Image (Hard) ==

The simple web server for this experience has one last end point: <code>/printerfacts</code>. Making an HTTP GET request to this end point returns some totally non-suspicious facts about printers. Your task is to write a simple client application (in any language of your choosing) to consume the <code>printerfacts</code> API in some way. Feel free to be as creative as you like.

Once you have written your application, containerize it and deploy it to your cluster in any way you see fit. For example, you may wish to replicate it, make it stateful (e.g. persist a simple database), or expose it to the outside world using a <code>LoadBalancer</code> service.

Tell us about what you did and how you did it. In particular, we want to hear about the parts you had difficulty with, any ideas you had that didn’t pan out, what ended up working, and how your deployment fits together with the rest of the cluster.

Points for this question will be awarded based on:

<ol style="list-style-type: lower-alpha;">
<li>The sophistication of your deployment. (Challenge yourself!)</li>
<li>The quality of your explanation.</li></ol>

Here are some hints to help you get started:

<ol style="list-style-type: lower-alpha;">
<li>When you are creating your container image, you need to take extra care to ensure Kubernetes uses your local image. To do this, run <code>eval $(minikube docker-env)</code> before running any <code>docker</code> commands in your shell. In your <code>deployment.yml</code>, set <code>imagePullPolicy: Never</code> under the <code>container</code> field to force it to use your local image.</li>
<li>You can create a new container image by writing a Dockerfile for it and running <code>docker build -t <name> .</code> to build it.</li>
<li>You can modify the <code>deployment.yml</code> file to create your API object, then re-deploy it by running the same <code>kubectl apply -f</code> command from earlier. Feel free to copy-paste and/or modify any of the existing configuration.</li></ol>

== Part 3: Reflection ==

Summarize your experience with Kubernetes in a few paragraphs (both the good and the bad). What concepts do you see reflected here from the research papers we have read thus far? After having some hands on experience with a distributed system technology, have any of your opinions or initial assumptions changed? Feel free to list any other thoughts you have.

== Acknowledgements ==

The idea for the printerfacts API comes from Christine Dodrill’s [https://christine.website/blog/dev-printerfact-2021-04-17 wonderful blog post].

DistOS 2021F: Using Openstack

2021-09-09T19:20:53Z

Housedhorse: Grammar

= OpenStack =

We will be using OpenStack to spin up virtual machine instances for use during the implementation experiences and (optionally) the course project if you choose to include an implementation component. In the first implementation experience, you will be working with a personal VM hosted on OpenStack. To get set up, follow the instructions below.

== Getting Started ==

To get started and connect to the OpenStack dashboard, you will first need to update your SCS account and connect to Carleton’s intranet via a VPN. You can see [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ the official guide provided by SCS technical support] for more details.

First, connect to the Carleton VPN by following the [https://carleton.ca/its/help-centre/remote-access/ remote access VPN instructions]. Once you are connected, you will likely need to update your SCS account to be added to our course’s OpenStack project. You can do so by [https://www.scs.carleton.ca/webacct clicking this link] and following the instructions. You '''do not''' need to change your SCS password, but you can if you like.

Once you are connected to the VPN and your account has been updated, you can access [https://openstack-stein.scs.carleton.ca/ our course’s OpenStack dashboard]. After clicking the link, you may need to select the COMP4000A-F21 project from the dropdown menu in the top left.

== Setting Up Your Personal VM ==

To set up your VM, navigate to <code>Compute -> Instances</code> using the menu on the left-hand side of the page. Then click the <code>Launch Instance</code> button near the top right. Then provide the following information:

* Under <code>Details</code>, set <code>Instance Name</code> to <code>firstname-lastname</code> where you sub in your first and last name respectively. You '''must''' follow this naming convention, otherwise your instance may be deleted without notice.
* Under <code>Source</code> select <code>Instance Snapshot</code> from the <code>Boot Source</code> dropdown. Then scroll down and select <code>COMP4000-studentvm-v1</code> by clicking the corresponding arrow on the right hand side.
* Under <code>Flavor</code> click the arrow on the right hand side of <code>comp4000a-f21.4gram.8gdisk.2cpu</code>.
* Under <code>Security Goups</code> click the arrow on the right hand side of <code>ping-ssh-egress</code>.
* Finally, click the blue <code>Launch Instance</code> button.

After following these steps, you should see your named instance show up in the list (likely at the top). Once you locate your instance, select <code>Associate Floating IP</code> using the dropdown on the right-hand side. You will be prompted to select an IP address starting in <code>134</code>. '''This is the IP address you will use to connect to your VM later.'''

== Connecting to Your Personal VM ==

You can connect to your personal VM using an ssh client. On Linux, MacOS, and WSL, you can do this using the <code>ssh</code> command like <code>ssh student@my.floating.ip</code>, where you replace <code>my.floating.ip</code> with your floating IP from earlier. You will then be prompted to enter your password, which is just <code>student</code> by default.

On Windows without WSL, you can use an ssh client like [https://www.putty.org/ <code>PuTTY</code>]. After downloading PuTTY, you can configure it to connect to your VM’s floating IP.

'''NOTE:''' You must either be connected to the Carleton VPN or perform a ProxyJump in order to ssh into your VM. We recommend avoiding the VPN and using a ProxyJump instead, as this will lighten the load on Carleton’s network.

=== Performing a ProxyJump Using SSH ===

This step is only necessary if you wish to connect to the VM without using the Carleton VPN.

You can use your access.scs.carleton.ca account to perform a ProxyJump into Carleton’s internal network. You can do so by modifying the ssh command from before as follows: <code>ssh -J scsname@access.scs.carleton.ca student@my.floating.ip</code>, where you replace <code>scsname</code> with your Carleton username. You will be prompted to enter a password '''twice'''. The first time, enter your SCS password. The second time, enter the password you chose for the <code>student</code> user on your VM.

If you are using <code>PuTTY</code>, note that it has no direct equivalent of a ProxyJump. Instead, you can consult [https://superuser.com/questions/1448180/how-to-setup-proxy-jump-with-putty this link] for help.

DistOS 2021F: Using Openstack

2021-09-09T19:19:08Z

Housedhorse: Created page with "= OpenStack = We will be using OpenStack to spin up virtual machine instances for use during the implementation experiences and (optionally) the course project if you choose..."

= OpenStack =

We will be using OpenStack to spin up virtual machine instances for use during the implementation experiences and (optionally) the course project if you choose to include an implementation component. In the first implementation experience, you will be working with a personal VM hosted on OpenStack. To get set up, follow the instructions below.

== Getting Started ==

To get started and connect to the OpenStack dashboard, you will first need to update your SCS account and connect to Carleton’s intranet via a VPN. You can see [https://carleton.ca/scs/tech-support/scs-open-stack/openstack-technical-support/ the official guide provided by SCS technical support] for more details.

First, connect to the Carleton VPN by following the [https://carleton.ca/its/help-centre/remote-access/ remote access VPN instructions]. Once you are connected, you will likely need to update your SCS account to be added to our course’s OpenStack project. You can do so by [https://www.scs.carleton.ca/webacct clicking this link] and following the instructions. You '''do not''' need to change your SCS password, but you can if you like.

Once you are connected to the VPN and your account has been updated, you can access [https://openstack-stein.scs.carleton.ca/ our course’s OpenStack dashboard]. After clicking the link, you may need to select the COMP4000A-F21 project from the dropdown menu in the top left.

== Setting Up Your Personal VM ==

To set up your VM, navigate to <code>Compute -> Instances</code> using the menu on the left-hand side of the page. Then click the <code>Launch Instance</code> button near the top right. Then, provide the following information:

* Under <code>Details</code>, set <code>Instance Name</code> to <code>firstname-lastname</code> where you sub in your first and last name respectively. You '''must''' follow this naming convention, otherwise your instance may be deleted without notice.
* Under <code>Source</code> select <code>Instance Snapshot</code> from the <code>Boot Source</code> dropdown. Then scroll down and select <code>COMP4000-studentvm-v1</code> by clicking the corresponding arrow on the right hand side.
* Under <code>Flavor</code> click the arrow on the right hand side of <code>comp4000a-f21.4gram.8gdisk.2cpu</code>.
* Under <code>Security Goups</code> click the arrow on the right hand side of <code>ping-ssh-egress</code>.
* Finally, click the blue <code>Launch Instance</code> button.

After following these steps, you should see your named instance show up in the list (likely at the top). Once you locate your instance, select <code>Associate Floating IP</code> using the dropdown on the right-hand side. You will be prompted to select an IP address starting in <code>134</code>. '''This is the IP address you will use to connect to your VM later.'''

== Connecting to Your Personal VM ==

You can connect to your personal VM using an ssh client. On Linux, MacOS, and WSL, you can do this using the <code>ssh</code> command like <code>ssh student@my.floating.ip</code>, where you replace <code>my.floating.ip</code> with your floating IP from earlier. You will then be prompted to enter your password, which is just <code>student</code> by default.

On Windows without WSL, you can use an ssh client like [https://www.putty.org/ <code>PuTTY</code>]. After downloading PuTTY, you can configure it to connect to your VM’s floating IP.

'''NOTE:''' You must either be connected to the Carleton VPN or perform a ProxyJump in order to ssh into your VM. We recommend avoiding the VPN and using a ProxyJump instead, as this will lighten the load on Carleton’s network.

=== Performing a ProxyJump Using SSH ===

This step is only necessary if you wish to connect to the VM without using the Carleton VPN.

You can use your access.scs.carleton.ca account to perform a ProxyJump into Carleton’s internal network. You can do so by modifying the ssh command from before as follows: <code>ssh -J scsname@access.scs.carleton.ca student@my.floating.ip</code>, where you replace <code>scsname</code> with your Carleton username. You will be prompted to enter a password '''twice'''. The first time, enter your SCS password. The second time, enter the password you chose for the <code>student</code> user on your VM.

If you are using <code>PuTTY</code>, note that it has no direct equivalent of a ProxyJump. Instead, you can consult [https://superuser.com/questions/1448180/how-to-setup-proxy-jump-with-putty this link] for help.

Operating Systems (Fall 2019)

2019-09-24T23:39:31Z

Housedhorse: /* Tutorial Grading */

==Course Outline==

[[Operating Systems (Fall 2019) Course Outline|Here]] is the course outline for COMP 3000: Operating Systems.

==Lectures & Tests==

Note that the topics below are primarily chapters from the class textbook, [http://pages.cs.wisc.edu/~remzi/OSTEP/ Operating Systems: Three Easy Pieces]. Note that while introductory and summary dialogues are not linked below, they are worth reading for an informal take on the material.

Assigned readings are subject to change, please check this page each week.

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
</tr>
<tr>
<td>
Sept. 4

</td>
<td>
[[Operating Systems 2019F Lecture 1|Lecture 1]]: [http://pages.cs.wisc.edu/~remzi/OSTEP/intro.pdf Introduction]

</td>
</tr>
<tr>
<td>
Sept. 6

</td>
<td>
[[Operating Systems 2019F Lecture 2|Lecture 2]]: [http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-api.pdf Process API]

</td>
</tr>
<tr>
<td>
Sept. 11

</td>
<td>
[[Operating Systems 2019F Lecture 3|Lecture 3]]: [http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-intro.pdf Processes]

</td>
</tr>
<tr>
<td>
Sept. 13

</td>
<td>
[[Operating Systems 2019F Lecture 4|Lecture 4]]: [http://pages.cs.wisc.edu/~remzi/OSTEP/file-intro.pdf Files]

</td>
</tr>
<tr>
<td>
Sept. 18

</td>
<td>
[[Operating Systems 2019F Lecture 5|Lecture 5]]: [http://pages.cs.wisc.edu/~remzi/OSTEP/vm-intro.pdf Address Spaces] [http://pages.cs.wisc.edu/~remzi/OSTEP/dialogue-vm.pdf (Dialogue)]

</td>
</tr>
<tr>
<td>
Sept. 20

</td>
<td>
[[Operating Systems 2019F Lecture 6|Lecture 6]]

</td>
</tr>
<tr>
<td>
Sept. 25

</td>
<td>
[[Operating Systems 2019F Lecture 7|Lecture 7]]

</td>
</tr>
<tr>
<td>
Sept. 27

</td>
<td>
[[Operating Systems 2019F Lecture 8|Lecture 8]]

</td>
</tr>
<tr>
<td>
Oct. 2

</td>
<td>
[[Operating Systems 2019F Lecture 9|Lecture 9]]: [http://pages.cs.wisc.edu/~remzi/OSTEP/file-devices.pdf I/O Devices], [http://pages.cs.wisc.edu/~remzi/OSTEP/file-disks.pdf Hard disk drives], [http://pages.cs.wisc.edu/~remzi/OSTEP/file-implementation.pdf Filesystem implementation], [http://pages.cs.wisc.edu/~remzi/OSTEP/file-journaling.pdf FSCK and Journaling]

</td>
</tr>
<tr>
<td>
Oct. 4

</td>
<td>
[[Operating Systems 2019F Lecture 10|Lecture 10]]

</td>
</tr>
<tr>
<td>
Oct. 9

</td>
<td>
[[Operating Systems 2019F Lecture 11|Lecture 11]]

</td>
</tr>
<tr>
<td>
Oct. 11

</td>
<td>
[[Operating Systems 2019F Lecture 12|Lecture 12]]: Midterm Review

</td>
</tr>
<tr>
<td>
Oct. 16

</td>
<td>
Midterm Exam

</td>
</tr>
<tr>
<td>
Oct. 18

</td>
<td>
[[Operating Systems 2019F Lecture 13|Lecture 13]]

</td>
</tr>
<tr>
<td>
Oct. 30

</td>
<td>
[[Operating Systems 2019F Lecture 14|Lecture 14]]

</td>
</tr>
<tr>
<td>
Nov. 1

</td>
<td>
[[Operating Systems 2019F Lecture 15|Lecture 15]]

</td>
</tr>
<tr>
<td>
Nov. 6

</td>
<td>
[[Operating Systems 2019F Lecture 16|Lecture 16]]

</td>
</tr>
<tr>
<td>
Nov. 8

</td>
<td>
[[Operating Systems 2019F Lecture 17|Lecture 17]]

</td>
</tr>
<tr>
<td>
Nov. 13

</td>
<td>
[[Operating Systems 2019F Lecture 18|Lecture 18]]

</td>
</tr>
<tr>
<td>
Nov. 15

</td>
<td>
[[Operating Systems 2019F Lecture 19|Lecture 19]]

</td>
</tr>
<tr>
<td>
Nov. 20

</td>
<td>
[[Operating Systems 2019F Lecture 20|Lecture 20]]

</td>
</tr>
<tr>
<td>
Nov. 22

</td>
<td>
[[Operating Systems 2019F Lecture 21|Lecture 21]]

</td>
</tr>
<tr>
<td>
Nov. 27

</td>
<td>
[[Operating Systems 2019F Lecture 22|Lecture 22]]

</td>
</tr>
<tr>
<td>
Nov. 29

</td>
<td>
[[Operating Systems 2019F Lecture 23|Lecture 23]]

</td>
</tr>
<tr>
<td>
Dec. 4

</td>
<td>
[[Operating Systems 2019F Lecture 24|Lecture 24]]

</td>
</tr>
<tr>
<td>
TBD

</td>
<td>
Final Exam

</td>
</tr>
</table>

==Tutorials==

'''Note this has changed for Tutorials 3 and 4.'''

You may complete tutorials in lab or on your own. Submit your answers on culearn, they are due before the next week but are accepted with no grade penalty up until the related assignment is due. (For example, Tutorials 1 and 2 must be completed before Assignment 1 is submitted.)

Your answers will be graded based on participation, not understanding. Basically, if you make a reasonable attempt at the whole tutorial you'll get 4/4. Partial attempts will potentially be given partial credit; however, you may improve your tutorial mark as long as it is still being accepted. Exceptions will be made only if there are extenuating circumstances.

While you may collaborate with others and use outside resources, you should indicate the names of who you worked with and cite the sources you used.

The words you submit should be your own. Please don't copy-paste answers from others, because if you do, you are subject to being reported to the Dean for plagiarism.

Note that your assigned TA will be marking your work. You can find your TA by looking at the feedback portion of the "TA" grade item in cuLearn.

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Tutorials
</th>
</tr>
<tr>
<td>
Sept. 9-13

</td>
<td>
[[Operating Systems 2019F: Tutorial 1|Processes]]

</td>
</tr>
<tr>
<td>
Sept. 16-20

</td>
<td>
[[Operating Systems 2019F: Tutorial 2|3000shell]]

</td>
</tr>
<tr>
<td>
Sept. 23-27

</td>
<td>
[[Operating Systems 2019F: Tutorial 3|Memory & System Calls]]

</td>
</tr>
<tr>
<td>
Sept. 30-Oct. 4

</td>
<td>
[[Operating Systems 2019F: Tutorial 4|3000test]]

</td>
</tr>
<tr>
<td>
Oct. 28-Nov. 1

</td>
<td>
[[Operating Systems 2019F: Tutorial 5|TBD]]

</td>
</tr>
<tr>
<td>
Nov. 4-8

</td>
<td>
[[Operating Systems 2019F: Tutorial 6|TBD]]

</td>
</tr>
<tr>
<td>
Nov. 11-15

</td>
<td>
[[Operating Systems 2019F: Tutorial 7|TBD]]

</td>
</tr>
<tr>
<tr>
<td>
Nov. 18-22

</td>
<td>
[[Operating Systems 2019F: Tutorial 8|TBD]]

</td>
</tr>
<tr>
<td>
Nov. 25-29

</td>
<td>
[[Operating Systems 2019F: Tutorial 9|TBD]]

</td>
</tr>
</table>

==Assignments==

Assignments are due before class on the due dates (2:30 PM).

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Due Date
</th>
<th>
Assignments
</th>
</tr>
<tr>
<td>
Sept. 27

</td>
<td>
[[Operating Systems 2019F: Assignment 1|Assignment 1]]

</td>
</tr>
<tr>
<td>
Oct. 11

</td>
<td>
[[Operating Systems 2019F: Assignment 2|Assignment 2]]

</td>
</tr>
<tr>
<td>
Nov. 15

</td>
<td>
[[Operating Systems 2019F: Assignment 3|Assignment 3]]

</td>
</tr>
<tr>
<td>
Dec. 6

</td>
<td>
[[Operating Systems 2019F: Assignment 4|Assignment 4]]

</td>
</tr>
</table>

==Course Software==

In this course we will primarily working with [http://www.ubuntu.com/ Ubuntu], a widely-used family of Linux distributions. We will be using Ubuntu Server on the SCS's [http://openstack.scs.carleton.ca/ Openstack installation] (accessible only from the Carleton network).

You may use other Linux distributions to complete the assigned work; there will be differences, however, in some aspects (such as installing software), particularly if you use a distribution not based on Ubuntu or Debian.

===Openstack===

You should create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. Documentation on the cluster is [https://carleton.ca/scs/tech-support/scs-open-stack/ here]. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

Note that you must be on the Carleton network to use openstack. When you are off campus, connect using the [https://carleton.ca/its/help-centre/remote-access/ Carleton VPN].

Create a VM using the latest COMP 3000 snapshot image. Please create a machine with two VCPUs. The user is student, default password is student. Please change your password after you first connect to your machine (using the passwd command).

'''Make sure you connect via ssh.''' Windows 10 and MacOS have ssh clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM. PuTTY also works, and you can use x2go. DO NOT use the web console, as it is glitchy!

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type

scs-backup janedoe

and it will create a copy of everything in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files. You should do backups at the end of every session and before you do anything dangerous.

The scs-backup bash function is listed below. Feel free to adapt to your own needs; however, realize that rsync is a very powerful command that can delete arbitrary files at the specified destination (and in fact that is what the listed command does to the backup directory). If you are changing any arguments, be sure to test with the -n option so you can see what will happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed).'''

==Online Resources==

Other than [http://pages.cs.wisc.edu/~remzi/OSTEP/ the textbook], there are many, many other good online sources of information about operating systems. Here are a few that may be of interest:

* Jian Huang's [http://web.eecs.utk.edu/~huangj/cs360/lecture_notes.html Systems Programming notes]

==Tutorial Grading==

Each week you will get a progress grade from 0-4, given to you by a TA. If you are being diligent, you should be able to get 4's every week. The easiest way to get your grade is to come to tutorial and meet with your TA; alternately, you can meet a TA in their office hours or, at their discretion, discuss things with them online. Tutorials must be completed before the assignment on which they are based is due (if you wish to receive credit).

Tutorial grades will be given out as follows:
* 2: student attended the tutorial (50%)
* 3: student worked on most of the tutorial material (75%)
* 4: student is learning the material in a way that should lead to success on assignment and the exams (100%)

It should be easy to get a 3 if you show up and attempt the material. To get a 4, however, you need to be demonstrating that you are conducting experiments and actively engaging with the material in a way that is likely to lead to success.

It is possible to upgrade your grade on a tutorial at any time before the assignment on which they are based is due.

==How to Succeed and How to Fail in COMP 3000==

While the use of outside resources is acceptable, even encouraged, use them to achieve '''understanding''' rather than answers.

It is very possible to get full tutorial marks by doing little more than showing up, and assignments can be quickly finished (and you can even get most of the marks) by working with partners, looking at old assignments, and doing lots of online searches. If this is all you do, however, you will fail the tests and you won't get a very good grade in the course.

Successful students use the tutorials and assignments as learning opportunities. They look at the code and ask "what does that do?" - not just in a general sense, but by looking at every line and asking why it is there. They modify the code in order to better understand it, and when they are confused they ask questions until they get the answers they need. This sort of learning takes time, generally much more than the time allocated for lectures and tutorials. A tutorial is only "finished" when you understand essentially all the material in it - not when 80 minutes are up.

If you find you are confused about the concepts, make sure to read and review the textbook and the Linux man pages. They provide much deeper answers than most online resources. The tutorials are designed to help you ask the right questions - the textbook and manual pages (and the lectures) help provide the answers.

Take the tutorials seriously. Understand the answers for all the questions on the assignments. Use the textbook and manual pages. Ask questions.

Good luck!

Operating Systems (Fall 2019)

2019-09-24T23:37:46Z

Housedhorse: /* Tutorial Grading */

==Course Outline==

[[Operating Systems (Fall 2019) Course Outline|Here]] is the course outline for COMP 3000: Operating Systems.

==Lectures & Tests==

Note that the topics below are primarily chapters from the class textbook, [http://pages.cs.wisc.edu/~remzi/OSTEP/ Operating Systems: Three Easy Pieces]. Note that while introductory and summary dialogues are not linked below, they are worth reading for an informal take on the material.

Assigned readings are subject to change, please check this page each week.

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
</tr>
<tr>
<td>
Sept. 4

</td>
<td>
[[Operating Systems 2019F Lecture 1|Lecture 1]]: [http://pages.cs.wisc.edu/~remzi/OSTEP/intro.pdf Introduction]

</td>
</tr>
<tr>
<td>
Sept. 6

</td>
<td>
[[Operating Systems 2019F Lecture 2|Lecture 2]]: [http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-api.pdf Process API]

</td>
</tr>
<tr>
<td>
Sept. 11

</td>
<td>
[[Operating Systems 2019F Lecture 3|Lecture 3]]: [http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-intro.pdf Processes]

</td>
</tr>
<tr>
<td>
Sept. 13

</td>
<td>
[[Operating Systems 2019F Lecture 4|Lecture 4]]: [http://pages.cs.wisc.edu/~remzi/OSTEP/file-intro.pdf Files]

</td>
</tr>
<tr>
<td>
Sept. 18

</td>
<td>
[[Operating Systems 2019F Lecture 5|Lecture 5]]: [http://pages.cs.wisc.edu/~remzi/OSTEP/vm-intro.pdf Address Spaces] [http://pages.cs.wisc.edu/~remzi/OSTEP/dialogue-vm.pdf (Dialogue)]

</td>
</tr>
<tr>
<td>
Sept. 20

</td>
<td>
[[Operating Systems 2019F Lecture 6|Lecture 6]]

</td>
</tr>
<tr>
<td>
Sept. 25

</td>
<td>
[[Operating Systems 2019F Lecture 7|Lecture 7]]

</td>
</tr>
<tr>
<td>
Sept. 27

</td>
<td>
[[Operating Systems 2019F Lecture 8|Lecture 8]]

</td>
</tr>
<tr>
<td>
Oct. 2

</td>
<td>
[[Operating Systems 2019F Lecture 9|Lecture 9]]: [http://pages.cs.wisc.edu/~remzi/OSTEP/file-devices.pdf I/O Devices], [http://pages.cs.wisc.edu/~remzi/OSTEP/file-disks.pdf Hard disk drives], [http://pages.cs.wisc.edu/~remzi/OSTEP/file-implementation.pdf Filesystem implementation], [http://pages.cs.wisc.edu/~remzi/OSTEP/file-journaling.pdf FSCK and Journaling]

</td>
</tr>
<tr>
<td>
Oct. 4

</td>
<td>
[[Operating Systems 2019F Lecture 10|Lecture 10]]

</td>
</tr>
<tr>
<td>
Oct. 9

</td>
<td>
[[Operating Systems 2019F Lecture 11|Lecture 11]]

</td>
</tr>
<tr>
<td>
Oct. 11

</td>
<td>
[[Operating Systems 2019F Lecture 12|Lecture 12]]: Midterm Review

</td>
</tr>
<tr>
<td>
Oct. 16

</td>
<td>
Midterm Exam

</td>
</tr>
<tr>
<td>
Oct. 18

</td>
<td>
[[Operating Systems 2019F Lecture 13|Lecture 13]]

</td>
</tr>
<tr>
<td>
Oct. 30

</td>
<td>
[[Operating Systems 2019F Lecture 14|Lecture 14]]

</td>
</tr>
<tr>
<td>
Nov. 1

</td>
<td>
[[Operating Systems 2019F Lecture 15|Lecture 15]]

</td>
</tr>
<tr>
<td>
Nov. 6

</td>
<td>
[[Operating Systems 2019F Lecture 16|Lecture 16]]

</td>
</tr>
<tr>
<td>
Nov. 8

</td>
<td>
[[Operating Systems 2019F Lecture 17|Lecture 17]]

</td>
</tr>
<tr>
<td>
Nov. 13

</td>
<td>
[[Operating Systems 2019F Lecture 18|Lecture 18]]

</td>
</tr>
<tr>
<td>
Nov. 15

</td>
<td>
[[Operating Systems 2019F Lecture 19|Lecture 19]]

</td>
</tr>
<tr>
<td>
Nov. 20

</td>
<td>
[[Operating Systems 2019F Lecture 20|Lecture 20]]

</td>
</tr>
<tr>
<td>
Nov. 22

</td>
<td>
[[Operating Systems 2019F Lecture 21|Lecture 21]]

</td>
</tr>
<tr>
<td>
Nov. 27

</td>
<td>
[[Operating Systems 2019F Lecture 22|Lecture 22]]

</td>
</tr>
<tr>
<td>
Nov. 29

</td>
<td>
[[Operating Systems 2019F Lecture 23|Lecture 23]]

</td>
</tr>
<tr>
<td>
Dec. 4

</td>
<td>
[[Operating Systems 2019F Lecture 24|Lecture 24]]

</td>
</tr>
<tr>
<td>
TBD

</td>
<td>
Final Exam

</td>
</tr>
</table>

==Tutorials==

'''Note this has changed for Tutorials 3 and 4.'''

You may complete tutorials in lab or on your own. Submit your answers on culearn, they are due before the next week but are accepted with no grade penalty up until the related assignment is due. (For example, Tutorials 1 and 2 must be completed before Assignment 1 is submitted.)

Your answers will be graded based on participation, not understanding. Basically, if you make a reasonable attempt at the whole tutorial you'll get 4/4. Partial attempts will potentially be given partial credit; however, you may improve your tutorial mark as long as it is still being accepted. Exceptions will be made only if there are extenuating circumstances.

While you may collaborate with others and use outside resources, you should indicate the names of who you worked with and cite the sources you used.

The words you submit should be your own. Please don't copy-paste answers from others, because if you do, you are subject to being reported to the Dean for plagiarism.

Note that your assigned TA will be marking your work. You can find your TA by looking at the feedback portion of the "TA" grade item in cuLearn.

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Tutorials
</th>
</tr>
<tr>
<td>
Sept. 9-13

</td>
<td>
[[Operating Systems 2019F: Tutorial 1|Processes]]

</td>
</tr>
<tr>
<td>
Sept. 16-20

</td>
<td>
[[Operating Systems 2019F: Tutorial 2|3000shell]]

</td>
</tr>
<tr>
<td>
Sept. 23-27

</td>
<td>
[[Operating Systems 2019F: Tutorial 3|Memory & System Calls]]

</td>
</tr>
<tr>
<td>
Sept. 30-Oct. 4

</td>
<td>
[[Operating Systems 2019F: Tutorial 4|3000test]]

</td>
</tr>
<tr>
<td>
Oct. 28-Nov. 1

</td>
<td>
[[Operating Systems 2019F: Tutorial 5|TBD]]

</td>
</tr>
<tr>
<td>
Nov. 4-8

</td>
<td>
[[Operating Systems 2019F: Tutorial 6|TBD]]

</td>
</tr>
<tr>
<td>
Nov. 11-15

</td>
<td>
[[Operating Systems 2019F: Tutorial 7|TBD]]

</td>
</tr>
<tr>
<tr>
<td>
Nov. 18-22

</td>
<td>
[[Operating Systems 2019F: Tutorial 8|TBD]]

</td>
</tr>
<tr>
<td>
Nov. 25-29

</td>
<td>
[[Operating Systems 2019F: Tutorial 9|TBD]]

</td>
</tr>
</table>

==Assignments==

Assignments are due before class on the due dates (2:30 PM).

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Due Date
</th>
<th>
Assignments
</th>
</tr>
<tr>
<td>
Sept. 27

</td>
<td>
[[Operating Systems 2019F: Assignment 1|Assignment 1]]

</td>
</tr>
<tr>
<td>
Oct. 11

</td>
<td>
[[Operating Systems 2019F: Assignment 2|Assignment 2]]

</td>
</tr>
<tr>
<td>
Nov. 15

</td>
<td>
[[Operating Systems 2019F: Assignment 3|Assignment 3]]

</td>
</tr>
<tr>
<td>
Dec. 6

</td>
<td>
[[Operating Systems 2019F: Assignment 4|Assignment 4]]

</td>
</tr>
</table>

==Course Software==

In this course we will primarily working with [http://www.ubuntu.com/ Ubuntu], a widely-used family of Linux distributions. We will be using Ubuntu Server on the SCS's [http://openstack.scs.carleton.ca/ Openstack installation] (accessible only from the Carleton network).

You may use other Linux distributions to complete the assigned work; there will be differences, however, in some aspects (such as installing software), particularly if you use a distribution not based on Ubuntu or Debian.

===Openstack===

You should create a VM on the new SCS openstack cluster at [https://openstack-stein.scs.carleton.ca openstack-stein.scs.carleton.ca] and do your work there. Documentation on the cluster is [https://carleton.ca/scs/tech-support/scs-open-stack/ here]. While you don't need a persistent VM for this lab, it will be important for future tuturials - and it is nice to have your work stick around when you leave the lab.

Note that you must be on the Carleton network to use openstack. When you are off campus, connect using the [https://carleton.ca/its/help-centre/remote-access/ Carleton VPN].

Create a VM using the latest COMP 3000 snapshot image. Please create a machine with two VCPUs. The user is student, default password is student. Please change your password after you first connect to your machine (using the passwd command).

'''Make sure you connect via ssh.''' Windows 10 and MacOS have ssh clients available from their command lines, just type "ssh student@<IP address>" where the IP address is the floating IP address you assigned to your VM. PuTTY also works, and you can use x2go. DO NOT use the web console, as it is glitchy!

The image provides an "scs-backup" command that will backup the student user's directory to the SCS linux machines. So if your SCS username is janedoe, you can type

scs-backup janedoe

and it will create a copy of everything in the student account in a directory called "COMP3000VM-backup" in your home directory. You can ssh/sftp to access.scs.carleton.ca in order to access this copy of your VM's files. You should do backups at the end of every session and before you do anything dangerous.

The scs-backup bash function is listed below. Feel free to adapt to your own needs; however, realize that rsync is a very powerful command that can delete arbitrary files at the specified destination (and in fact that is what the listed command does to the backup directory). If you are changing any arguments, be sure to test with the -n option so you can see what will happen!

'''Note that you cannot take snapshots of your VM, so please don't try (it will keep trying and never succeed).'''

==Online Resources==

Other than [http://pages.cs.wisc.edu/~remzi/OSTEP/ the textbook], there are many, many other good online sources of information about operating systems. Here are a few that may be of interest:

* Jian Huang's [http://web.eecs.utk.edu/~huangj/cs360/lecture_notes.html Systems Programming notes]

==Tutorial Grading==

Each week you will get a progress grade from 0-4, given to you by a TA. If you are being diligent, you should be able to get 4's every week. The easiest way to get your grade is to come to tutorial and meet with your TA; alternately, you can meet a TA in their office hours or, at their discretion, discuss things with them online. Tutorials from before the Midterm must be completed by the Midterm, and Tutorials after the Midterm must be completed by the last day of classes (if you wish to receive credit).

Tutorial grades will be given out as follows:
* 2: student attended the tutorial (50%)
* 3: student worked on most of the tutorial material (75%)
* 4: student is learning the material in a way that should lead to success on assignment and the exams (100%)

It should be easy to get a 3 if you show up and attempt the material. To get a 4, however, you need to be demonstrating that you are conducting experiments and actively engaging with the material in a way that is likely to lead to success.

It is possible to upgrade your grade on a tutorial at any time before the assignment on which they are based is due.

==How to Succeed and How to Fail in COMP 3000==

While the use of outside resources is acceptable, even encouraged, use them to achieve '''understanding''' rather than answers.

It is very possible to get full tutorial marks by doing little more than showing up, and assignments can be quickly finished (and you can even get most of the marks) by working with partners, looking at old assignments, and doing lots of online searches. If this is all you do, however, you will fail the tests and you won't get a very good grade in the course.

Successful students use the tutorials and assignments as learning opportunities. They look at the code and ask "what does that do?" - not just in a general sense, but by looking at every line and asking why it is there. They modify the code in order to better understand it, and when they are confused they ask questions until they get the answers they need. This sort of learning takes time, generally much more than the time allocated for lectures and tutorials. A tutorial is only "finished" when you understand essentially all the material in it - not when 80 minutes are up.

If you find you are confused about the concepts, make sure to read and review the textbook and the Linux man pages. They provide much deeper answers than most online resources. The tutorials are designed to help you ask the right questions - the textbook and manual pages (and the lectures) help provide the answers.

Take the tutorials seriously. Understand the answers for all the questions on the assignments. Use the textbook and manual pages. Ask questions.

Good luck!

Operating Systems 2019F: Tutorial 1

2019-09-08T23:50:42Z

Housedhorse: /* Tasks/Questions */

'''This tutorial is not yet finalized.'''

In this tutorial you will be learning the basics of command-line interaction in Linux.

===Getting Started===

For this tutorial, you need to get access to a Linux or UNIX machine. We suggest you use one of the Virtualbox virtual machines already configured on the SCS lab machines. Alternately, you can use a Linux terminal on your own machine, running on your own virtual Linux box, or on one of the [https://carleton.ca/scs/technical-support/linux/ SCS Linux machines]. Starting (hopefully) next week we will begin working with SCS's openstack cluster.

The concepts covered below are mostly part of standard UNIX/Linux tutorials. Feel free to consult one or more of them. However, remember that you are trying to build a conceptual model of how things work. Thus, don't memorize commands; instead, try to understand how things fit together, and ask questions when things don't work as expected!

Feel free to discuss this tutorial on discord on the #tutorials channel.

==Background==

===The Shell===

The shell or command line provides a text interface for running programs. While not as visually pleasing as a graphical interface, the shell provides a more clear representation of the functionality provided by the operating system.

To run a program contained in the current directory in the shell, you need to prefix the name of the command with a <tt>./</tt>. This "./" tells the shell that the location of the command you wish to run is the current directory. By default, the shell will not search for executable commands in the current working directory. To run most system commands, the name of the command can be typed without a path specification.

===Help===

When working in the shell, help is available on most programs in the system, especially those that are command line based. This system of help is available by using the <tt>man</tt> (manual) command. If one wanted to get help on the echo command, the associated command would be <tt>man echo</tt>.

While you can find lots of documentation using web searches, note that it is very easy to find documentation that doesn't precisely match your system. Thus web searches should be a complement to rather than a substitute for man pages.

===Shell Basics===

Note that <tt>bash</tt> is the default shell on most Linux systems. Other UNIX-like systems can default to other shells like <tt>csh</tt> or <tt>tcsh</tt>; there are many alternatives such as <tt>zsh</tt> that you may prefer. When you change shells the syntax of the following operations can change; however, conceptually all UNIX-like shells provide the same basic functionality:
* run external programs with command-line arguments
* view and set environment variables
* redirect program input and output using I/O redirection and pipes.
* allow for the creation of scripts that combine external programs with built-in programming functionality.

===Processes===

Each application running on a system is assigned a unique process identifier. The <tt>ps</tt> command shows the process identifiers for running processes. Each process running on the system is kept separated from other processes by the operating system. This information will be useful for subsequent questions.

When you enter a command at a shell prompt, most of the time you are creating a new process which runs the program you specified.

===Permissions===

Your permission to access a file in Unix is determined by who you are logged in as. All files on the Unix file system (including directories and other special files) have three different sets of permissions. The first set of permissions denotes the allowed file operations for the owner of the file. The second set of permissions denotes the allowed file operations for a group of users. The third set of permissions denotes the allowed file operations for everyone else. A file is always owned by someone and is always associated with a group.

The <tt>ls</tt> command with the <tt>-l</tt> option can be used to show both the permissions of a file as well as the owner and group associated with the file. Permissions are listed first, followed by the owner and the group.

===Environment & Shell Variables===

Environment variables on both Linux and Windows are variable-value pairs that are shared between processes that define important context-related information (such as the name of the current user, the current language, the timezone) for applications. THe key advantage of environment variables is that they are available right when a program starts - they are given to it by the operating system.

In Linux, these environment variables can be printed on the command line in most shells by referring to the variable name prefixed with a $ sign (eg: to output the value in the HELLO environment variable, one could write <tt>echo $HELLO</tt>).

Most shells also have internal variables which are private to the shell process. Typically you can access shell and environment variables using the same mechanisms. By convention, shell variables are lower case or mixed case, while environment variables are all upper case. In bash, by default all variables are first shell variables. To make them environment variables, they must be "export"-ed. Thus

X="Important Data"

just defines X for the current bash process. However, if you then type

export X

X will be turned into an environment variable, and so every subsequent program will also get X. You can combine both in one line:

export X="Important Data"

This is the idiom for setting environment variables normally.

One thing to remember with the above is that spaces are used to separate arguments in bash and most other UNIX shells. Thus it is an error to type:

export X = "Important Data"

as you now are giving export three arguments, not one.

One of the key reasons people choose alternatives to bash is because of quirks like this!

===Dynamic Libraries===

Most applications on the system do not contain all the code that they need right within the executable. Instead, dynamic libraries are loaded into the program address space when the program loads. As an example, the standard C library, which contains such functions as <tt>printf</tt>, is loaded in at run-time. Typically dynamic libraries are stored in /lib or /usr/lib.

The dynamic libraries associated with a program binary can be found using the <tt>ldd</tt> command. You can use <tt>ltrace</tt> to see calls to functions that are dynamically linked.

===System Calls===

A process on its own has limited access to the system. It cannot directly access any external devices or data sources (e.g., files, keyboard, the screen, networks) on its own. To access these external resources, to allocate memory, or otherwise change its runtime environment, it must make '''system calls'''. Note that system calls run code outside of a process and thus cannot be called like regular function calls. The standard C library provides function wrappers for most commonly-used system calls so they can be accessed like regular C functions. Under the hood, however, these functions make use of special compiler directives in order to generate the machine code necessary to invoke system calls.

You can see the system calls produced by a process using the <tt>strace</tt> command.

===Cotrolling Processes===

On Linux, you can control processes by sending them signals. You send signals when you type certain key sequences in most shells: Control-C sends INT (interrupt), Control-Z sends STOP.

You can send a signal to a process using the kill command:

kill -<signal> <process ID>

So to stop process 4542, type

kill -STOP 4542

By default, kill sends the TERM signal.

===Downloading Code & Compiling Programs===

To download C programs to your VM, use <tt>wget</tt> or <tt>curl</tt> commands:

wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
curl https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c -o hello.c

To compile, use gcc:

gcc -O2 hello.c -o hello

This compiles it with level 2 optimization and without debugging symbols.

To run, you have to specify where it is:

./hello

Remember you can change directories using the <tt>cd</tt> command.

By default gcc-produced binaries are dynamically linked (so at runtime they will require dynamic libraries to be present on the system). To compile a binary that is statically linked (so it has no external runtime library dependencies), instead do this:

gcc -O2 -static hello.c -o hello

==Tasks/Questions==

# Look up the manual page for three shell commands discussed above or shown in lecture. What do you notice about the format of manual pages? What sections are they divided into? How detailed are they?
# By default, manual pages are displayed using <tt>less</tt>. How do you quit <tt>less</tt>? How can you search for specific terms?
# Using the <tt>which</tt> command, figure out where at least three commands reside on the system. Look at the permissions of those files. Who owns them? What group are they in?
# For those same program binaries, figure out what the permission bits mean by reading the man page of <tt>chmod</tt>. (This is the command you could use to change those permission bits.) What is the difference between "man chmod" and "man 2 chmod"?
# What are the owner, group, and permissions of /etc/passwd and /etc/shadow? What are these files used for?
# What does it mean to have execute permission on a directory?
# The <tt>ls</tt> command can be used to get a listing of the files in a directory. What options are passed to <tt>ls</tt> to see all of the files within a directory (including hidden files)? What files are hidden?
# The PATH environment variable lists the directories the shell uses to search for commands. Where can you find documentation on it? How can you add the current directory (whichever directory you are currently in) to PATH?
# Is <tt>cd</tt> a command that is built in to a shell, or is it an external binary? How do you know?
# Using <tt>ldd</tt>, what dynamic library dependencies does the <tt>top</tt> command have? Note that you must specify the full path to <tt>top</tt>.
# Run <tt>top</tt> in one window and try to terminate it using the <tt>kill</tt> command in another window. Try running "strace -fqo /tmp/top.log top" to get a record of the system calls that top is running. What happens to top when it receives those signals? What system call is used to send the signals?
# Download and compile [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c]. Compile them statically and dynamically. How do the library and system calls produced by them compare?
# Download, compile, and run [http://homeostasis.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c csimpleshell.c]. How does its functionality compare to that of <tt>bash</tt>?

==Code==

===hello.c===
<source lang="c">
#include <stdio.h>

int main(int argc, char *argv[]) {

printf("Hello world!\n");

return 0;
}
</source>

===syscall-hello.c===
<source lang="c">
#include <unistd.h>
#include <sys/syscall.h>

char *buf = "Hello world!\n";

int main(int argc, char *argv) {
size_t result;

/* "man 2 write" to see arguments to write syscall */
result = syscall(SYS_write, 1, buf, 13);

return (int) result;
}
</source>

===csimpleshell.c===
<source line lang="C">
/* csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html
"BSD" license

January 12, 2019: minor changes to eliminate most compilation warnings
(Anil Somayaji, soma@scs.carleton.ca)
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>
#include <sys/types.h>
#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp;
char *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if(strlen(buf_args[i])>0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

int main(int argc, char *argv[], char *envp[]){
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int ret_status;
size_t nargs;
pid_t pid;

while(1){
printf("$ ");
fgets(buffer, BUFFER_SIZE, stdin);
parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;
if (!strcmp(args[0], "exit" )) exit(0);
pid = fork();
if (pid){
printf("Waiting for child (%d)\n", pid);
pid = wait(&ret_status);
printf("Child (%d) finished\n", pid);
} else {
if( execvp(args[0], args)) {
puts(strerror(errno));
exit(127);
}
}
}
return 0;
}
</source>

Operating Systems 2019W: Tutorial 9

2019-04-03T11:41:57Z

Housedhorse: /* 3000log-write.c */

In this tutorial you'll attempt to exploit a simple TOCTTOU vulnerability in [https://homeostasis.scs.carleton.ca/~soma/os-2019w/code/3000log-write.c 3000log-write.c] using [https://homeostasis.scs.carleton.ca/~soma/os-2019w/code/3000fast-swap.c 3000fast-swap.c] and some bash shell commands.

==Tasks==

===Running 3000log-write===

First, compile [https://homeostasis.scs.carleton.ca/~soma/os-2019w/code/3000log-write.c 3000log-write.c]:
gcc -O2 3000log-write.c -o 3000log-write
If you try running it, you'll find that it won't do much because it isn't running as root.

To make the binary setuid root, do the following:
sudo su (to become root but stay in the same dir)
chown root:root 3000log-write
chmod u+s 3000log-write
exit (so you're no longer root)

Create a file that will be overwritten:
echo "This file will be overwritten" > testfile

Now, try running the following as a regular user:
./3000log-write testfile "Kilroy was here"

What shows up in <tt>testfile</tt>? Anything surprising about what is in the file now?

Also, where was the record of this event recorded?

===Setting up the exploit environment===

To try to exploit the race condition, we will have a victimfile that is owned by root and a safefile that is the "safe" file that will pass the permission checks (i.e., it is owned by the unprivileged user running the attack). Note for the following we assume you are user student. If you are running as a different user you'll need to change the hardcoded paths in 3000fast-swap.c.

Compile [https://homeostasis.scs.carleton.ca/~soma/os-2019w/code/3000fast-swap.c 3000fast-swap.c]:
gcc -O2 3000fast-swap.c -o 3000fast-swap

Make the directory for the attack:
mkdir /home/student/tmp

Create the safefile (owned by student):
echo "This is the safe file" > /home/student/tmp/safefile

Create the victimfile (owned by root):
sudo su
echo "This is the victim file" > /etc/victimfile
exit

===Running the exploit===

First, get 3000fast-swap running in the background:
3000fast-swap &

If you run <tt>top</tt> you should see it consuming significant resources.

Try viewing targetfile several times. You should see its contents changing between the victimfile and safefile.
Note that sometimes targetfile may not exist while other times it does.
for x in `seq 1 10`; do cat /home/student/tmp/targetfile; done

Now try running 3000log-write many times and see whether the victimfile has changed:
for x in `seq 1 10`; do ./3000log-write /home/student/tmp/targetfile payload; done
cat /etc/victimfile

Did victimfile change? If not, try running 3000log-write more times.

When you are done, be sure to kill off 3000fast-swap!

===Other Tasks & Questions===

* Add a timestamp to the log using <tt>ctime</tt> or equivalent.
* Vary the delays in the 3000fast-swap. Do shorter delays make it easier or harder to win the race? What about longer delays?
* Can you make 3000fast-swap use hard links instead of symbolic links? Why or why not?
* Does the attack work if you append rather than just write to the file?
* How does the system call profile of the system change when these attacks are run? Are there more system calls? More failed ones? What kind?
* Load your machine with heavy CPU and/or I/O bound tasks. Do these affect how quickly you can win the race?
* [HARD] Could 3000log-write.c tell that it had made a mistake and written to the wrong file?
* Modify 3000log-write.c so it drops privileges temporarily while doing the write using <tt>seteuid</tt>. Is the modified version vulnerable to the same attack?
* Do you think you could detect this attack by observing system call patterns? What about by observing patterns in the logs? (Could the attacker cover their tracks after they gained privileges?)

==Code==

===3000log-write.c===
<source lang="c" line>
/* 3000log-write.c

A program to demonstrate TOCTTOU issues

Usage: 3000log-write <file> <message>

When run, writes message to the file. It then also records a
record of this action to /var/log/comp3000-write.log

Note the program must be setuid root in order to add entries to
the log file (which is owned by root). But, it should only add entries
to files that the current user can write to.
*/

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

#define LOGFILE "/var/log/3000write.log"

void usage(char *message)
{
fprintf(stderr, "ERROR: %s\n", message);
fprintf(stderr, "Usage: log-append <file> <message>\n");
exit(-1);
}

void test_root_privileges(void)
{
if (geteuid() != 0) {
fprintf(stderr, "Not running with root privileges, exiting.\n");
exit(-1);
}
}

char *get_username(void)
{
char *username;
char *default_username = "UNKNOWN";

username = getenv("USER");

if (username == NULL) {
username = default_username;
}

return username;
}

void log_append(char *username, char *filename)
{
FILE *f;

f = fopen(LOGFILE, "a");
if (!f) {
fprintf(stderr, "Could not open log for writing.\n");
exit(-1);
}

fprintf(f, "%s (%d) appended to %s\n", username, getuid(), filename);
fclose(f);
}

void safe_write(char *filename, char *message)
{
int fd;
int allowed;

if (access(filename, W_OK)) {
fprintf(stderr, "You aren't allowed to write to %s\n",
filename);
exit(-1);
}

fd = open(filename, O_WRONLY);
if (fd == -1) {
fprintf(stderr, "Could not open %s for writing.\n", filename);
exit(-1);
}

write(fd, message, strlen(message));
close(fd);
}

int main(int argc, char *argv[])
{
char *username, *filename, *message;

test_root_privileges();

if (argc < 3) {
usage("Not enough arguments");
}

filename = argv[1];
message = argv[2];

username = get_username();

safe_write(filename, message);
log_append(username, filename);

printf("Message written to %s\n", filename);

return 0;
}
</source>

===3000fast-swap.c===
<source lang="c" line>
/* 3000fast-swap.c

Quickly swap files that are being used by 3000run-write.c.
This is part of how to exploit TOCTTOU (race condition)
vulnerability in 3000run-write.c

Note it assumes that:
/etc/victimfile is a file that is only writable by root
/home/student/tmp exists (and is owned by student)
/home/student/tmp/safefile exists (and is owned by student)

Change hard coded files and sleep times to change conditions of
the swapping.
*/

#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>

int main(int argc, char *argv[])
{
printf("Swapping between safefile and victimfile...\n");

while(1) {
unlink("/home/student/tmp/targetfile");
symlink("/etc/victimfile",
"/home/student/tmp/targetfile");
usleep(200);
unlink("/home/student/tmp/targetfile");
symlink("/home/student/tmp/safefile",
"/home/student/tmp/targetfile");
usleep(200);
}
return 0;
}
</source>

Operating Systems 2019W: Assignment 3

2019-03-13T00:16:38Z

Housedhorse: /* Questions */

<div style="background-color: cyan; border-style: dashed;padding-top: 10px;
padding-right: 20px;
padding-bottom: 10px;
padding-left: 20px;">
'''This assignment is not yet finalized''' but it is feature complete. Feel free to start working on it, but please check it again after it has been finalized for small changes.
</div>

Please submit the answers to the following questions via CULearn by 11:55 PM on Sunday, March 24, 2019. There are 20 points in 9 questions.

Submit your answers as a single text file named "<username>-comp3000-assign3.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Assignment 3", your name, student number, and the date of submission. You may wish to format your answers in Markdown to improve their appearance.

No other formats will be accepted. Submitting in another format will likely result in your assignment not being graded and you receiving no marks for this assignment. In particular do not submit an MS Word or OpenOffice file as your answers document!

Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.

'''Please make your best effort to do a proper implementation where required.''' There will be times where you may be tempted to copy large portions of code from other parts of the kernel. While you may have to copy a small number of lines, avoid duplicating significant functionality.

When an answer asks for modifications to the remember module, please give your code as a "diff -c" versus the original remember.c or versus the code for a previous answer. Points may be deducted for code in improper form. (Note that by using diff -c it is easily possible to automatically apply your changes to the original code in order to get a full working version.)

==Questions==

# [2] What are two reasons Linux kernel code doesn't make system calls?
# [2] What code could we use to get the information returned by getuid and geteuid system calls in the kernel? How do you know your code is correct?
# [2] When you unload a kernel module, can the kernel automatically deallocate the resources that were used by the module? Explain.
# [2] How could a userspace program prevent the remember module from being unloaded? Give code and explain why this code blocks the removal of the remember module.
# [2] What happens if you call class_create() in a module using a class name that already exists in the kernel? Describe the process by which you figured out your answer.
# [2] Fix the remember module so that it returns EFAULT to userspace when given an invalid pointer. Describe the process by which you figured out your answer.
# [2] In the remember module, modify remember_read() so it uses a non-zero offset properly rather than simply logging an error. Describe the process by which you figured out your answer.
# [2] Modify the remember module so llseek system calls work as they do on regular files. Describe the process by which you figured out your answer.
# [4] Modify the remember module so the behavior of writes change as follows:
#* [1] Increase the allocation size to 16K of storage.
#* [1] Allocate memory when data is first written to /dev/remember and free memory when zero bytes are written to /dev/remember or when the remember module is unloaded.
#* [1] Preserve data across writes such that a shorter write preserves data from a previous longer write.
#* [1] Allow writes to non-zero offsets (subject to the maximum size of /dev/remember).

Operating Systems 2019W: Assignment 1

2019-01-23T03:03:41Z

Housedhorse: /* Questions */

Please submit the answers to the following questions via CULearn by 4 PM on January 28, 2019. There are 20 points in 11 questions.

Submit your answers as a single text file named "<username>-comp3000-assign1.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Assignment 1", your name, student number, and the date of submission. You may wish to format your answers in Markdown to improve their appearance.

No other formats will be accepted. Submitting in another format will likely result in your assignment not being graded and you receiving no marks for this assignment. In particular do not submit an MS Word, OpenOffice, or PDF file as your answers document!

Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.

==Questions==
# [1] When you run a program from 3000shell, what does that program get for file descriptors 0, 1, and 2? Assume that you are running 3000shell in a standard terminal on Linux.
# [1] If line 293 from 3000shell.c is removed, <tt>pid = wait(ret_status);</tt>, how will the behavior of 3000shell change?
# [1] How would the behaviour of 3000shell change if lines 299 and 300 were removed?
# [1] What does the call to setup_comm_fn() in line 167 of 3000shell.c do?
# [2] Are system calls used to set signal handlers? Use output from <tt>strace</tt> to show your answer is correct.
# [2] Does find_env() generate any system calls? Use output from <tt>strace</tt> to show your answer is correct.
# [2] Give the assembly code corresponding to the allocation of pattern[] on line 63. Note that this allocation may be for multiple variables. How do you know your answer is correct?
# [2] How can <tt>execve</tt> overwrite all of a process's memory while also preserving its file descriptors? Specifically, does preserving file descriptors require execve to avoid erasing some process memory?
# [2] Is the SA_RESTART flag on a signal handler (e.g., line 243) interpreted by code running in the process or in the kernel? Give evidence for your answer.
# [3] Implement a "listfiles" command that lists the files in the current directory. Give the code for the listfiles() function and show how you'd change the rest of the code so that typing "listfiles" runs this function. Show your changes by using <tt>diff -c</tt>.
# [3] Implement an "input from file" feature to csimpleshell that works as follows. If you run <pre>$ bc infile=foo.bc</pre> then csimpleshell should have bc read the contents of foo.bc from standard input. You may assume that the "infile=" parameter is the last one (other than perhaps &). Show your changes from the standard csimpleshell.c using <tt>diff -c</tt>.

Operating Systems 2018F: Tutorial 8

2018-11-11T21:17:35Z

Housedhorse: /* Tasks */

'''This tutorial is not yet finalized.'''

In this tutorial you will be learning about [https://github.com/libfuse/libfuse filesystem in userspace (FUSE)] using an example from [https://github.com/terencehonles/fusepy fusepy]. You will also be tracing kernel-level behavior using [https://wkz.github.io/ply/ ply]. The exercises below have been tested in the class openstack VM. It should also work in the virtualbox VM (as long as you don't run out of disk space while installing/updating packages). It should also work on any ubuntu 18.04 installation. Other linux distributions are likely to work but there may be glitches.

==memoryll & fusell==

The memoryll script (which depends on fusell) creates an in-memory filesystem. You can store what you want in this filesystem and the data will be recorded in python data structures. When the script terminates all data is lost.

The memoryll and fusell example code are written in Python, not C. The code should be readable even if you are not familiar with Python. When you make changes, keep in mind the following:
* Indentation, not curly braces, is used to denote block structure. Thus indentation matters! Pay particular attention to spaces versus tabs. (When in doubt, don't use tabs.)
* To create a local variable, just assign to it. Python will make sure it is only defined within that function.
* If you just type "python" on the command line you get a read-eval-print loop where you can try things out.
* Python is heavily object oriented, so expect to use methods more than straight functions.

To get going, first download the [http://homeostasis.scs.carleton.ca/~soma/os-2014f/code/fuse.zip fuse example code] in a zip file. Unpack it and change into the directory in a terminal. You should see two files: fusell.py and memoryll.py (both listed below). We will be running and modifying memoryll.py. For it to work, however, fusell.py has to be in the same directory as memoryll.py.

Specifically, to get started run the following commands:
wget http://homeostasis.scs.carleton.ca/~soma/os-2014f/code/fuse.zip
unzip fuse.zip
cd fuse
mkdir mnt

Now to run the example program type:

python memoryll.py mnt

(You may get an error about /etc/fuse.conf is not readable; if so don't worry about it, this happens when the user is not in the fuse group.)

After you do this, a new filesystem will be mounted on mnt (in the current directory). '''NOTE: all files created in this directory disappear when the script is terminated!'''

To get the script to properly exit, run:

fusermount -u mnt

(This will unmount the filesystem.) Note that if any process is using files in the mounted filesystem, this command will fail.

To forcibly terminate the script, type Control-Z then type "kill %1" (kill first job).

If you terminate the script and re-run it, you may get errors. To fix them, do the following:
* Make sure no processes are using the mnt directory (e.g., being in that directory in another terminal window).
* sudo umount mnt (while in the fuse directory)
We suggest you leave the memoryll.py script running in one terminal window while doing the following exercises (using GUI programs or commands in another terminal window).

==ply==

[https://wkz.github.io/ply/ ply] is a tool for tracing and gathering stats on the currently running Linux kernel. We will be using it today to see what is happening on the kernel side when we use memoryll.

First, install the dependencies:

apt install build-essential autoconf flex bison git
apt clean

Next, download the source code:

wget https://homeostasis.scs.carleton.ca/~soma/os-2018f/code/tut8/ply-src.zip
unzip ply-src.zip

or

git clone https://github.com/iovisor/ply.git

Then, build and install:

cd ply
./autogen.sh
./configure
make
sudo make install

After this, you should have ply installed in /usr/local/sbin/.

For documentation, check out [https://wkz.github.io/ply/ply.1.html ply's man page] and [https://github.com/iovisor/ply/blob/master/README.md ply's README].

==Tasks==
# Make a few directories in mnt and populate it with several files. Do you see any errors? What messages does memoryll.py output while doing this?
# When you make files in mnt, are they normal files? Can they be accessed by regular programs?
# What permissions do you need to "mount" the filesystem? What about to "umount" it?
# What system calls are associated with which functions in memoryll.py? How close is the correspondence between system calls made and python function invocations? (Note that if you want to use strace you'll have to do everything as root.)
# Download [https://homeostasis.scs.carleton.ca/~soma/os-2018f/code/tut8/opensnoop.ply opensnoop.ply] and run it with the command "sudo ply opensnoop.ply". Cancel the script by entering Ctrl-C. What does this ply script output?
# Download [https://homeostasis.scs.carleton.ca/~soma/os-2018f/code/tut8/fusesnoop.ply fusesnoop.ply] and run it with the command "sudo ply fusesnoop.ply". What does this ply script output?
# Create a ply script to monitor other functions in the Linux kernel. Try looking at functions in [https://elixir.bootlin.com/linux/latest/source/fs/fuse fs/fuse] and general filesystem operations such as [https://elixir.bootlin.com/linux/latest/source/fs/read_write.c fs/read_write.c].
# Modify the code so that file renames don't delete the old file but instead just create a new name for it.
# Modify the code so that when read, files are converted to upper case.

==Code==

===opensnoop.ply===
<source lang="C" line>
#!/usr/bin/env ply

kprobe:do_sys_open
{
printf("%16s(%5d): %s\n", comm(), pid(), mem(arg(1), "128s"));
}
</source>

===fusesnoop.ply===
<source lang="C" line>
#!/usr/bin/env ply

kprobe:fuse_do_open
{
printf("%16s(%5d): %5d\n", comm(), pid(), arg(1));
}
</source>

===memoryll.py===

<source lang="python" line>
#!/usr/bin/env python

from collections import defaultdict
from errno import ENOENT, EROFS
from stat import S_IFMT, S_IMODE, S_IFDIR, S_IFREG
from sys import argv, exit
from time import time

from fusell import FUSELL

class Memory(FUSELL):
def create_ino(self):
self.ino += 1
return self.ino

def init(self, userdata, conn):
self.ino = 1
self.attr = defaultdict(dict)
self.data = defaultdict(str)
self.parent = {}
self.children = defaultdict(dict)

self.attr[1] = {'st_ino': 1, 'st_mode': S_IFDIR | 0777, 'st_nlink': 2}
self.parent[1] = 1

forget = None

def getattr(self, req, ino, fi):
print 'getattr:', ino
attr = self.attr[ino]
if attr:
self.reply_attr(req, attr, 1.0)
else:
self.reply_err(req, ENOENT)

def lookup(self, req, parent, name):
print 'lookup:', parent, name
children = self.children[parent]
ino = children.get(name, 0)
attr = self.attr[ino]

if attr:
entry = {'ino': ino, 'attr': attr, 'atttr_timeout': 1.0, 'entry_timeout': 1.0}
self.reply_entry(req, entry)
else:
self.reply_err(req, ENOENT)

def mkdir(self, req, parent, name, mode):
print 'mkdir:', parent, name
ino = self.create_ino()
ctx = self.req_ctx(req)
now = time()
attr = {
'st_ino': ino,
'st_mode': S_IFDIR | mode,
'st_nlink': 2,
'st_uid': ctx['uid'],
'st_gid': ctx['gid'],
'st_atime': now,
'st_mtime': now,
'st_ctime': now}

self.attr[ino] = attr
self.attr[parent]['st_nlink'] += 1
self.parent[ino] = parent
self.children[parent][name] = ino

entry = {'ino': ino, 'attr': attr, 'atttr_timeout': 1.0, 'entry_timeout': 1.0}
self.reply_entry(req, entry)

def mknod(self, req, parent, name, mode, rdev):
print 'mknod:', parent, name
ino = self.create_ino()
ctx = self.req_ctx(req)
now = time()
attr = {
'st_ino': ino,
'st_mode': mode,
'st_nlink': 1,
'st_uid': ctx['uid'],
'st_gid': ctx['gid'],
'st_rdev': rdev,
'st_atime': now,
'st_mtime': now,
'st_ctime': now}

self.attr[ino] = attr
self.attr[parent]['st_nlink'] += 1
self.children[parent][name] = ino

entry = {'ino': ino, 'attr': attr, 'atttr_timeout': 1.0, 'entry_timeout': 1.0}
self.reply_entry(req, entry)

def open(self, req, ino, fi):
print 'open:', ino
self.reply_open(req, fi)

def read(self, req, ino, size, off, fi):
print 'read:', ino, size, off
buf = self.data[ino][off:(off + size)]
self.reply_buf(req, buf)

def readdir(self, req, ino, size, off, fi):
print 'readdir:', ino
parent = self.parent[ino]
entries = [('.', {'st_ino': ino, 'st_mode': S_IFDIR}),
('..', {'st_ino': parent, 'st_mode': S_IFDIR})]
for name, child in self.children[ino].items():
entries.append((name, self.attr[child]))
self.reply_readdir(req, size, off, entries)

def rename(self, req, parent, name, newparent, newname):
print 'rename:', parent, name, newparent, newname
ino = self.children[parent].pop(name)
self.children[newparent][newname] = ino
self.parent[ino] = newparent
self.reply_err(req, 0)

def setattr(self, req, ino, attr, to_set, fi):
print 'setattr:', ino, to_set
a = self.attr[ino]
for key in to_set:
if key == 'st_mode':
# Keep the old file type bit fields
a['st_mode'] = S_IFMT(a['st_mode']) | S_IMODE(attr['st_mode'])
else:
a[key] = attr[key]
self.attr[ino] = a
self.reply_attr(req, a, 1.0)

def write(self, req, ino, buf, off, fi):
print 'write:', ino, off, len(buf)
self.data[ino] = self.data[ino][:off] + buf
self.attr[ino]['st_size'] = len(self.data[ino])
self.reply_write(req, len(buf))

if __name__ == '__main__':
if len(argv) != 2:
print 'usage: %s <mountpoint>' % argv[0]
exit(1)
fuse = Memory(argv[1])
</source>

===fusell.py===
<source lang="python">
# Copyright (c) 2010 Giorgos Verigakis <verigak@gmail.com>
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

from __future__ import division

from ctypes import *
from ctypes.util import find_library
from errno import *
from functools import partial, wraps
from inspect import getmembers, ismethod
from platform import machine, system
from stat import S_IFDIR, S_IFREG

_system = system()
_machine = machine()

class LibFUSE(CDLL):
def __init__(self):
if _system == 'Darwin':
self.libiconv = CDLL(find_library('iconv'), RTLD_GLOBAL)
super(LibFUSE, self).__init__(find_library('fuse'))

self.fuse_mount.argtypes = (c_char_p, POINTER(fuse_args))
self.fuse_mount.restype = c_void_p
self.fuse_lowlevel_new.argtypes = (POINTER(fuse_args), POINTER(fuse_lowlevel_ops),
c_size_t, c_void_p)
self.fuse_lowlevel_new.restype = c_void_p
self.fuse_set_signal_handlers.argtypes = (c_void_p,)
self.fuse_session_add_chan.argtypes = (c_void_p, c_void_p)
self.fuse_session_loop.argtypes = (c_void_p,)
self.fuse_remove_signal_handlers.argtypes = (c_void_p,)
self.fuse_session_remove_chan.argtypes = (c_void_p,)
self.fuse_session_destroy.argtypes = (c_void_p,)
self.fuse_unmount.argtypes = (c_char_p, c_void_p)

self.fuse_req_ctx.restype = POINTER(fuse_ctx)
self.fuse_req_ctx.argtypes = (fuse_req_t,)

self.fuse_reply_err.argtypes = (fuse_req_t, c_int)
self.fuse_reply_attr.argtypes = (fuse_req_t, c_void_p, c_double)
self.fuse_reply_entry.argtypes = (fuse_req_t, c_void_p)
self.fuse_reply_open.argtypes = (fuse_req_t, c_void_p)
self.fuse_reply_buf.argtypes = (fuse_req_t, c_char_p, c_size_t)
self.fuse_reply_write.argtypes = (fuse_req_t, c_size_t)

self.fuse_add_direntry.argtypes = (c_void_p, c_char_p, c_size_t, c_char_p,
c_stat_p, c_off_t)

class fuse_args(Structure):
_fields_ = [('argc', c_int), ('argv', POINTER(c_char_p)), ('allocated', c_int)]

class c_timespec(Structure):
_fields_ = [('tv_sec', c_long), ('tv_nsec', c_long)]

class c_stat(Structure):
pass # Platform dependent

if _system == 'Darwin':
ENOTSUP = 45
c_dev_t = c_int32
c_fsblkcnt_t = c_ulong
c_fsfilcnt_t = c_ulong
c_gid_t = c_uint32
c_mode_t = c_uint16
c_off_t = c_int64
c_pid_t = c_int32
c_uid_t = c_uint32
c_stat._fields_ = [
('st_dev', c_dev_t),
('st_ino', c_uint32),
('st_mode', c_mode_t),
('st_nlink', c_uint16),
('st_uid', c_uid_t),
('st_gid', c_gid_t),
('st_rdev', c_dev_t),
('st_atimespec', c_timespec),
('st_mtimespec', c_timespec),
('st_ctimespec', c_timespec),
('st_size', c_off_t),
('st_blocks', c_int64),
('st_blksize', c_int32)]
elif _system == 'Linux':
ENOTSUP = 95
c_dev_t = c_ulonglong
c_fsblkcnt_t = c_ulonglong
c_fsfilcnt_t = c_ulonglong
c_gid_t = c_uint
c_mode_t = c_uint
c_off_t = c_longlong
c_pid_t = c_int
c_uid_t = c_uint

if _machine == 'x86_64':
c_stat._fields_ = [
('st_dev', c_dev_t),
('st_ino', c_ulong),
('st_nlink', c_ulong),
('st_mode', c_mode_t),
('st_uid', c_uid_t),
('st_gid', c_gid_t),
('__pad0', c_int),
('st_rdev', c_dev_t),
('st_size', c_off_t),
('st_blksize', c_long),
('st_blocks', c_long),
('st_atimespec', c_timespec),
('st_mtimespec', c_timespec),
('st_ctimespec', c_timespec)]
elif _machine == 'ppc':
c_stat._fields_ = [
('st_dev', c_dev_t),
('st_ino', c_ulonglong),
('st_mode', c_mode_t),
('st_nlink', c_uint),
('st_uid', c_uid_t),
('st_gid', c_gid_t),
('st_rdev', c_dev_t),
('__pad2', c_ushort),
('st_size', c_off_t),
('st_blksize', c_long),
('st_blocks', c_longlong),
('st_atimespec', c_timespec),
('st_mtimespec', c_timespec),
('st_ctimespec', c_timespec)]
else:
# i686, use as fallback for everything else
c_stat._fields_ = [
('st_dev', c_dev_t),
('__pad1', c_ushort),
('__st_ino', c_ulong),
('st_mode', c_mode_t),
('st_nlink', c_uint),
('st_uid', c_uid_t),
('st_gid', c_gid_t),
('st_rdev', c_dev_t),
('__pad2', c_ushort),
('st_size', c_off_t),
('st_blksize', c_long),
('st_blocks', c_longlong),
('st_atimespec', c_timespec),
('st_mtimespec', c_timespec),
('st_ctimespec', c_timespec),
('st_ino', c_ulonglong)]
else:
raise NotImplementedError('%s is not supported.' % _system)

class c_statvfs(Structure):
_fields_ = [
('f_bsize', c_ulong),
('f_frsize', c_ulong),
('f_blocks', c_fsblkcnt_t),
('f_bfree', c_fsblkcnt_t),
('f_bavail', c_fsblkcnt_t),
('f_files', c_fsfilcnt_t),
('f_ffree', c_fsfilcnt_t),
('f_favail', c_fsfilcnt_t)]

class fuse_file_info(Structure):
_fields_ = [
('flags', c_int),
('fh_old', c_ulong),
('writepage', c_int),
('direct_io', c_uint, 1),
('keep_cache', c_uint, 1),
('flush', c_uint, 1),
('padding', c_uint, 29),
('fh', c_uint64),
('lock_owner', c_uint64)]

class fuse_ctx(Structure):
_fields_ = [('uid', c_uid_t), ('gid', c_gid_t), ('pid', c_pid_t)]

fuse_ino_t = c_ulong
fuse_req_t = c_void_p
c_stat_p = POINTER(c_stat)
fuse_file_info_p = POINTER(fuse_file_info)

FUSE_SET_ATTR = ('st_mode', 'st_uid', 'st_gid', 'st_size', 'st_atime', 'st_mtime')

class fuse_entry_param(Structure):
_fields_ = [
('ino', fuse_ino_t),
('generation', c_ulong),
('attr', c_stat),
('attr_timeout', c_double),
('entry_timeout', c_double)]

class fuse_lowlevel_ops(Structure):
_fields_ = [
('init', CFUNCTYPE(None, c_void_p, c_void_p)),
('destroy', CFUNCTYPE(None, c_void_p)),
('lookup', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_char_p)),
('forget', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_ulong)),
('getattr', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, fuse_file_info_p)),
('setattr', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_stat_p, c_int, fuse_file_info_p)),
('readlink', CFUNCTYPE(None, fuse_req_t, fuse_ino_t)),
('mknod', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_char_p, c_mode_t, c_dev_t)),
('mkdir', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_char_p, c_mode_t)),
('unlink', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_char_p)),
('rmdir', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_char_p)),
('symlink', CFUNCTYPE(None, fuse_req_t, c_char_p, fuse_ino_t, c_char_p)),
('rename', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_char_p, fuse_ino_t, c_char_p)),
('link', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, fuse_ino_t, c_char_p)),
('open', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, fuse_file_info_p)),
('read', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_size_t, c_off_t, fuse_file_info_p)),
('write', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_char_p, c_size_t, c_off_t,
fuse_file_info_p)),
('flush', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, fuse_file_info_p)),
('release', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, fuse_file_info_p)),
('fsync', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_int, fuse_file_info_p)),
('opendir', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, fuse_file_info_p)),
('readdir', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_size_t, c_off_t, fuse_file_info_p)),
('releasedir', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, fuse_file_info_p)),
('fsyncdir', CFUNCTYPE(None, fuse_req_t, fuse_ino_t, c_int, fuse_file_info_p))]

def struct_to_dict(p):
try:
x = p.contents
return dict((key, getattr(x, key)) for key, type in x._fields_)
except ValueError:
return {}

def stat_to_dict(p):
try:
d = {}
x = p.contents
for key, type in x._fields_:
if key in ('st_atimespec', 'st_mtimespec', 'st_ctimespec'):
ts = getattr(x, key)
key = key[:-4] # Lose the "spec"
d[key] = ts.tv_sec + ts.tv_nsec / 10 ** 9
else:
d[key] = getattr(x, key)
return d
except ValueError:
return {}

def dict_to_stat(d):
for key in ('st_atime', 'st_mtime', 'st_ctime'):
if key in d:
val = d[key]
sec = int(val)
nsec = int((val - sec) * 10 ** 9)
d[key + 'spec'] = c_timespec(sec, nsec)
return c_stat(**d)

def setattr_mask_to_list(mask):
return [FUSE_SET_ATTR[i] for i in range(len(FUSE_SET_ATTR)) if mask & (1 << i)]

class FUSELL(object):
def __init__(self, mountpoint):
self.libfuse = LibFUSE()

fuse_ops = fuse_lowlevel_ops()

for name, prototype in fuse_lowlevel_ops._fields_:
method = getattr(self, 'fuse_' + name, None) or getattr(self, name, None)
if method:
setattr(fuse_ops, name, prototype(method))

args = ['fuse']
argv = fuse_args(len(args), (c_char_p * len(args))(*args), 0)

# TODO: handle initialization errors

chan = self.libfuse.fuse_mount(mountpoint, argv)
assert chan

session = self.libfuse.fuse_lowlevel_new(argv, byref(fuse_ops), sizeof(fuse_ops), None)
assert session

err = self.libfuse.fuse_set_signal_handlers(session)
assert err == 0

self.libfuse.fuse_session_add_chan(session, chan)

err = self.libfuse.fuse_session_loop(session)
assert err == 0

err = self.libfuse.fuse_remove_signal_handlers(session)
assert err == 0

self.libfuse.fuse_session_remove_chan(chan)
self.libfuse.fuse_session_destroy(session)
self.libfuse.fuse_unmount(mountpoint, chan)

def reply_err(self, req, err):
return self.libfuse.fuse_reply_err(req, err)

def reply_none(self, req):
self.libfuse.fuse_reply_none(req)

def reply_entry(self, req, entry):
entry['attr'] = c_stat(**entry['attr'])
e = fuse_entry_param(**entry)
self.libfuse.fuse_reply_entry(req, byref(e))

def reply_create(self, req, *args):
pass # XXX

def reply_attr(self, req, attr, attr_timeout):
st = dict_to_stat(attr)
return self.libfuse.fuse_reply_attr(req, byref(st), c_double(attr_timeout))

def reply_readlink(self, req, *args):
pass # XXX

def reply_open(self, req, d):
fi = fuse_file_info(**d)
return self.libfuse.fuse_reply_open(req, byref(fi))

def reply_write(self, req, count):
return self.libfuse.fuse_reply_write(req, count)

def reply_buf(self, req, buf):
return self.libfuse.fuse_reply_buf(req, buf, len(buf))

def reply_readdir(self, req, size, off, entries):
bufsize = 0
sized_entries = []
for name, attr in entries:
entsize = self.libfuse.fuse_add_direntry(req, None, 0, name, None, 0)
sized_entries.append((name, attr, entsize))
bufsize += entsize

next = 0
buf = create_string_buffer(bufsize)
for name, attr, entsize in sized_entries:
entbuf = cast(addressof(buf) + next, c_char_p)
st = c_stat(**attr)
next += entsize
self.libfuse.fuse_add_direntry(req, entbuf, entsize, name, byref(st), next)

if off < bufsize:
buf = cast(addressof(buf) + off, c_char_p) if off else buf
return self.libfuse.fuse_reply_buf(req, buf, min(bufsize - off, size))
else:
return self.libfuse.fuse_reply_buf(req, None, 0)

# If you override the following methods you should reply directly
# with the self.libfuse.fuse_reply_* methods.

def fuse_getattr(self, req, ino, fi):
self.getattr(req, ino, struct_to_dict(fi))

def fuse_setattr(self, req, ino, attr, to_set, fi):
attr_dict = stat_to_dict(attr)
to_set_list = setattr_mask_to_list(to_set)
fi_dict = struct_to_dict(fi)
self.setattr(req, ino, attr_dict, to_set_list, fi_dict)

def fuse_open(self, req, ino, fi):
self.open(req, ino, struct_to_dict(fi))

def fuse_read(self, req, ino, size, off, fi):
self.read(req, ino, size, off, fi)

def fuse_write(self, req, ino, buf, size, off, fi):
buf_str = string_at(buf, size)
fi_dict = struct_to_dict(fi)
self.write(req, ino, buf_str, off, fi_dict)

def fuse_flush(self, req, ino, fi):
self.flush(req, ino, struct_to_dict(fi))

def fuse_release(self, req, ino, fi):
self.release(req, ino, struct_to_dict(fi))

def fuse_fsync(self, req, ino, datasync, fi):
self.fsyncdir(req, ino, datasync, struct_to_dict(fi))

def fuse_opendir(self, req, ino, fi):
self.opendir(req, ino, struct_to_dict(fi))

def fuse_readdir(self, req, ino, size, off, fi):
self.readdir(req, ino, size, off, struct_to_dict(fi))

def fuse_releasedir(self, req, ino, fi):
self.releasedir(req, ino, struct_to_dict(fi))

def fuse_fsyncdir(self, req, ino, datasync, fi):
self.fsyncdir(req, ino, datasync, struct_to_dict(fi))

# Utility methods

def req_ctx(self, req):
ctx = self.libfuse.fuse_req_ctx(req)
return struct_to_dict(ctx)

# Methods to be overridden in subclasses.
# Reply with the self.reply_* methods.

def init(self, userdata, conn):
"""Initialize filesystem

There's no reply to this method
"""
pass

def destroy(self, userdata):
"""Clean up filesystem

There's no reply to this method
"""
pass

def lookup(self, req, parent, name):
"""Look up a directory entry by name and get its attributes.

Valid replies:
reply_entry
reply_err
"""
self.reply_err(req, ENOENT)

def forget(self, req, ino, nlookup):
"""Forget about an inode

Valid replies:
reply_none
"""
self.reply_none(req)

def getattr(self, req, ino, fi):
"""Get file attributes

Valid replies:
reply_attr
reply_err
"""
if ino == 1:
attr = {'st_ino': 1, 'st_mode': S_IFDIR | 0755, 'st_nlink': 2}
self.reply_attr(req, attr, 1.0)
else:
self.reply_err(req, ENOENT)

def setattr(self, req, ino, attr, to_set, fi):
"""Set file attributes

Valid replies:
reply_attr
reply_err
"""
self.reply_err(req, EROFS)

def readlink(self, req, ino):
"""Read symbolic link

Valid replies:
reply_readlink
reply_err
"""
self.reply_err(req, ENOENT)

def mknod(self, req, parent, name, mode, rdev):
"""Create file node

Valid replies:
reply_entry
reply_err
"""
self.reply_err(req, EROFS)

def mkdir(self, req, parent, name, mode):
"""Create a directory

Valid replies:
reply_entry
reply_err
"""
self.reply_err(req, EROFS)

def unlink(self, req, parent, name):
"""Remove a file

Valid replies:
reply_err
"""
self.reply_err(req, EROFS)

def rmdir(self, req, parent, name):
"""Remove a directory

Valid replies:
reply_err
"""
self.reply_err(req, EROFS)

def symlink(self, req, link, parent, name):
"""Create a symbolic link

Valid replies:
reply_entry
reply_err
"""
self.reply_err(req, EROFS)

def rename(self, req, parent, name, newparent, newname):
"""Rename a file

Valid replies:
reply_err
"""
self.reply_err(req, EROFS)

def link(self, req, ino, newparent, newname):
"""Create a hard link

Valid replies:
reply_entry
reply_err
"""
self.reply_err(req, EROFS)

def open(self, req, ino, fi):
"""Open a file

Valid replies:
reply_open
reply_err
"""
self.reply_open(req, fi)

def read(self, req, ino, size, off, fi):
"""Read data

Valid replies:
reply_buf
reply_err
"""
self.reply_err(req, EIO)

def write(self, req, ino, buf, off, fi):
"""Write data

Valid replies:
reply_write
reply_err
"""
self.reply_err(req, EROFS)

def flush(self, req, ino, fi):
"""Flush method

Valid replies:
reply_err
"""
self.reply_err(req, 0)

def release(self, req, ino, fi):
"""Release an open file

Valid replies:
reply_err
"""
self.reply_err(req, 0)

def fsync(self, req, ino, datasync, fi):
"""Synchronize file contents

Valid replies:
reply_err
"""
self.reply_err(req, 0)

def opendir(self, req, ino, fi):
"""Open a directory

Valid replies:
reply_open
reply_err
"""
self.reply_open(req, fi)

def readdir(self, req, ino, size, off, fi):
"""Read directory

Valid replies:
reply_readdir
reply_err
"""
if ino == 1:
attr = {'st_ino': 1, 'st_mode': S_IFDIR}
entries = [('.', attr), ('..', attr)]
self.reply_readdir(req, size, off, entries)
else:
self.reply_err(req, ENOENT)

def releasedir(self, req, ino, fi):
"""Release an open directory

Valid replies:
reply_err
"""
self.reply_err(req, 0)

def fsyncdir(self, req, ino, datasync, fi):
"""Synchronize directory contents

Valid replies:
reply_err
"""
self.reply_err(req, 0)
</source>

Operating Systems 2018F: Tutorial 7

2018-11-05T20:52:04Z

Housedhorse: /* Tasks/Questions */

Again in this tutorial you will be building and installing kernel modules. You will need root access to install kernel modules.

It is '''highly recommended''' that you use a comp3000 openstack instance for the exercises below for two reasons. First, you may have difficulties compiling kernel modules on other systems. Second, these operations are potentially dangerous and mistakes could '''destroy all data''' on the Linux system. Consider yourself warned!

In this tutorial you'll be playing with the remember kernel module. This module creates a device /dev/remember. You can write data to this device and when you read from it, it will return the data that you most recently wrote.

==Getting started==

First, make sure your system is ready to build things. On ubuntu:

sudo apt install build-essential libelf-dev
sudo apt clean

Note that libelf-dev is a new addition. (To update your system, run "sudo apt update; sudo apt dist-upgrade")

Download and unzip [https://homeostasis.scs.carleton.ca/~soma/os-2018f/code/tut7/remember.zip remember.zip]. From the command line:

wget https://homeostasis.scs.carleton.ca/~soma/os-2018f/code/tut7/remember.zip
unzip remember.zip

Next, build the module and install it:

cd remember
make
sudo insmod remember.ko

And then test the module:

echo "Hello world" > /dev/remember
cat /dev/remember

Be sure to check the kernel logs before and after. You may even want to follow the logs as you play with the module. To do this, run:

tail -f /var/log/kern.log

You'll want to do this in a separate window.

==Tasks/Questions==

A good resource is [https://learnlinuxconcepts.blogspot.com/2014/02/linux-memory-management.html this page] on Linux kernel memory management.

# What can you do with the Makefile other than type "make"?
# How much data can you write to /dev/remember? What determines the limit? (Hint: try writing the contents of remember.c to /dev/remember)
# When is data being allocated? When is it deallocated?
# How can you increase the amount of data that /dev/remember stores? (Hint: what is saved_data_order for?)
# Does the kernel use virtual or physical addresses for its own data structures?
# How are we copying data to and from kernel space? Is it the same way we did before?
# What was changed from newgetpid.c that allows the /dev/remember device to be written to? What parts of the code had to be changed? What had to be added?

==Code==

===remember.c===

<source lang="c" line>
/*
remember.c

remember module COMP 3000, Carleton University
remembers what is written to it, returns in when read along with
info about how it is stored

License: GPLv2 or later
Author: Anil Somayaji
November 3, 2018

device driver and module code derived from:
https://appusajeev.wordpress.com/2011/06/18/writing-a-linux-character-device-driver/
and
http://pete.akeo.ie/2011/08/writing-linux-device-driver-for-kernels.html
*/

#include <linux/module.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/device.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/uaccess.h>
#include <linux/mm.h>

#define DEVICE_NAME "remember"
#define CLASS_NAME "comp3000"

static struct class* remember_class = NULL;
static struct device* remember_device = NULL;
static int remember_major;

static struct page *saved_data_page = NULL;
static char *saved_data = NULL;
static unsigned long saved_data_len = 0;
static int saved_data_max = PAGE_SIZE;
static int saved_data_order = 0;

static int remember_open(struct inode *the_inode, struct file *f)
{
pr_info("Remember: device opened\n");
return 0;
}

static ssize_t remember_read(struct file *f, char *buf, size_t len, loff_t *offset)
{
unsigned long n;
char *error_msg = "Buffer too small.";

pr_info("Remember: read started\n");

if (*offset > 0) {
pr_info("Remember: read non-zero offset, aborting\n");
return 0;
}

if (len < saved_data_len) {
pr_info("Remember: read short buffer\n");
n = strlen(error_msg) + 1; // Include terminating null byte
if (n > len) {
n = len;
}
copy_to_user(buf, error_msg, n);

return n;
} else {
pr_info("Remember: read returning data, %ld bytes\n",
saved_data_len);
copy_to_user(buf, saved_data, saved_data_len);
*offset = saved_data_len;

return saved_data_len;
}
}

void init_saved_data(void)
{
pr_info("Remember: allocating data page");

if (saved_data) {
pr_err("Remember: saved_data already initialized!");
} else {
saved_data_page = alloc_pages(GFP_KERNEL,
saved_data_order);
saved_data = (char *) page_address(saved_data_page);
saved_data_len = 0;

pr_info("saved_data at kernel virtual address %lx",
(unsigned long) saved_data);
pr_info("saved_data_page page struct at address %lx",
(unsigned long) saved_data_page);
}
}

void free_saved_data(void)
{
if (saved_data_page) {
pr_info("Remember: freeing old data page");
__free_pages(saved_data_page, saved_data_order);
saved_data_page = NULL;
saved_data = NULL;
saved_data_len = 0;
}
}

static ssize_t remember_write(struct file *f, const char *buf, size_t len,
loff_t *offset)
{
unsigned long result;

if (*offset > 0) {
pr_info("Remember: write nonzero offset, aborting");

return 0;
}

free_saved_data();
init_saved_data();

if (len > saved_data_max) {
len = saved_data_max;
}

pr_info("Remember: write saving data, %ld bytes", len);

result = copy_from_user(saved_data, buf, len);
saved_data_len = len;

*offset = len;

return len;
}

static int remember_release(struct inode *the_inode, struct file *f)
{
pr_info("Remember: device closed\n");
return 0;
}

static struct file_operations remember_fops = {
.open = remember_open,
.read = remember_read,
.write = remember_write,
.release = remember_release,
};

static char *remember_devnode(struct device *dev, umode_t *mode)
{
if (mode)
*mode = 0666;
return NULL;
}

static int __init remember_init(void)
{
int retval;

remember_major = register_chrdev(0, DEVICE_NAME, &remember_fops);
if (remember_major < 0) {
pr_err("failed to register device: error %d\n", remember_major);
retval = remember_major;
goto failed_chrdevreg;
}

remember_class = class_create(THIS_MODULE, CLASS_NAME);
if (IS_ERR(remember_class)) {
pr_err("Remember: failed to register device class '%s'\n",
CLASS_NAME);
retval = PTR_ERR(remember_class);
goto failed_classreg;
}

remember_class->devnode = remember_devnode;

remember_device = device_create(remember_class, NULL,
MKDEV(remember_major, 0),
NULL, DEVICE_NAME);

if (IS_ERR(remember_device)) {
pr_err("Remember: failed to create device '%s'\n", DEVICE_NAME);
retval = PTR_ERR(remember_device);
goto failed_devreg;
}

pr_info("Remember: device registered using major %d.\n",
remember_major);

return 0;

failed_devreg:
class_unregister(remember_class);
class_destroy(remember_class);
failed_classreg:
unregister_chrdev(remember_major, DEVICE_NAME);
failed_chrdevreg:
return -1;
}

static void __exit remember_exit(void)
{
free_saved_data();

device_destroy(remember_class, MKDEV(remember_major, 0));
class_unregister(remember_class);
class_destroy(remember_class);
unregister_chrdev(remember_major, "remember");
pr_info("Unloading Remember module.\n");
return;
}

module_init(remember_init);
module_exit(remember_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Anil Somayaji <soma@scs.carleton.ca>");
MODULE_DESCRIPTION("A remember character device module");
</source>

===Makefile===

Note that the large spaces below should be tabs.

<source lang="make" line>
MODNAME := remember
obj-m := $(MODNAME).o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

clean:
/bin/rm -f *.o *.ko *~
/bin/rm -f Module.symvers modules.order Modules.symvers *.mod.c
/bin/rm -f .*o.cmd .cache.mk
/bin/rm -rf .tmp_versions

zip:
rm -f $(MODNAME).zip
mkdir $(MODNAME)
cp -a Makefile $(MODNAME).c $(MODNAME)
zip -r $(MODNAME).zip $(MODNAME)
rm -rf $(MODNAME)
</source>

Operating Systems 2018F: Tutorial 6

2018-10-28T19:42:09Z

Housedhorse: /* Creating, Mounting, and Unmounting Filesystem */

In this tutorial you will be playing with filesystems (regular filesystems and sshfs). Please use a VM and make backups, as some of these commands could erase all data on your system.

==Creating, Mounting, and Unmounting Filesystem==

# Run <tt>ls -lai</tt> (by itself or for a specific directory). What are the numbers appearing in the left column?
# Run dd if=/dev/zero of=foo bs=8192 count=32K What is the logical size of the file? How much space does it consume on disk? (Hint: Look at the size option to ls.)
# Run <tt>mkfs.ext4 foo</tt>. (If asked, say "yes" to operating on a regular file.) Does foo consume any more space?
# Run <tt>dumpe2fs foo</tt>. What does the output of this command mean?
# What command do you run to check the filesystem in foo for errors?
# Run <tt>sudo mount foo /mnt</tt>. How does this command change what files are accessible?
# Run <tt>df</tt>. What device is mounted on /mnt? What is this device?
# Run <tt>rsync -a -v /etc /mnt</tt>. What does this command do? Explain the arguments as well.
# Run <tt>sudo umount /mnt</tt>. What files can you still access, and what have gone away?
# Run <tt>dd if=/dev/zero of=foo conv=notrunc count=10 bs=512</tt>. How does the "conv=notrunc" change dd's behavior (versus the command in question 1)?
# Run <tt>sudo mount foo /mnt</tt>. What error do you get?
# What command can you run to make foo mountable again? What characteristic of the file system enables this command to work?
# Run the command <tt>truncate -s 1G bar</tt>. What is the logical size of bar, and how much space does it consume on disk? How does this compare with foo?
# How does the logical size of bar change when you create an ext4 filesystem in it? What about the space consumed on disk?

==SSH & SSHFS==

Here you will be learning about [http://www.openssh.org ssh (openssh)] and [https://github.com/libfuse/sshfs sshfs], a network filesystem built on [https://github.com/libfuse/libfuse FUSE].

===Setup===

Install the openssh-server and sshfs packages:

sudo apt-get install openssh-server sshfs

Create a second user in the virtual machine named "other" (or any other name you wish to use):

sudo adduser other

(Answer the subsequent prompts however you wish, just remember the password.)

At this point you should be able to log in to the "other" account using ssh:

ssh other@localhost

You'll have to enter your password.

If you don't get a password prompt, password authentication has probably been disabled. (Password authentication has been disabled on the openstack VMs.) To enable it, do the following

sudo nano /etc/ssh/sshd_config (or vi, or emacs)

In the editor change the line "PasswordAuthentication no" to "PasswordAuthentication yes". Then, to restart sshd:

sudo service sshd restart

Be sure to change it back after you've set up public key authentication!

===Remote filesystems using sshfs===

To mount the other user's files in a directory called "otherfiles", do the following (as user student, ubuntu, or your personal account):

mkdir otherfiles
sshfs other@localhost: otherfiles

To unmount the filesystem:

fusermount -u otherfiles

===Public key authentication and ssh===

Create a public key file for your account (as user student, ubuntu, or your personal account):

ssh-keygen

(Accept the default filename and choose at least a simple passphrase.)

You just created a certificate! (A certificate is just a public key with metadata.)

Copy the key to the other account:

cat ~/.ssh/id_rsa.pub >> authorized_keys
scp authorized_keys other@localhost:.
rm authorized_keys
ssh other@localhost

(as user other)
mkdir ~/.ssh (if it doesn't exist already)
chmod 700 ~/.ssh (make it private)
mv ~/authorized_keys ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Now you can log in to user other by typing in the passphrase you used to lock the key you generated.

To avoid entering this passphrase every time, you can give it to the authentication agent (generally, ssh-agent) that was started when you logged in:

ssh-add

Note I expect the above to be a bit confusing. Do look around for resources on public key cryptography; however, you may find that playing around with ssh authentication may help you understand things better. In particular, try using "-v" (verbose) with ssh.

===Tasks===

# Look at the hard link counts of files locally and compare those to the link counts over sshfs. How do they compare?
# Can you access sshfs mounted files as root? (You can become root by typing "sudo su -".) What happens?
# Look at inode numbers in local and remote filesystems (as reported by ls -i). How do they compare?
# dd a large file to a local drive. Do same thing over sshfs. Which is faster? (What is a large file in this context?)
# Can you sshfs to the SCS systems (e.g., access.scs.carleton.ca)?
# Setup password-less login to the SCS system (and then undo it).
# How can you use the mount command to unmount a sshfs-mounted filesystem (rather than fusermount)?

Operating Systems 2018F: Tutorial 5

2018-10-15T14:34:55Z

Housedhorse: /* A simple kernel module */

In this tutorial you will be building and installing kernel modules. You will need root access to install kernel modules.

It is '''highly recommended''' that you use a comp3000 openstack instance for the exercises below for two reasons. First, you may have difficulties compiling kernel modules on other systems. Second, these operations are potentially dangerous and mistakes could '''destroy all data''' on the Linux system. Consider yourself warned!

See [[Operating Systems 2018F Lecture 8|Lecture 8]] for a walkthrough of setting up an openstack instance. Key steps:
* Login at [https://openstack.scs.carleton.ca openstack.scs.carleton.ca] (you need to be connected to the Carleton network, either directly or via VPN).
* If you can't log in, change your SCS password (this updates your openstack credentials).
* Create an instance, making sure to assign it a globally routable visible IP address (rather than a private 192.168.X.X address).
* Connect to your instance via ssh or x2go.

This is the first tutorial where you are seeing kernel code. By the end of tutorial you should be able to run all of the code here and be able to make trivial modifications. Lectures later this week will go through this code in detail. Learning as much as you can about the code now will help you prepare for the upcoming lectures. In particular, try to figure out what is different about this code.

To answer the questions on newgetpid.c, you'll need to refer to the [https://elixir.bootlin.com/linux/latest/source Linux kernel source], particularly [https://elixir.bootlin.com/linux/latest/source/kernel/sys.c kernel/sys.c]. (These are links to a cross-referenced version of the Linux kernel source, a key resource for understanding and developing kernel code.)

=Tasks=

==A simple kernel module==

# Download the source for [http://homeostasis.scs.carleton.ca/~soma/os-2015f/code/simple.zip this simple module], unpack, and build it by typing "make". Use <code>wget</code> to download the zip file.
# Install the module using "sudo insmod simple.ko". The hello message is recorded in the kernel logs. How do you view the kernel logs?
# Check to see that the module has been loaded. How do you do this?
# Remove the module from the kernel. What did you do?

==A character device kernel module==

# Download the source for [http://homeostasis.scs.carleton.ca/~soma/os-2015f/code/ones.zip ones], a kernel module implementing a character device that ouputs an unbounded string of "1"'s. Build, compile, and run it as before.
# What kernel messages does the module generate? Does it create any new files (other than /dev/ones)? If so, where?
# What happens when you "cat" the device /dev/ones? How can you limit the output?
# How can you modify your module to generate a kernel "Oops" as reported in the kernel logs or outright crash the kernel?

==Listing processes from a module==

# Download the source [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/lec16/newgetpid.zip newgetpid.c]. Build and run it as before.
# What type is "current"? How can you figure this out?
# Modify newgetpid.c so that it creates a device file /dev/describe rather than /dev/newgetpid.
# Make /dev/describe output the calling process's parent ID (ppid), user ID (uid), group ID (gid), effective user ID (euid), and effective group ID (egid).
# '''(Advanced)''' Modify /dev/describe so that if you write a process ID to it, it will output the information on the provided process. To make this work, you'll need to:
#* Add a write method by adding a write operation to the file operations struct. Write operations have the same prototype as read operations, except the buffer is marked constant (because it shouldn't be modified).
#* Convert the written text to an integer and store in a global variable (to the module).
#* Find the right task struct. See the implementation of the [http://elixir.free-electrons.com/linux/v4.4.83/source/kernel/signal.c#L2855 kill system call], and how it [http://elixir.free-electrons.com/linux/v4.4.83/source/kernel/signal.c#L1388 looks up the pid struct] and then [http://elixir.free-electrons.com/linux/v4.4.83/source/kernel/signal.c#L1303 gets the right task struct using that pid struct].
#* After returning info on the selected process, further calls should return info on the current process. You can do this by setting the global process ID to 0 and checking this value, using the current task if it is zero.

=Code=

==Simple module==

===simple.c===

<source lang="c">
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>

static int __init simple_init(void)
{
printk ("Hello kernel world!\n");
return 0;
}

static void __exit simple_exit(void)
{
printk ("Goodbye kernel world.\n");
return;
}

module_init(simple_init);
module_exit(simple_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Anil Somayaji <soma@scs.carleton.ca>");
MODULE_DESCRIPTION("A simple module");
</source>

===Makefile===

<source lang="make">
obj-m := simple.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
</source>

==Ones module==

===ones.c===
<source lang="c">
/* Code derived from:
https://appusajeev.wordpress.com/2011/06/18/writing-a-linux-character-device-driver/
and
http://pete.akeo.ie/2011/08/writing-linux-device-driver-for-kernels.html
*/

#include <linux/module.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/device.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <asm/uaccess.h>

#define dbg(format, arg...) do { if (debug) pr_info(CLASS_NAME ": %s: " format, __FUNCTION__, ## arg); } while (0)
#define err(format, arg...) pr_err(CLASS_NAME ": " format, ## arg)
#define info(format, arg...) pr_info(CLASS_NAME ": " format, ## arg)
#define warn(format, arg...) pr_warn(CLASS_NAME ": " format, ## arg)

#define DEVICE_NAME "ones"
#define CLASS_NAME "comp3000"

static struct class* ones_class = NULL;
static struct device* ones_device = NULL;
static int ones_major;

static int ones_open(struct inode *the_inode, struct file *f)
{
return 0;
}

static ssize_t ones_read(struct file *f, char *buf, size_t len, loff_t *offset)
{
size_t i;

for (i = 0; i < len; i++) {
put_user('1', buf++);
}

return i;
}

static int ones_release(struct inode *the_inode, struct file *f)
{
printk(KERN_ALERT "Ones device closed\n");
return 0;
}

static struct file_operations ones_fops = {
.open = ones_open,
.read = ones_read,
.release = ones_release,
};

static char *ones_devnode(struct device *dev, umode_t *mode)
{
if (mode)
*mode = 0444;
return NULL;
}

static int __init ones_init(void)
{
int retval;

ones_major = register_chrdev(0, DEVICE_NAME, &ones_fops);
if (ones_major < 0) {
err("failed to register device: error %d\n", ones_major);
retval = ones_major;
goto failed_chrdevreg;
}

ones_class = class_create(THIS_MODULE, CLASS_NAME);
if (IS_ERR(ones_class)) {
err("failed to register device class '%s'\n", CLASS_NAME);
retval = PTR_ERR(ones_class);
goto failed_classreg;
}

ones_class->devnode = ones_devnode;

ones_device = device_create(ones_class, NULL, MKDEV(ones_major, 0),
NULL, DEVICE_NAME);

if (IS_ERR(ones_device)) {
err("failed to create device '%s'\n", DEVICE_NAME);
retval = PTR_ERR(ones_device);
goto failed_devreg;
}

info("Ones device registered using major %d.\n", ones_major);

return 0;

failed_devreg:
class_unregister(ones_class);
class_destroy(ones_class);
failed_classreg:
unregister_chrdev(ones_major, DEVICE_NAME);
failed_chrdevreg:
return -1;
}

static void __exit ones_exit(void)
{
device_destroy(ones_class, MKDEV(ones_major, 0));
class_unregister(ones_class);
class_destroy(ones_class);
unregister_chrdev(ones_major, "ones");
info("Unloading Ones module.\n");
return;
}

module_init(ones_init);
module_exit(ones_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Anil Somayaji <soma@scs.carleton.ca>");
MODULE_DESCRIPTION("A write ones character device module");
</source>

===Makefile===
<source lang="make">
obj-m := ones.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
</source>

==newgetpid module==

===newgetpid.c===

<source lang="C" line>
/* Code derived from:
https://appusajeev.wordpress.com/2011/06/18/writing-a-linux-character-device-driver/
and
http://pete.akeo.ie/2011/08/writing-linux-device-driver-for-kernels.html
*/

#include <linux/module.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/device.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/sched.h>
#include <asm/uaccess.h>

#define dbg(format, arg...) do { if (debug) pr_info(CLASS_NAME ": %s: " format, __FUNCTION__, ## arg); } while (0)
#define err(format, arg...) pr_err(CLASS_NAME ": " format, ## arg)
#define info(format, arg...) pr_info(CLASS_NAME ": " format, ## arg)
#define warn(format, arg...) pr_warn(CLASS_NAME ": " format, ## arg)

#define DEVICE_NAME "newgetpid"
#define CLASS_NAME "comp3000"

static struct class* newgetpid_class = NULL;
static struct device* newgetpid_device = NULL;
static int newgetpid_major;

static int newgetpid_open(struct inode *the_inode, struct file *f)
{
return 0;
}

static ssize_t newgetpid_read(struct file *f, char *buf, size_t len, loff_t *offset)
{
size_t i, msglen;
pid_t thepid;

char message[100];

if (*offset > 0) {
return 0;
}

thepid = task_tgid_vnr(current);

snprintf(message, 100, "Your PID is %d!\n", thepid);

msglen = strlen(message);

if (len < msglen) {
msglen = len;
}

for (i = 0; i < msglen; i++) {
put_user(message[i], buf++);
}

*offset = i;

return i;
}

static int newgetpid_release(struct inode *the_inode, struct file *f)
{
printk(KERN_ALERT "Newgetpid device closed\n");
return 0;
}

static struct file_operations newgetpid_fops = {
.open = newgetpid_open,
.read = newgetpid_read,
.release = newgetpid_release,
};

static char *newgetpid_devnode(struct device *dev, umode_t *mode)
{
if (mode)
*mode = 0444;
return NULL;
}

static int __init newgetpid_init(void)
{
int retval;

newgetpid_major = register_chrdev(0, DEVICE_NAME, &newgetpid_fops);
if (newgetpid_major < 0) {
err("failed to register device: error %d\n", newgetpid_major);
retval = newgetpid_major;
goto failed_chrdevreg;
}

newgetpid_class = class_create(THIS_MODULE, CLASS_NAME);
if (IS_ERR(newgetpid_class)) {
err("failed to register device class '%s'\n", CLASS_NAME);
retval = PTR_ERR(newgetpid_class);
goto failed_classreg;
}

newgetpid_class->devnode = newgetpid_devnode;

newgetpid_device = device_create(newgetpid_class, NULL, MKDEV(newgetpid_major, 0),
NULL, DEVICE_NAME);

if (IS_ERR(newgetpid_device)) {
err("failed to create device '%s'\n", DEVICE_NAME);
retval = PTR_ERR(newgetpid_device);
goto failed_devreg;
}

info("Newgetpid device registered using major %d.\n", newgetpid_major);

return 0;

failed_devreg:
class_unregister(newgetpid_class);
class_destroy(newgetpid_class);
failed_classreg:
unregister_chrdev(newgetpid_major, DEVICE_NAME);
failed_chrdevreg:
return -1;
}

static void __exit newgetpid_exit(void)
{
device_destroy(newgetpid_class, MKDEV(newgetpid_major, 0));
class_unregister(newgetpid_class);
class_destroy(newgetpid_class);
unregister_chrdev(newgetpid_major, "newgetpid");
info("Unloading Newgetpid module.\n");
return;
}

module_init(newgetpid_init);
module_exit(newgetpid_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Anil Somayaji <soma@scs.carleton.ca>");
MODULE_DESCRIPTION("A write newgetpid character device module");
</source>

===Makefile===

<source lang=make line>
obj-m := newgetpid.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
</source>

Operating Systems 2018F: Assignment 2

2018-10-05T19:27:50Z

Housedhorse: /* Questions */

Please submit the answers to the following questions via CULearn by 2:30 PM on Wednesday, October 10, 2018. There are 20 points in 10 questions.

Submit your answers as a single text file named "<username>-comp3000-assign2.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Assignment 2", your name, student number, and the date of submission. You may wish to format your answers in Markdown to improve their appearance.

No other formats will be accepted. Submitting in another format will likely result in your assignment not being graded and you receiving no marks for this assignment. In particular do not submit an MS Word or OpenOffice file as your answers document!

Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.

==Questions==

# [2] Assume you have a file A. You type <tt>ln A B</tt> in order to create file B. What is the relationship between the return of lstat() on A versus B? Explain briefly.
# [2] Assume you have a file A. You type <tt>ln -s A B</tt> in order to create file B. What is the relationship between the return of lstat() on A versus B? Explain briefly.
# [2] How could you modify 3000test.c so it can report on what a file's user ID and group ID are and the corresponding username and group name? Specify the changes you make rather than writing all the code out. (In other words, code a solution and explain the changes you made here.)
# [2] If you change line 68 of 3000test.c to be <tt>data[i] = 'A';</tt> (from <tt>count++;</tt>), what will the program do? Explain briefly.
# [2] What does setup_comm_fn() do in 3000shell?
# [2] How can you modify 3000pc so the consumer permanently stops consuming once it finds an empty queue?
# [2] What would happen to 3000pc if we replaced lines 341-347 with <tt>s = (shared *) malloc(sizeof(shared));</tt>? Why?
# [2] In 3000pc, what happens if you remove the calls to kill()? What does this tell you about the roles of signals in this program?
# [2] Is it possible to predict the output of /dev/random? Explain briefly.
# [2] Do sem_wait() and sem_post() generate system calls? (Be sure to check!) Why?

Operating Systems 2018F: Assignment 1

2018-10-01T22:11:53Z

Housedhorse: /* Solutions */

Please submit the answers to the following questions via CULearn by 2:30 PM on September 26, 2018. There are 20 points in 12 questions.

Submit your answers as a single text file named "<username>-comp3000-assign1.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Assignment 1", your name, student number, and the date of submission. You may wish to format your answers in Markdown to improve their appearance.

No other formats will be accepted. Submitting in another format will likely result in your assignment not being graded and you receiving no marks for this assignment. In particular do not submit an MS Word or OpenOffice file as your answers document!

Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.

==Questions==
# [1] What does it mean to run a program "in the background"? Specifically, what is the key difference between running a program in the foreground and in the background?
# [1] Are system calls used to receive signals? Explain briefly. (Hint: strace a program and send it a signal. What happens?)
# [1] The system calls 3000shell uses to search for a program to run (in one of the PATH directories) are not the same as those used by standard shells such as bash. What's the difference?
# [1] How could you change 3000shell so that it generates zombie processes?
# [2] How would the behaviour of 3000shell change if line 286 was removed? (<tt>pid = fork();</tt>) Why?
# [2] In 3000shell, when are lines 299 and 300 executed? Why?
# [2] Does using <tt>getenv()</tt> generate any additional library calls (as reported by ltrace)? Does it generate any additional system calls (as reported by strace)? Why?
# [2] Does parse_args() allocate any memory on the heap (i.e., any memory that stays allocated after the function returns)? How do you know? Give a brief argument.
# [2] <tt>execve</tt> overwrites all of a process's memory with that of a new executable. Does <tt>execve</tt> also close all open file descriptors? How do you know (from your experience with 3000shell)?
# [2] What happens to an in-progress system call when a process receives a signal? (An example is a program waiting for input from a terminal with a blocking <tt>read</tt> call.) What does "restarting" a system call have to do with this?
# [2] If you changed plist() so it took proc_prefix as an argument (rather than accessing it as a global variable), what output would it produce when given an argument other than "/proc"? Explain briefly.
# [2] Describe how you could add output redirection for external programs to 3000shell.

==Solutions==

# The difference between running a program in the foreground and the background is that when run in the foreground, the shell waits for the program to terminate (using wait or waitpid), while when running in the background the shell does not wait and immediately gives another prompt so the user can enter more programs to run (or commands for the shell to execute itself).
# System calls are not used to receive signals. Instead, a process registers signal handlers with the kernel and the kernel calls these functions directly (by manipulating the process's instruction pointer and stack).
# 3000shell makes stat() calls to see if a file exists before doing an execve. bash does similar stat()'s, but it also checks the permissions on the file (using access) to see if it is executable before doing an execve. (You can also say bash just does execve's directly rather than doing stats, but I did not see that behavior in later tests.)
# You can get 3000shell to generate zombie processes by removing the calls to sigaction that register a signal handler. If 3000shell doesn't handle SIGCHLD (and thus never calls wait on background processes), it will create zombie processes that will only go away when 3000shell terminates.
# If you remove the call to fork, only one of the branches of the if statement will be executed. Which branch is executed depends on the value of pid; since it was never initialized, its value is unspecified and thus could be anything. This happens because without the call to fork we never create a child process and we never initialize the pid variable. (1 point for one process, 1 for explaining the uninitialized variable)
# Lines 299 and 300 only execute if the execve call fails. If it succeeds, the code of the process is replaced with the code of the specified program binary; thus, lines 299 and 300 no longer are loaded and thus cannot run. In other words, execve only has a return value when it fails.
# getenv() is a dynamically-linked library function, thus it shows up when doing an ltrace. This function makes no system calls (as getenv() is just a convenience function for accessing data in envp), thus strace reports no additional system calls generated by getenv().
# parse_args() does not allocate any memory on the heap as it does not call malloc() or any other function that allocates heap memory. The only functions it calls are strsep() and strlen(), and their man pages make no mention of allocating memory on the heap. (In fact, very few standard C library functions dynamically allocate memory on the heap, and when they do it is clearly documented as such allocation can be problematic in the context of many C programs.)
# execve does not close open file descriptors. If it did, then it would not be possible to redirect file descriptors for standard in, standard out, and standard error (file descriptors 0, 1, and 2), as these are assumed to already be open when a program starts.
# When a process receives a signal, any currently executing system call is interrupted. If the system call is set to be restarted, then the system call is resumed once the signal handler returns; otherwise, interrupted system calls return (after the signal handler has finished executing). It is particularly important when the read system call is interrupted, as it can mean that data that would normally be read is not read (and an additional read system call must be executed to get the rest of the data). In the case of 3000shell, an interrupted system call can cause a read to think that the "end of the file" has been reached (the terminal has been closed), thus causing it to terminate unless we tell the system to allow system calls to be restarted (line 243).
# If given an arbitrary directory other than /proc, it would list all the files that started with a number and would then attempt to treat each as a directory and would look inside it for a "comm" file in order to get the contents of the second column. Since most directories have few files starting with a number, and few of those are directories with a "comm" file, plist() won't output much for most directories.
# To add output redirection to 3000shell, add the following code somewhere between 266 and 286 (so once it completes the execve completes as usual):
#* Add in code that looks for arguments starting with ">" followed by a filename (that may or may not be separated by a space from ">"). Make sure to remove the ">" and the specified file from the argument list, and generate an error if no filename is specified.
#* Next, add in code that opens the specified file for writing. Call the returned file descriptor fd.
#* Call dup2(fd, 1), to make standard out go to this file.
#* close(fd), because we don't want the specified file to be open on a random file descriptor.

Operating Systems 2018F: Tutorial 4

2018-10-01T21:35:57Z

Housedhorse: /* Tasks/Questions */

In this tutorial you will be experimenting with and extending [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut4/3000pc.c 3000pc.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut4/3000random.c 3000random.c] (both listed below).

==Key Concepts==

3000pc is a simple implementation of the [https://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem producer-consumer problem] in which two processes coordinate their behavior.

In producer-consumer, the two processes share a buffer. One process "produces" - places things inside the buffer. The other process "consumes" - takes things out of the buffer. [https://en.wikipedia.org/wiki/Pipeline_%28Unix%29 UNIX pipes] are a classic implementation of producer-consumer.

In 3000pc, the producer process (the parent process) adds random words to a shared buffer while the consumer (the child process) removes them and prints out the words that it has received. Note that normally a parent and child process cannot communicate with shared memory; however, here they can because of how the buffer is allocated. To prevent the contents of the buffer from being corrupted, ''locks'' are used to enforce ''mutual exclusion''. If there is nothing for the producer to do (no room in the buffer to add words), it goes to sleep; similarly, the consumer goes to sleep if there are no words for it to consume. If either process goes to sleep, the other must wake it up.

3000pc uses the C standard's way for generating pseudo-random numbers. This method is fast but not very good. The Linux kernel, however, has a built-in high quality random number generator. 3000random.c is a demonstration for how to use it.

You will notice that there are a number of concepts here that we have not yet discussed in class. This is by design. Play with the code and see what it does. You should be able to understand most of it once you study it, as it just uses fork, mmap, and signals. We will discuss the higher level concepts (synchronization, locking, producer-consumer) and lower level mechanisms (character devices, /dev/urandom, semaphores) in depth in lecture later this week.

==Tasks/Questions==

For '''Questions 3-8''' make sure you undo your changes before moving on to the next question.

# Compile and run 3000pc.c. Note that you'll need to add a "-pthread" option to your compile command. First run it with a -1 for both delay intervals, then try other values. When does the producer signal the consumer? When does the consumer signal the producer?
# How can you output the random words to a file so that you only see the signal messages on the console?
# Modify the producer so that it never unlocks each entry (but does lock it). What happens?
# Modify the consumer so that it never unlocks each entry (but does lock it). What happens?
# What happens if you remove all entry locking/unlocking? How does the behavior change?
# Remove the SIGUSR1 signal handler from the producer (so it uses the C library default signal handler). How does the program behave?
# Remove the SIGUSR1 signal handler from the consumer (so it uses the C library default signal handler). How does the program behave?
# Change the producer and consumer so they only sleep for 1000 nanoseconds (1 millisecond) rather than 1 second during each delay interval. How does the behavior of the program change?
# Compile and run 3000random.c. Note that it takes two arguments. Where does this program get its random numbers from?
# Change 3000random.c to use /dev/random rather than /dev/urandom. How does its performance change, especially when generating a large number of random numbers?
# Change 3000pc.c to use random numbers from /dev/urandom rather than using the standard library function random(). How does this change affect the relative speed of the producer and consumer processes?
# '''(Bonus)''' Modify 3000pc.c so it takes in an additional command line argument that is the filename of a word list. This file should have one word per line. The program should then use this read-in word list rather than the hard coded word list. Pay attention to:
#* where you read the file (in the producer, consumer, or before the fork)
#* where and how you store the words in memory (the word list should be arbitrarily long, but the maximum length of a word can be fixed)
# '''(Bonus)''' Modify 3000pc.c so that it has multiple producers and consumers running concurrently, with the number of each specified on the command line.

==Code==

===3000pc.c===
<source lang="c" line>
/* 3000pc.c */
/* producer-consumer example using signals, processes and mmap */
/* v1 Oct. 15, 2017 */
/* Licenced under the GPLv3, copyright Anil Somayaji */
/* You really shouldn't be incorporating parts of this in any other code,
it is meant for teaching, not production */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <semaphore.h>
#include <string.h>
#include <time.h>

#define QUEUESIZE 32
#define WORDSIZE 16

const int wordlist_size = 27;
const char *wordlist[] = {
"Alpha",
"Bravo",
"Charlie",
"Delta",
"Echo",
"Foxtrot",
"Golf",
"Hotel",
"India",
"Juliet",
"Kilo",
"Lima",
"Mike",
"November",
"Oscar",
"Papa",
"Quebec",
"Romeo",
"Sierra",
"Tango",
"Uniform",
"Victor",
"Whiskey",
"X-ray",
"Yankee",
"Zulu",
"Dash"
};

typedef struct entry {
char word[WORDSIZE];
sem_t lock;
} entry;

typedef struct shared {
int prod_waiting;
int con_waiting;
entry queue[QUEUESIZE];
int last_produced;
int last_consumed;
pid_t prod_pid;
pid_t con_pid;
int prod_count;
int con_count;
} shared;

void report_error(char *error)
{
fprintf(stderr, "Error: %s\n", error);
}

void usage_exit(char *progname)
{
fprintf(stderr,
"Usage: %s <event count> <prod delay int> <con delay int>\n",
progname);
exit(-1);
}

void producer_handler(int the_signal)
{
if (the_signal == SIGUSR1) {
fprintf(stderr, "Producer received SIGUSR1.\n");
return;

} else {
fprintf(stderr, "Producer: No handler for for signal %d?!\n",
the_signal);
return;
}
}

void consumer_handler(int the_signal)
{
if (the_signal == SIGUSR1) {
fprintf(stderr, "Consumer received SIGUSR1.\n");
return;
} else {
fprintf(stderr, "Consumer: No handler for for signal %d?!\n",
the_signal);
return;
}
}

void pick_word(char *word)
{
int pick;

pick = random() % wordlist_size;

strcpy(word, wordlist[pick]);
}

void wait_for_producer(shared *s)
{
struct timespec delay;

delay.tv_sec = 100;
delay.tv_nsec = 0;

s->con_waiting = 1;

while (s->con_waiting) {
nanosleep(&delay, NULL);
}
}

void wait_for_consumer(shared *s)
{
struct timespec delay;

delay.tv_sec = 100;
delay.tv_nsec = 0;

s->prod_waiting = 1;

while (s->prod_waiting) {
nanosleep(&delay, NULL);
}
}

void wakeup_consumer(shared *s)
{
if (s->con_waiting) {
s->con_waiting = 0;
kill(s->con_pid, SIGUSR1);
}
}

void wakeup_producer(shared *s)
{
if (s->prod_waiting) {
s->prod_waiting = 0;
kill(s->prod_pid, SIGUSR1);
}
}

void output_word(int c, char *w)
{
printf("Word %d: %s\n", c, w);
}

int queue_word(char *word, shared *s)
{
entry *e;
int current, retval;

current = (s->last_produced + 1) % QUEUESIZE;

e = &s->queue[current];

sem_wait(&e->lock);

if (e->word[0] != '\0') {
/* consumer hasn't consumed this entry yet */
sem_post(&e->lock);
wait_for_consumer(s);
sem_wait(&e->lock);
}

if (e->word[0] != '\0') {
fprintf(stderr, "ERROR: No room for producer after waiting!\n");
retval = -1;
goto done;
} else {
strncpy(e->word, word, WORDSIZE);
s->last_produced = current;
s->prod_count++;
wakeup_consumer(s);
retval = 0;
goto done;
}

done:
sem_post(&e->lock);
return retval;
}

int get_next_word(char *word, shared *s)
{
entry *e;
int current, retval;

current = (s->last_consumed + 1) % QUEUESIZE;

e = &s->queue[current];

sem_wait(&e->lock);

if (e->word[0] == '\0') {
/* producer hasn't filled in this entry yet */
sem_post(&e->lock);
wait_for_producer(s);
sem_wait(&e->lock);
}

if (e->word[0] == '\0') {
fprintf(stderr, "ERROR: Nothing for consumer after waiting!\n");
retval = -1;
goto done;
} else {
strncpy(word, e->word, WORDSIZE);
e->word[0] = '\0';
s->last_consumed = current;
s->con_count++;
wakeup_producer(s);
retval = 0;
goto done;
}

done:
sem_post(&e->lock);
return retval;
}

void producer(shared *s, int event_count, int producer_delay_interval)
{
char word[WORDSIZE];
int i;
struct sigaction signal_handler_struct;

memset (&signal_handler_struct, 0, sizeof(signal_handler_struct));
signal_handler_struct.sa_handler = producer_handler;

if (sigaction(SIGUSR1, &signal_handler_struct, NULL)) {
fprintf(stderr, "Producer couldn't register SIGUSR1 handler.\n");
}

for (i=0; i < event_count; i++) {
pick_word(word);
queue_word(word, s);
if (producer_delay_interval > 0) {
if (i % producer_delay_interval == 0) {
sleep(1);
}
}
}

printf("Producer finished.\n");
exit(0);
}

void consumer(shared *s, int event_count, int consumer_delay_interval)
{
char word[WORDSIZE];
int i;
struct sigaction signal_handler_struct;

memset (&signal_handler_struct, 0, sizeof(signal_handler_struct));
signal_handler_struct.sa_handler = consumer_handler;

if (sigaction(SIGUSR1, &signal_handler_struct, NULL)) {
fprintf(stderr, "Consumer couldn't register SIGUSR1 handler.\n");
}

for (i=0; i < event_count; i++) {
get_next_word(word, s);
output_word(s->con_count, word);
if (consumer_delay_interval > 0) {
if (i % consumer_delay_interval == 0) {
sleep(1);
}
}
}

printf("Consumer finished.\n");
exit(0);
}

void init_shared(shared *s)
{
int i;

s->con_waiting = 0;
s->last_consumed = -1;

s->prod_waiting = 0;
s->last_produced = -1;

s->prod_pid = -1;
s->con_pid = -1;

s->prod_count = 0;
s->con_count = 0;

for (i=0; i<QUEUESIZE; i++) {
s->queue[i].word[0] = '\0';
/* semaphore is shared between processes,
and initial value is 1 (unlocked) */
sem_init(&s->queue[i].lock, 1, 1);
}
}

int main(int argc, char *argv[])
{
int pid, count, prod_interval, con_interval;

shared *s;

srandom(42);

if (argc < 4) {
if (argc < 1) {
report_error("no command line");
usage_exit(argv[0]);
} else {
report_error("Not enough arguments");
usage_exit(argv[0]);
}
}

count = atoi(argv[1]);
prod_interval = atoi(argv[2]);
con_interval = atoi(argv[3]);

s = (shared *) mmap(NULL, sizeof(shared),
PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_ANONYMOUS, -1, 0);

if (s == MAP_FAILED) {
report_error(strerror(errno));
}

init_shared(s);

pid = fork();

if (pid) {
/* producer */
s->prod_pid = getpid();
producer(s, count, prod_interval);
} else {
/* consumer */
s->con_pid = getpid();
consumer(s, count, con_interval);
}

/* This line should never be reached */
return -1;
}
</source>

===3000random.c===

<source lang="c" line>
/* 3000random.c */
/* prints out random numbers obtained from system /dev/urandom */
/* (This is much, much better than using rand() or random())! */
/* v1 Oct. 15, 2017 */
/* Licenced under the GPLv3, copyright Anil Somayaji */
/* You really shouldn't be incorporating parts of this in any other code,
it is meant for teaching, not production */

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>

#define BUFSIZE 1024

typedef struct rand_state {
unsigned long buffer[BUFSIZE];
int current;
int fd;
} rand_state;

void fill_rand_buffer(rand_state *r)
{
ssize_t count;

count = read(r->fd, (void *) &r->buffer,
BUFSIZE * sizeof(unsigned long));

if (count > sizeof(unsigned long)) {
r->current = (count / sizeof(unsigned long)) - 1;
/* was %, that was wrong! */
/* left out -1, that was wrong! */
} else {
fprintf(stderr, "Couldn't fill random buffer.\n");
}
}

void system_rand_init(rand_state *r)
{
r->fd = open("/dev/urandom", O_RDONLY);

fill_rand_buffer(r);
}

long system_rand(long max, rand_state *r)
{
unsigned long val;

if (r->current < 0) {
fill_rand_buffer(r);
if (r->current < 0) {
/* fill_rand_buffer should have already
reported an error */
return 0;
}
}

val = r->buffer[r->current];
r->current--;
return val % max;
}

int main(int argc, char *argv[])
{
int count, i;
long max, x;
rand_state r;

if (argc != 3) {
fprintf(stderr, "Usage: %s <count> <max>\n", argv[0]);
exit(-1);
}

count = atoi(argv[1]);
max = atol(argv[2]);

printf("count = %d, max = %ld\n", count, max);

system_rand_init(&r);

for (i = 0; i < count; i++) {
x = system_rand(max, &r);
printf("%ld\n", x);
}

return 0;
}
</source>

Operating Systems 2018F: Tutorial 4

2018-10-01T21:35:01Z

Housedhorse: /* Tasks/Questions */

In this tutorial you will be experimenting with and extending [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut4/3000pc.c 3000pc.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut4/3000random.c 3000random.c] (both listed below).

==Key Concepts==

3000pc is a simple implementation of the [https://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem producer-consumer problem] in which two processes coordinate their behavior.

In producer-consumer, the two processes share a buffer. One process "produces" - places things inside the buffer. The other process "consumes" - takes things out of the buffer. [https://en.wikipedia.org/wiki/Pipeline_%28Unix%29 UNIX pipes] are a classic implementation of producer-consumer.

In 3000pc, the producer process (the parent process) adds random words to a shared buffer while the consumer (the child process) removes them and prints out the words that it has received. Note that normally a parent and child process cannot communicate with shared memory; however, here they can because of how the buffer is allocated. To prevent the contents of the buffer from being corrupted, ''locks'' are used to enforce ''mutual exclusion''. If there is nothing for the producer to do (no room in the buffer to add words), it goes to sleep; similarly, the consumer goes to sleep if there are no words for it to consume. If either process goes to sleep, the other must wake it up.

3000pc uses the C standard's way for generating pseudo-random numbers. This method is fast but not very good. The Linux kernel, however, has a built-in high quality random number generator. 3000random.c is a demonstration for how to use it.

You will notice that there are a number of concepts here that we have not yet discussed in class. This is by design. Play with the code and see what it does. You should be able to understand most of it once you study it, as it just uses fork, mmap, and signals. We will discuss the higher level concepts (synchronization, locking, producer-consumer) and lower level mechanisms (character devices, /dev/urandom, semaphores) in depth in lecture later this week.

==Tasks/Questions==

For '''Questions 3-8''' make sure you undo your changes before moving onto the next question.

# Compile and run 3000pc.c. Note that you'll need to add a "-pthread" option to your compile command. First run it with a -1 for both delay intervals, then try other values. When does the producer signal the consumer? When does the consumer signal the producer?
# How can you output the random words to a file so that you only see the signal messages on the console?
# Modify the producer so that it never unlocks each entry (but does lock it). What happens?
# Modify the consumer so that it never unlocks each entry (but does lock it). What happens?
# What happens if you remove all entry locking/unlocking? How does the behavior change?
# Remove the SIGUSR1 signal handler from the producer (so it uses the C library default signal handler). How does the program behave?
# Remove the SIGUSR1 signal handler from the consumer (so it uses the C library default signal handler). How does the program behave?
# Change the producer and consumer so they only sleep for 1000 nanoseconds (1 millisecond) rather than 1 second during each delay interval. How does the behavior of the program change?
# Compile and run 3000random.c. Note that it takes two arguments. Where does this program get its random numbers from?
# Change 3000random.c to use /dev/random rather than /dev/urandom. How does its performance change, especially when generating a large number of random numbers?
# Change 3000pc.c to use random numbers from /dev/urandom rather than using the standard library function random(). How does this change affect the relative speed of the producer and consumer processes?
# '''(Bonus)''' Modify 3000pc.c so it takes in an additional command line argument that is the filename of a word list. This file should have one word per line. The program should then use this read-in word list rather than the hard coded word list. Pay attention to:
#* where you read the file (in the producer, consumer, or before the fork)
#* where and how you store the words in memory (the word list should be arbitrarily long, but the maximum length of a word can be fixed)
# '''(Bonus)''' Modify 3000pc.c so that it has multiple producers and consumers running concurrently, with the number of each specified on the command line.

==Code==

===3000pc.c===
<source lang="c" line>
/* 3000pc.c */
/* producer-consumer example using signals, processes and mmap */
/* v1 Oct. 15, 2017 */
/* Licenced under the GPLv3, copyright Anil Somayaji */
/* You really shouldn't be incorporating parts of this in any other code,
it is meant for teaching, not production */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <semaphore.h>
#include <string.h>
#include <time.h>

#define QUEUESIZE 32
#define WORDSIZE 16

const int wordlist_size = 27;
const char *wordlist[] = {
"Alpha",
"Bravo",
"Charlie",
"Delta",
"Echo",
"Foxtrot",
"Golf",
"Hotel",
"India",
"Juliet",
"Kilo",
"Lima",
"Mike",
"November",
"Oscar",
"Papa",
"Quebec",
"Romeo",
"Sierra",
"Tango",
"Uniform",
"Victor",
"Whiskey",
"X-ray",
"Yankee",
"Zulu",
"Dash"
};

typedef struct entry {
char word[WORDSIZE];
sem_t lock;
} entry;

typedef struct shared {
int prod_waiting;
int con_waiting;
entry queue[QUEUESIZE];
int last_produced;
int last_consumed;
pid_t prod_pid;
pid_t con_pid;
int prod_count;
int con_count;
} shared;

void report_error(char *error)
{
fprintf(stderr, "Error: %s\n", error);
}

void usage_exit(char *progname)
{
fprintf(stderr,
"Usage: %s <event count> <prod delay int> <con delay int>\n",
progname);
exit(-1);
}

void producer_handler(int the_signal)
{
if (the_signal == SIGUSR1) {
fprintf(stderr, "Producer received SIGUSR1.\n");
return;

} else {
fprintf(stderr, "Producer: No handler for for signal %d?!\n",
the_signal);
return;
}
}

void consumer_handler(int the_signal)
{
if (the_signal == SIGUSR1) {
fprintf(stderr, "Consumer received SIGUSR1.\n");
return;
} else {
fprintf(stderr, "Consumer: No handler for for signal %d?!\n",
the_signal);
return;
}
}

void pick_word(char *word)
{
int pick;

pick = random() % wordlist_size;

strcpy(word, wordlist[pick]);
}

void wait_for_producer(shared *s)
{
struct timespec delay;

delay.tv_sec = 100;
delay.tv_nsec = 0;

s->con_waiting = 1;

while (s->con_waiting) {
nanosleep(&delay, NULL);
}
}

void wait_for_consumer(shared *s)
{
struct timespec delay;

delay.tv_sec = 100;
delay.tv_nsec = 0;

s->prod_waiting = 1;

while (s->prod_waiting) {
nanosleep(&delay, NULL);
}
}

void wakeup_consumer(shared *s)
{
if (s->con_waiting) {
s->con_waiting = 0;
kill(s->con_pid, SIGUSR1);
}
}

void wakeup_producer(shared *s)
{
if (s->prod_waiting) {
s->prod_waiting = 0;
kill(s->prod_pid, SIGUSR1);
}
}

void output_word(int c, char *w)
{
printf("Word %d: %s\n", c, w);
}

int queue_word(char *word, shared *s)
{
entry *e;
int current, retval;

current = (s->last_produced + 1) % QUEUESIZE;

e = &s->queue[current];

sem_wait(&e->lock);

if (e->word[0] != '\0') {
/* consumer hasn't consumed this entry yet */
sem_post(&e->lock);
wait_for_consumer(s);
sem_wait(&e->lock);
}

if (e->word[0] != '\0') {
fprintf(stderr, "ERROR: No room for producer after waiting!\n");
retval = -1;
goto done;
} else {
strncpy(e->word, word, WORDSIZE);
s->last_produced = current;
s->prod_count++;
wakeup_consumer(s);
retval = 0;
goto done;
}

done:
sem_post(&e->lock);
return retval;
}

int get_next_word(char *word, shared *s)
{
entry *e;
int current, retval;

current = (s->last_consumed + 1) % QUEUESIZE;

e = &s->queue[current];

sem_wait(&e->lock);

if (e->word[0] == '\0') {
/* producer hasn't filled in this entry yet */
sem_post(&e->lock);
wait_for_producer(s);
sem_wait(&e->lock);
}

if (e->word[0] == '\0') {
fprintf(stderr, "ERROR: Nothing for consumer after waiting!\n");
retval = -1;
goto done;
} else {
strncpy(word, e->word, WORDSIZE);
e->word[0] = '\0';
s->last_consumed = current;
s->con_count++;
wakeup_producer(s);
retval = 0;
goto done;
}

done:
sem_post(&e->lock);
return retval;
}

void producer(shared *s, int event_count, int producer_delay_interval)
{
char word[WORDSIZE];
int i;
struct sigaction signal_handler_struct;

memset (&signal_handler_struct, 0, sizeof(signal_handler_struct));
signal_handler_struct.sa_handler = producer_handler;

if (sigaction(SIGUSR1, &signal_handler_struct, NULL)) {
fprintf(stderr, "Producer couldn't register SIGUSR1 handler.\n");
}

for (i=0; i < event_count; i++) {
pick_word(word);
queue_word(word, s);
if (producer_delay_interval > 0) {
if (i % producer_delay_interval == 0) {
sleep(1);
}
}
}

printf("Producer finished.\n");
exit(0);
}

void consumer(shared *s, int event_count, int consumer_delay_interval)
{
char word[WORDSIZE];
int i;
struct sigaction signal_handler_struct;

memset (&signal_handler_struct, 0, sizeof(signal_handler_struct));
signal_handler_struct.sa_handler = consumer_handler;

if (sigaction(SIGUSR1, &signal_handler_struct, NULL)) {
fprintf(stderr, "Consumer couldn't register SIGUSR1 handler.\n");
}

for (i=0; i < event_count; i++) {
get_next_word(word, s);
output_word(s->con_count, word);
if (consumer_delay_interval > 0) {
if (i % consumer_delay_interval == 0) {
sleep(1);
}
}
}

printf("Consumer finished.\n");
exit(0);
}

void init_shared(shared *s)
{
int i;

s->con_waiting = 0;
s->last_consumed = -1;

s->prod_waiting = 0;
s->last_produced = -1;

s->prod_pid = -1;
s->con_pid = -1;

s->prod_count = 0;
s->con_count = 0;

for (i=0; i<QUEUESIZE; i++) {
s->queue[i].word[0] = '\0';
/* semaphore is shared between processes,
and initial value is 1 (unlocked) */
sem_init(&s->queue[i].lock, 1, 1);
}
}

int main(int argc, char *argv[])
{
int pid, count, prod_interval, con_interval;

shared *s;

srandom(42);

if (argc < 4) {
if (argc < 1) {
report_error("no command line");
usage_exit(argv[0]);
} else {
report_error("Not enough arguments");
usage_exit(argv[0]);
}
}

count = atoi(argv[1]);
prod_interval = atoi(argv[2]);
con_interval = atoi(argv[3]);

s = (shared *) mmap(NULL, sizeof(shared),
PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_ANONYMOUS, -1, 0);

if (s == MAP_FAILED) {
report_error(strerror(errno));
}

init_shared(s);

pid = fork();

if (pid) {
/* producer */
s->prod_pid = getpid();
producer(s, count, prod_interval);
} else {
/* consumer */
s->con_pid = getpid();
consumer(s, count, con_interval);
}

/* This line should never be reached */
return -1;
}
</source>

===3000random.c===

<source lang="c" line>
/* 3000random.c */
/* prints out random numbers obtained from system /dev/urandom */
/* (This is much, much better than using rand() or random())! */
/* v1 Oct. 15, 2017 */
/* Licenced under the GPLv3, copyright Anil Somayaji */
/* You really shouldn't be incorporating parts of this in any other code,
it is meant for teaching, not production */

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>

#define BUFSIZE 1024

typedef struct rand_state {
unsigned long buffer[BUFSIZE];
int current;
int fd;
} rand_state;

void fill_rand_buffer(rand_state *r)
{
ssize_t count;

count = read(r->fd, (void *) &r->buffer,
BUFSIZE * sizeof(unsigned long));

if (count > sizeof(unsigned long)) {
r->current = (count / sizeof(unsigned long)) - 1;
/* was %, that was wrong! */
/* left out -1, that was wrong! */
} else {
fprintf(stderr, "Couldn't fill random buffer.\n");
}
}

void system_rand_init(rand_state *r)
{
r->fd = open("/dev/urandom", O_RDONLY);

fill_rand_buffer(r);
}

long system_rand(long max, rand_state *r)
{
unsigned long val;

if (r->current < 0) {
fill_rand_buffer(r);
if (r->current < 0) {
/* fill_rand_buffer should have already
reported an error */
return 0;
}
}

val = r->buffer[r->current];
r->current--;
return val % max;
}

int main(int argc, char *argv[])
{
int count, i;
long max, x;
rand_state r;

if (argc != 3) {
fprintf(stderr, "Usage: %s <count> <max>\n", argv[0]);
exit(-1);
}

count = atoi(argv[1]);
max = atol(argv[2]);

printf("count = %d, max = %ld\n", count, max);

system_rand_init(&r);

for (i = 0; i < count; i++) {
x = system_rand(max, &r);
printf("%ld\n", x);
}

return 0;
}
</source>