Hej!
Så här ser det ut när man run-cosmos på web.ndn:
--8<---------------cut here---------------start------------->8---
################################################################
FAILED signature check on puppet-module dhcp
################################################################
object a840d658cf26dc1a5c4506a453ab0c9353d8d5b8
type commit
tag sunet-2013-12-20-v01
tagger Fredrik Thulin <fredrik at thulin.net> 1387529664 +0100
new version
gpg: Signature made Fri Dec 20 09:54:27 2013 CET using RSA key ID 505152DD
gpg: Can't check signature: public key not found
error: could not verify the tag 'sunet-2013-12-20-v01'
--8<---------------cut here---------------end--------------->8---
Jag antar att det beror på att vi plockade bort Fredriks nyckel (commit
1d039c6). Fattar inte riktigt hur det kunde funka fram till idag
dock. Verifierar cosmos "gamla taggar" ibland?
Mer genereellt, hur är det tänkt att det skall gå till när man tar bort
nycklar?
Hej!
(Vilka är på den här listan förresten? Är Markus och htj här t.ex.?)
Skulle göra en https://software.nordu.net/ som kunde innehålla sånt som
https://software.nordu.net/radsecproxy/.
Trodde att det var smart att använda en s.k. datacontainer för varje
projekt och göra
docker run --name radsecproxy-web radsecproxy-web # VOLUME /var/www/html/radsecproxy
docker run --name web_software_ndn --volumes-from radsecproxy-web -d web_software_ndn
I web_software_ndn kommer då att finnas en /var/www/html/radsecproxy som
kommer från containern radsecproxy-web som är Exited men fortfarande
fungerar som "data container".
Om jag sen vill uppdatera något i radsecproxy-web och bygger om den så
verkar det som att dessa ändringar inte biter förrän web_software_ndn
startas om. Det var ju lite trist.
Så, hur gör man sånt här smartast?
(Adding dev at .)
Markus Krogh <markus at nordu.net> wrote
Thu, 3 Dec 2015 09:09:25 +0100:
| CI is a hackers best friend, they are often’t unpatched/unmaintained,
| as well as they by default have unsafe configuration. Most CIs will by
| default compile on the same machine as the CI is running, meaning if
| you are compiling code you cannot trust that is a problem, they also
| often have access to internal systems to do redeploys etc. making them
| a juicy target.
Thanks.
(For more context, CI means "continous integration". A CI system is a
(set of) machine(s) continously compiling (and hopefully testing)
software projects, often showing the current status in some web
thing. 15 years ago this was called "nightly builds".)
| If you ask me it is more of a please configure and update your CI rather than a don’t use CI systems.
I think that binaries built on a machine with any internet facing
services except perhaps sshd should not be deployed. Unless reproducibly
built.
CI systems can of course still be useful for catching
regression. Running tests on a CI system is a good idea.
