##osx-server

Nick_ZWG: it’s designed to sit behind something else that’s doingng ssl

**doing

Since a plist key of "Identifier" is not the same a plist key of "IDENTIFIER"

grahamgilbert: https://gist.github.com/nmcspadden/883b1cccc8ac... is what I'm seeing right now

Starting with a completely fresh install

Means it can’t connect to your postgres database I think

gneagle: Did you see those 2.x fixes to python in the latest release? Neat stuff. SNI support, trusting the system CA roots, etc. Still no decent SSL validation mechanisms, but still, amazed that landed in 2.x

grahamgilbert: Hmm, where is that IP hardcoded then?

Because that doesn't match my current IP...

It’s not

it’s assigned by docker

frogor: No, but only of academic interest anyway

I need to know more info about your setup now..

Hmm, maybe I just need to restart the VM

frogor: Since those changes aren't present in any version of Python pre-installed on OS X.

gneagle: Yup. Even if it landed in 10.11, still not worth using on OS X vs. the APIs.

yeah

Not a lot of additional feedback about the changes in Munki 2.1

Maybe I should declare a release candidate -- or just a release

Still not 100% happy with how I'm handling the CA cert(s).

But it _works_ and working is more important than "perfection"

grahamgilbert: From a completely fresh install, of a rebooted VM, with latest Docker images for sal + postgres: https://gist.github.com/nmcspadden/883b1cccc8ac... (updated gist)

gneagle: Any aspect in particular re: CA cert(s) ?

Nick_ZWG: Which postgres image are you using?

Nick_ZWG: and will also need to see your settings.py

grahamgilbert: The default one? Whichever comes down with "docker pull postgres"

frogor: I import them into the System keychain every time Munki runs if they are in the legacy location(s).

I suppose one approach would be to move/remove them after import

But that might break someone who is testing 2.1 and also _using_ pre-2.1

I could add a extended attribute that told me I already imported them

grahamgilbert: Updated gist with settings.py

oh I wonder...

grahamgilbert: You might find this thread interesting: https://jamfnation.jamfsoftware.com/discussion....

Or Pebble.it might

I might need to rebuild my salWHD image

gneagle: Maybe instead of moving the file, you can make a different file somewhere else / create a setting indicating that CAs have been converted from legacy. But there's the whole 'change the CA certs' process too now that they're in a keychain instead of files

Nick_ZWG: try using the database image specified in the sat image instructions

Hmm. The extended attribute is an interesting idea.

sat? Sal.

gneagle: And that solves the upgrade issue. File replaced = no extended attribute

grahamgilbert: Out of curiosity, what's the difference?

frogor: But here's a failure mode for that: Admin packages some certs from his/her own machine and pushes them out: with the EAs...

Nick_ZWG: It’s at a set version that I know works properly, and it sets itself up if needed. Just pass it the auth details in environment variables

gneagle: Machine-specific extended attribute?

gah

Just an idea.

But a good one

Often difficult to imagine all the ways something can fail

But if there is a way, it will happen

And maybe it's all for nothing

As security won't actually reimport the cert if it's already there.

It just seems wrong to attempt it every time, but if the security binary is doing the same work (checking before importing) then it's kind of silly to replicate that work badly.

grahamgilbert: Thanks, that did it.

I guess the default postgres container made some changes somewhere.

Nick_ZWG: Good stuff

@gneagle ta.

I assume that's a variation on 'thanks'

Whoa. grahamgilbert posting on JAMFNation.

Sorry, my internal translation mechanism that I have to use online borked

macmule: took me a few minutes to remember I had an account

grahamgilbert: nice. That thread went to weird places.

macmule: Inevitably, there's always the "Munki isn't a real product" debate

Which turns into an open source holy war at some point

Sooner or later Richard Stallman's going to show up

Nick_ZWG: I liked the points about, "If your writing your own scripts.. Will JAMF support them?"

I love this bit: "munki will continue to be a side note in enterprise". Kind of like how Apple will continue to be a side note in enterprise...

All because "enterprise" doesn't really mean anything.

gneagle: yea. Lots of odd views there.

My personal favourite response: https://jamfnation.jamfsoftware.com/discussion....

"The fact is you might just have to hire quality admins/engineers rather than button pushers who when they get in a bind just log a support call and go back to playing COD"

Heh

Best line right there.

grahamgilbert: gneagle Yep. My fave.

wow/10

Like the guy who tried to compile a Python script from Hannes in the AppleScript Editor...

Shame he's not in here now. Hunty1 his nick is I think.

Don't get me wrong, JAMF support will help to a point. But some random script & they may point you to JAMFNation.

No-one would expect JAMF to support scripts that didn't come from JAMF.

Or at least _I_ would not expect that.

gneagle: Yep. Does the JSS deliver it correctly? Check. JSS acts as designed.

Nick_ZWG: http://cck2.freshdesk.com/support/discussions/t...

Mike seemed interested for a minute

But then nothing

I tried opening a new issue, but have not seen it "approved"/posted.

So I might be left with hacking it

in response to that quote: Is it sad that where I work if something doesn't work for me the expectation is that I immediately call support rather than spend time fixing it myself?

Avatharian: yes.

The argument is that if support can fix it faster than I could then money is saved and my time not wasted... Which would make sense if I didn't have to sit on the phone with them.

And what if support stinks

or if they were any faster at fixing the problem, which has been a big no in my experience.

Sure -- and _sometimes_ that might even happen.

Man, I'm starting to realize how bass ackward things are around here.

Avatharian: It also doesn't help you develop problem-solving skills or learn more about how the tools actually work

gneagle: Which is why I ignore those instructions most of the time.

The 2 times where I really needed to call support it was to be told that it was a known issue and I needed to wait on a patch =P

Where else should I look for a launchdaemon that is running as root?

Oh ffs

"Where else"?

A third party launchdaemon ended up in /System/Library/LaunchDaemons...

Where else should I look for my keys?

Nick_ZWG: Public shaming of the vendor needed

Nick_ZWG: C'mon: give us a name.

Wait, no, I'm incorrect.

Someone loaded a crontab somewhere

It's doing something that causes all windows to lose focus every 8-10 seconds

I can see it doing it in activity monitor

SEP?

Nope, not that.

I've seen that for about three minutes during the weekly SEP "full scan"

have other folks used loginhooks on 10.10.1+?

Yes

can't tell what I'm doing wrong on 10.10.2

Seem to work, though marczak says he's seen "issues"

Avatharian: for some, yes.

Whoa. Delayed message.

back inna bit

Avatharian: yea JAMF need to post know defects. That's one of the big things I'd like to change. (There are some in the release notes, but between releases is key).

grahamgilbert: i have heard you say a few times that your company would mange munki for people. And it brings up 2 questions, 1. would you help them ramp up there own servers, and continue support. Or does it need to be your servers? And 2. can you beat the price casper is going to charge? Dont mean to put you on blast. Feel free to PM the response

s/know/known/

mikedodge04: Yes to the first, I have no idea what Jamf would charge for this. Do Jamf support Munki….? ;)