Segmentation is your fault, PIKT
Working with PIKT. I got around to the keys.conf
documentation.
Looked pretty neat, I decide to tell PIKT to distribute
PIKT.conf. (BTW, don’t get too distracted and read keys.cfg
instead of keys.conf. I named the file keys.cfg and got kind
of confused for a while because PIKT.conf was showing things like
private_key CHANGE_ME.)
[root@piktmaster /usr/local/pikt/lib/configs]# piktc -pv +H piktmaster processing piktmaster.mydomain.net... killing daemon (piktc_svc)... root@piktmaster.mydomain.net's password: installing PIKT.conf... root@piktmaster.mydomain.net's password: PIKT.conf 100% 186 188.6KB/s 00:00 PIKT.conf installed restarting daemon (piktc_svc)... root@piktmaster.mydomain.net's password: determining piktc_svc pid... Segmentation fault (core dumped)
This led me digging with GDB, looking at the output of rpcgen, and
looking at PIKT sources. Finally I determined two things. First, the
problem is the lack of register_request() being called in
src/piktc/rpcclnt.c in the install_piktconf() (IIRC) function
before piktc_svc_pid() is called. I put some
register_request() around it and no more SIGSEGV. Second, this
SIGSEGV was kind of unimportant. At this point PIKT has already done
as much as it’s going to do. All it’s trying to do at that point,
AFAIK, is make sure that piktc_svc restarted by getting its PID.
So maybe I could have ignored it, though it might have mucked up
distributing to multiple hosts. Hopefully I’ll remember to make and
send a patch to the PIKT team/author tomorrow.
Of course, now that I’ve got all this working, I notice that PIKT is
leaving ssh processes around after distributing PIKT.conf. Wonder
if I’ll fix that or not…
Oh, and I’ve noticed that PIKT is picking different ports to listen on after every invocation. Joy! I’ll have to fix that so I can sic various packet filters on it. Sometimes I wonder if I shouldn’t be running IPSec internally.
Then I realize that it’s easily 1.5h past when I wanted to go to bed, so I shut up and go do that.