 Okay And welcome How to deploy from salsa I am Riccordini I maintain Mostly web services in Debian. I like okay, wasn't me. I swear I have witnesses I Maintain probably I like to write Web services more than I like to package, so I write web services and Nn.debian.org is one the website for the new member process that people use when they Want to get Status in Debian like become Debian maintainer or the developer Another one is contributors.debian.org which tracks contributions from people and So at some point Alliot was discontinued salsa happened and And that was really nice and salsa also has continuous integration So you can set it up so that when you commit something to salsa you have test cases running so Somewhere here Which is hard to see you can see that Somebody guide me to finding the sea I report Right See from here Okay Said things right No We'll get there later Okay, so yeah commits trigger a Built and running tests So that's the last commit that built and past all the tests and that was great And then I was like, okay, but then when the tests are built It will be nice if the new site will be deployed And so I played with doing that Alliot allows To do webhooks this time I do need the configuration There it is Would it expose the secret tokens? triggers variables What am I missing? the webhooks right This is hard integrations Okay So you can tell Salsa that when Things happened or what you can tell github the code behind salsa that when things are pushed or something Then it will Call a URL can you read this? So I told it, okay when Something happens in continuous integration Call the code on the side and here pipeline events so when Things happen in the continuous integration pipelines code is called on the site and then since Well, it's a it's a web service. So I could add code that's triggered by the I mean I already can implement like views and URL endpoints in the web service. I Created one so I get posted by github. I Verify you can set up a secret token in github so that you know it's github calling you and not someone else Decode things check that the right kind of event. So it's a pipeline event Check that The build status is success because github also calls to say I started building I Finish building the building fails and so on when I realize it's the right kind of event I touch a file and This is done I touch a file so that the Actual deploy is not done with the same user as the web the web serve the web service cannot write on its own code otherwise if somebody can Find a vulnerability on the web service. They have arbitrary code execution on the site step 2 systemd there is a path unit which basically says if Files are created with this Name then do and that's a user configuration of systemd no route required But this is the user that can do the deploy So basically I get notified by github. I verify that Github is telling the right things and then I call a deploy script I mean I touch a file which triggers calling a deploy script the path activation in systemd is quite nice in my opinion Then next bit clean the flicks next bit I That's the code that does the deploying Which does some custom logging which Logs in an email so that everything it does is notified to a mailing list and Then and then I verify that the commit is in the branch that is configured to be deployed I The files that are created have the shasam given by github to be deployed and summarizing things It does a fetch to get the code Check that the Shasam of the branch that it fetched is the shasam that built correctly on the CI Builds GPG key ring with the keys that are in the repository so there's a sub directory in the repository with the keys of people who can commit and I create a GPG temporary GPG key ring with that and use it to verify the signature on the commit So I don't need to trust salsa. Basically. I'm pushing a signed commit My key is known by the repository by the git repository salsa builds notifies I fetch I verify the signature so if salsa is malicious and notifies me of deploying pointers commits I mean amalicious takeover of salsa cannot generate signed commits and Also, I check that the branch to be deployed is a fast forward from the current one So Amalicious takeover of salsa will not deploy a past signed commit That may be had a vulnerability that I fixed later So people cannot roll back to a previous commit After which I'm happy I Run the deploy and all the out of all the output of this gets emailed And that's my implementation of one out of the plowing from salsa I built this as a mostly reusable Django application so if other people are using Django for Debian services or Using Django outside Debian, but a combination of Django and GitLab This is a working setup That that can mostly be reused And it it's yeah, well free software part of an M Debian org and contributors Debian org So these are one way to do it FTP master Did it differently? I Describe if you from what Ansgar showed me earlier FTP master runs a cron job that fetches from Git and check signature a Bit like this and then if signature is fine, and it's a fast forward it does the deploy FTP master uses a hundred lines of shell. I use a thousand lines of Python But this at least this has integration with GitLab Continuous integration. So this gets a push from GitLab and on FTP master. It's a cron job running Still to me that was quite a new thing for Debian I mean Because we have salsa we can do this which I think is amazing That so there's a CI meaning that the tests in the code Work not only on my computer, but also on salsa So they're very likely to also work on the computers of other people trying to work on the site Which is great and they are checked out automatically on salsa So when I'm lazy or stupid and I commit mistakes, and I'm in a hurry and I push them anyway They don't get deployed and also The whole pipeline of a deploying is not just on my laptop So I panic everything It's not just on my laptop. So if somebody else wants to contribute they just push There's been a lot more people deploying changes in the in the code Then before because now it's just a push away so I would like to see more of this in Debian and the point of this both is to Show that this is possible and encourage for more to happen as Do you know of any other service in Debian that can deploy? from Github automatically because I may not know them all or Do any of you do automatic deploy from Github outside of Debian? So that's the idea and How to store the keys is an issue So Currently I have this So I commit to the key in the repository Which means on the deploy side There's no need to fetch keys from key servers And in a way that's convenient. I mean on Debian machines you have access to the Debian key ring So one can get the keys from there, but this works also in a setup where There's no key to go for Possible keys the downside of this is That when a subkey expires you need to manually add one So not only send the new key to the key ring, but also update the deploy key ring on FTP master side. They only keep fingerprints, right? Yeah And then they look up the fingerprint in the Debian key ring And so they don't have that problem Yeah design issues, but yeah, there's a like already two ways in which this is done and Yeah, I would like to encourage more of it questions suggestions Anybody would like to have this in other services Or in other projects Microphone so Use a similar setup not with the web services and looks but the configuration for auto-replying packages So we have Get server of our own for Amaral Linux. It's a derivative of Debian Mm-hmm And what we do is we build the packages in this inner container using the CI file and We deploy using SSH, right? So that's kind of auto-reply for us but it's it's not having a lot of Quality checks that you're high you are implementing. So this seems nice But which distribution you said Amaral Linux H-A-M-A-R-E Amaral Linux. Yeah, it's based on Debian. Cool. Yeah, so I use this particular thing that Just a configuration file is we could just write a configuration file to build a Debian package in a container and Just pushes the files to the repositories So but that's that's uses SSH. This is GPG is nice Yeah, thank you and I want yeah, I wanted to use GPG because at work we thought about auto-replying web services and We did not want to trust the GitLab instance And so we thought that the GitLab instance could ping a deploying machine that had the SSH keys to do deploy remotely with Ansible on On the production servers, but that requires an extra machine that needs to be secured a lot And so the workaround was well. Yeah, we can sign commits. So So that it's possible to skill patch an mdebian org and push Something and see what happens Okay, thank you. Oh 2012 And it's not just me How about that and other Debian contributors? How do you do that? Okay, sounds good good push Of course never pull before Checking what happened Okay, it's good Of course the Shassam changed Okay, correct Okay pushed so that's the Debian new main tier C channel Something should happen at some point, especially if I scroll to the bottom. Who needs me? Ah, okay Okay, I'll get back to you later on that Okay, so there's another webhook that Notifies things on on IRC. So you can tell there's been a push it's been building Running duration no time. Okay tests are running So I can go to salsa Pipelines It's probably already finished No running good It's uh, yeah running the test suite There was a scroll to the bottom It doesn't scroll to bottom So the good thing is that I don't need to do anything at this point except Be anxious. Hopefully all tests pass. Yeah, you should have a lot of tests in your test suite That is a bit. I thought they would be faster. Yes Yeah, I give feedback Well salsa As access to lots of container like docker files, I think it uses docker Confirm, okay, and you can choose a lot of docker setups So in this case, it's Debian stable, but the container has no access to the internet So you cannot have a test that depends on Stuff on the internet as far as I can tell as far as I remember Come on. Yeah, it is testing all the possible user combinations like If you are An application manager, can you read the mailbox of an applicant? Even if it's not your applicant And and all sort of like permission checking on an mw anorg is quite insane so Uh Can an advocate check on the progress of their applicants? And so on but I was hoping for faster tests back to IRC Which one was IRC? Okay test that would success Duration no time Fine So this should have triggered things on salsa's side and an email to however hide a bit of the screen Because is it hidden? Yes And then I get mail with all the log of the deploy process Uh added to a mail So Yeah Deploy happened the commands have been run Signature is valid Can it be read probably small? That's what I wanted to check the signature Did rebase Of I'm used to rebase when I pull in changes because if I merge sometimes there's a merge commit But in this case it checks that there is a linear history From the current commit to the one to be deployed. So it's the same thing Um And that's the normal deploy thing for a Django application touch of the source code so apache will reload the service and removes the Deploy file with the shasam to deploy there were two of them. I guess one of them failed to deploy and was discarded So, yeah, that's uh one implement one possible implementation of auto deploy from salsa I would suggest that anyone running Running services for debian set something like this up. It takes a bit There's example code on ftp master and on an m debian org and contributors dot debian dot org Feel free to come and poke me for the an m debian org site It's not hard to implement one like I've been paranoid and then I tried to make it reusable But the general idea is either by a cron or via Push from salsa fetch check signature Check that you have linear history deploy and yeah, this greatly helps people joining your your Your your project Your team Being able to run the test suite being able to deploy You just need to add once you trust them you add their key to To the the key ring if you don't trust them You pull the change and you make an empty signed commit There's a good commit the dash capital s dash dash allow empty I think So it's like you stamp their commit and push and yay done that's That's what I have there's 10 more minutes for questions want to see the code again Want to see the units on system d side again? Or yeah Are the units System d for somewhere on salsa so that we can get back to it if you want I did not know the file trigger or and stuff like that, but right Good point because currently the units are just on the server um Maybe you could make it Repository somewhere to share them. Yeah, uh, I have I can give you this Like I blocked a little quick guide on system d mountain swap service path Okay Which uh, I guess if you google for in ricozini system d path units uh, you get a A quick introduction, but um, yeah when when Like at the end of the talk Remind me because I'm usually confused after a talk And um, I'll publish them somewhere. Yes, definitely Even just yeah in in a read me in in in the deploy read me or something. Yeah Yeah, I've um at the beginning of this year I think I was asked to give uh to teach people about system d Which was a fantastic opportunity for me to learn something about system d And uh, and these are all the teaching notes that uh, I was allowed to dump on my block It can also trigger on When a device happens or Like um, that was actually cute in in the system decors that I made um So you can say when that usb key is plugs that play beeps That specific usb key so people started playing pranks on each other saying that When the usb key of a specific person is plugged into somebody's computer, there will be a loud alert sound Thank you for being here