Hi,
I’m looking for someone who knows a thing or two about data visualisation and has a few hours to spare.
I have a few sets of entries (accepted root certificates in CT logs, 10 logs with 20-500 entries each) and I’m interested in showing how they overlap, preferably with the possibility to klick around a bit. There are probably some people online who would also find it interesting…
I don’t really know anything about setting up the front end but I have some scripts for generating the data. Anyone interested?
// Josef
Hej!
Jag har två grejer i ct-ops som jag skulle vilja höra om ni vet något
om.
Vid run-cosmos -v ser jag dels
--8<---------------cut here---------------start------------->8---
70run-post-tasks: invoking /var/cache/cosmos/model/post-tasks.d/018packages
WARNING
WARNING - attempting UNSAFE installation/upgrade of puppet-module from
WARNING
--8<---------------cut here---------------end--------------->8---
och dessutom
--8<---------------cut here---------------start------------->8---
Error: Duplicate declaration: Package[cpu-checker] is already declared; cannot redeclare at /etc/puppet/cosmos-modules/sunet/manifests/cloudimage.pp:22 on node f1.ct.not
Error: Duplicate declaration: Package[cpu-checker] is already declared; cannot redeclare at /etc/puppet/cosmos-modules/sunet/manifests/cloudimage.pp:22 on node f1.ct.not
--8<---------------cut here---------------end--------------->8---
Det senare tror jag Leif är lite halvt ansvarig för efter en ändring i
puppet-sunet/manifests/cloudimage.pp tidigare idag:
ensure_resource('package',['cpu-checker','mtools','kvm','libvirt-bin','virtinst'],{ensure => 'installed'})
Hur fixar jag det?
Varf får jag (alltid?) samma felmeddelande två gånger?
Varför klipper någon av felutskrifterna sådär?
Kan jag använda scriptherder för att förbättra något av detta?
Det förra ("attempting UNSAFE installation/upgrade") beror nog på knasig
("") $src i 018packages. $src kommer från
while read module src update pattern; do
men vad kommer på stdin? Varifrån kommer det?
Är det något som hindrar att vi lägger till https:// där?
git-protokollet är vare sig autenticerat eller insynskyddat. Ser ingen
anledning att stödja det alls egentligen men oavsett det så borde vi
köra https där det går.
Tack,
Linus
Hej!
Jag vill att min docker-container som kör en web-server skall vara
tillgänglig över IPv6 men jag vet inte hur det skall gå till.
John berättade att (någon del av) eduid NAT:ar (redirectar) inkommande
v6 till v4 men vi kunde inte hitta var det händer.
Någon som vet?
Hej!
Det här i nunoc-ops/global/overlay/etc/puppet/manifests/cosmos-site.pp
--8<---------------cut here---------------start------------->8---
node 'web.nordu.net' {
sunet::docker_run {'software_web':
image => 'docker.sunet.se/web_software_ndn',
ports => ['80:80', '443:443'],
volumes => ['/usr/local/etc/software.nordu.net/lighttpd:/etc/lighttpd',
'/usr/local/etc/software.nordu.net.local/lighttpd/certs:/etc/lighttpd/certs',
'/usr/local/src/radsecproxy-web/html:/var/www/html/radsecproxy']
}
}
--8<---------------cut here---------------end--------------->8---
ger det här vid run-cosmos -v
--8<---------------cut here---------------start------------->8---
70run-post-tasks: invoking /var/cache/cosmos/model/post-tasks.d/030puppet
Info: Loading facts
Info: Loading facts
Info: Loading facts
Info: Loading facts
Notice: Compiled catalog for web in environment production in 0.21 seconds
Info: Applying configuration version '1449495948'
Notice: Finished catalog run in 0.07 seconds
--8<---------------cut here---------------end--------------->8---
men jag har inte någon sådan "startup-fil" som det påstås att man skall
få
--8<---------------cut here---------------start------------->8---
root at web:~# ls -l /etc/init/docker*
-rw-r--r-- 1 root root 1533 Nov 20 13:47 /etc/init/docker.conf
--8<---------------cut here---------------end--------------->8---
Tips?
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.
