Disqus - Latest Comments for pilif

Re: Fiber7 & Unifi Security Gateway (USG) mit DHCPv6 Prefix Delegation (DHCPv6-PD)

Philip Hofstetter — Fri, 16 Mar 2018 09:28:52 -0000

ja. das meinte ich. Fiber7 delegiert dir ein /48 und die USG kann dann 65536 /64er Netze erstellen.

Die Delegationsgrösse seitens provider ist fix. Fiber7 ist einfach sehr grosszügig.

Re: Fiber7 & Unifi Security Gateway (USG) mit DHCPv6 Prefix Delegation (DHCPv6-PD)

Philip Hofstetter — Tue, 13 Mar 2018 14:31:49 -0000

/64 ist die Standardgrösse für ein ipv6 Netzwerk. Fiber7 delegiert dir ein /48, welches dann deiner USG erlaubt, 2^16 (also 65536) /64 Netze zu erstellen.

Re: Slow PostgreSQL Performance? Don't Forget to Vacuum your Database

Philip Hofstetter — Fri, 10 Jul 2015 14:40:01 -0000

Yeah. Sure. The index can potentially hurt insert performance, but you should still try it. The index in question would be small and quickly written and it would be a huge help for the read performance.

Re: Slow PostgreSQL Performance? Don't Forget to Vacuum your Database

Philip Hofstetter — Wed, 08 Jul 2015 23:47:12 -0000

As I have said in the reddit thread (https://www.reddit.com/r/Po... you are likely missing an index that covers charges.date_created.

Of the two sequence scans you are making, the one on `charges` is suspicious; the one on users is likely unavoidable but also shouldn't take very long as there won't be as many users as there are (hopefully) charges.

In general, please post the output of `explain analyze` instead of plain `explain` as that shows the real world instead of just planner guesses.

Generally you should not need to have to tweak autovacuum parameters too much.

Re: do not fill this field: serialize() output is binary data!

Philip Hofstetter — Wed, 13 May 2015 07:57:36 -0000

There are multiple encodings here at place as there's the encoding the data is actually stored at and there's the encoding chosen by your application via the client library.

Ideally, you do not have to care about what encoding the data is stored in in the database itself because the database client (or the server - that's really an implementation detail) would transcode for you on the fly.

So that means that normally, you would not change the encoding of the data that is stored (especially as that would mean rewriting all the data), but you would tell the client to give you the data in a different encoding.

This would then change the binary representation of the data.

And this is what has happened here.

On serialization, we have serialized data with one byte per character and stored that as text, in the same encoding that was used to serialize the data in. Then, we changed the encoding we wanted data to be given to us in to utf-8 and that's what we got back, using two bytes to encode some characters.

This then caused the unserializing process to fail because the byte counts as read from the database (two bytes for some characters) did not match the expectation (one byte per character) that was encoded into the serialized stream.

Re: pdo_pgsql needs some love

Philip Hofstetter — Wed, 25 Feb 2015 01:55:12 -0000

Python and Ruby have proper support for some of the extended data types in Postgres. I know for certain about array and hstore support and I would assume that they will be getting json support soon too - especially now with jsonb in postgres.

Btw: Last year, I was working on adding support for JSON and arrays to pdo_pgsql. I've blogged about it here: http://pilif.github.io/2014...

When I sent a probing mail to php internals whether there would be potential interest and whether I should try and craft an RFC, I never got a response though (and non-developers can't write RFCs to begin with).

As such, this is probably going to bit-rot now.

Re: do not fill this field: Why is nobody using SSL client certificates?

Philip Hofstetter — Wed, 22 Jan 2014 06:56:25 -0000

usually, the private keys used for SSH are encrypted, so you do have to type in a password.

Malware could still be abusing the SSH agent though, so, yes, adding an additional hurdle might make sense.

For OpenSSH, there's no such configuration option, but maybe you can do something using PAM to force that - it'll annoy your users though as scp and friends now suddenly ask for passwords despite the agent being installed.

Re: Gordon Diggs - Rails Edge Case: ID Overflow

Philip Hofstetter — Tue, 21 Jan 2014 05:07:36 -0000

While hitting the boundaries of a 32bit int is within the realm of actually happening, I seriously doubt the 64bit boundary is something we have to keep at the back of our heads for quite some time into the future

Using UUIDs solves the problem for all eternity of course, but it lacks some nice properties which sequences have - like getting a free way of ordering records by creation time (ordering by a timestamp might not be sufficient as they aren't high enough resolution to be guaranteed unique).

Personally, I'd go with a BIGSERIAL (bigint backed by 64bit sequence) and stop worrying.

Re: pdo_pgsql needs some love

Philip Hofstetter — Wed, 11 Sep 2013 10:58:30 -0000

never. But in this case I'm using multiple databases at the same time (ours and the ones we import data from). Having just one API is quite convenient.

I see no reason why a postgres-specific PDOStatement subclass couldn't deal with postgres' types though.

What would be great is having a database-specific layer that also implements parts of PDO or at least provide a way to convert between PDO objects and database specific driver objects.

Re: pdo_pgsql needs some love

Philip Hofstetter — Wed, 11 Sep 2013 03:39:02 -0000

That's really cool! If I weren't locked into PDO now (newrelic supports only PDO, my wrapper is tightly wrapping around PDO), I would really consider switching over.

I'm interested: What was your reasoning behind not going the PDO route?

Re: when in doubt - SSL

Philip Hofstetter — Thu, 05 Sep 2013 03:17:07 -0000

Are you guys having the same issue? ;-)

Re: do not fill this field: Why is nobody using SSL client certificates?

Philip Hofstetter — Fri, 12 Jul 2013 02:35:24 -0000

I would contend that OAuth is actually more burdensome on the application developer on both ends. Adding client certificate support to both the server and the client (using native HTTP libraries) is trivial.

HTTP libraries are older and thus much more mature than the various OAuth libraries in various languages.

Also, debugging in curl is immensely easier with client certs than with oauth.

Re: why I don't touch crypo

Philip Hofstetter — Fri, 12 Jul 2013 02:30:54 -0000

yes. I agree. It *is* fun. But when you are at a point where the complexity of writing the test case matches the complexity of writing the code to be tested, you can't be sure whether your failing test fails because of a bug in the test or the tested code.

If it passes, you can't be sure whether it passes because the code is fine or because of a bug in the test.

Re: why I don't touch crypo

Philip Hofstetter — Fri, 12 Jul 2013 02:28:48 -0000

Totally agreed, but then Cryptocat is open source and still was badly vulnerable for most of its existence. Being open source at least allows for code reviews. Whether they happen or not is another question.

Re: why I don't touch crypo

Philip Hofstetter — Fri, 12 Jul 2013 02:27:15 -0000

Yes it would, but I would contend that getting the test right is nearly as hard as getting the code-to-be tested right to begin with.

You have two options: Either you use an external tool, but then you have to integrate this into your test suite, or you reimplement the test in JS, exposing you to the possibilities of writing a buggy test.

What I meant was that writing the test is nearly as complicated as writing the code in the first place.

Re: background events

Philip Hofstetter — Wed, 06 Mar 2013 09:39:31 -0000

That's certainly the way we prefer to go. The problem is that there are too many prices and calculating them takes too much time (as evidenced by the trouble we have to go through).

The prices change multiple times a day and a full export of all prices would take 27 hours.

The other solution is to mirror the source tables from SAP, but then we'd have to rebuild the whole price finding logic on our side which isn't feasible in any reasonable amount of time because a) the logic is bloody complicated and intransparent to begin with and b) changes about weekly.

Re: JavaScript and Applet interaction

Philip Hofstetter — Mon, 04 Mar 2013 02:41:43 -0000

The whole concept of a signed applet with full machine access is crazy to begin with. Once you accept that and let that pass, I don't see much difference to using DoPrivileged.

The real solution is to not use java at all. There are other means for getting access to the local hardware that come with fewer additional security problems (just look at the news about Java flaws recently)

Re: A love affair with PostgreSQL [Rails 4 Countdown to 2013]

Philip Hofstetter — Wed, 02 Jan 2013 11:38:16 -0000

At least add a note then recommending against creating the index for now. Both gist and gin indexes are comparably expensive to maintain, such that it IMHO makes no sense to do that work if no query can actually take advantage of them.

Or, of course, fix rails. It shouldn't really be parsing the SQL to begin with

Re: A love affair with PostgreSQL [Rails 4 Countdown to 2013]

Philip Hofstetter — Wed, 02 Jan 2013 08:20:44 -0000

The -> hstore operator can't use the index. You should make a note of that in the article. See my note on HN here https://news.ycombinator.co...

Re: do not fill this field: Google Apps - Provisioning - Two-Legged OAuth

Philip Hofstetter — Tue, 25 Sep 2012 02:39:28 -0000

as you are writing to the API, you'd probably have to remove the #readonly from the scope declaration.

It's just a guess - I've never written to the API myself - only ever read.

Re: Logging to JSON format in nginx. - pkhamre.blog

Philip Hofstetter — Thu, 23 Aug 2012 07:07:40 -0000

Be careful: Between two (referrer, user agent) and four (request method, remote_user) can be set by the end-user and thus can cause the JSON to be invalid (i.e. set the user-agent to "}).

As long as nginx doesn't have explicit JSON support, I would recommend against manually building JSON and stick to combined log which is well-supported by logstack.

Re: Disable GateKeeper in Mac OS X 10.8 Mountain Lion

Philip Hofstetter — Mon, 20 Aug 2012 10:31:57 -0000

Or you could do what the last dialog says which is to right-click a specific file and select "Open". This has the advantage that you can decide in a case-by-case basis.

That way you can, for example, install MAMP in this case, while $TROJAN abusing the latest security flaw in Flash still gets blocked from launching anything.

Re: E_NOTICE stays off.

Philip Hofstetter — Thu, 03 Nov 2011 14:58:29 -0000

Back in the days (of PHP and early 4), the @-operator was said to be extremely slow which is why I didn't even consider it.

But now thanks to your pointer, I did test it again (I've updated the test script in the gist above). It's still 50% slower than just turning off E_NOTICE, but I don't think this would really have an impact in the real world

Notices off. Array 100000 iterations took 0.102854s
Notices on. @-operator. 100000 iterations took 0.163940s

That still leaves the fact that it's my strong believe that code like

$options['a'] = $options['a'] ?: 'foobar';

should never raise anything anyways.

Still. Thanks a lot for the pointer. I might actually consider this.

Re: do not fill this field: Lion Server authentication issues

Philip Hofstetter — Mon, 31 Oct 2011 18:41:56 -0000

I actually might have only just today. If I really solved the problem, I'll post a followup.

Question: did you too see log entries about misconfigurations in hash 'Kerberos'? I think the two issues are related and now I know how to fix the latter.

Re: E_NOTICE stays off.

Philip Hofstetter — Thu, 06 Oct 2011 15:04:13 -0000

When I look back at this code, while I agree that I had issues with people accessing not-always-defined variables, that wouldn't have been caught any earlier with E_NOTICE because the code blew up regardless.

So it's not as if I would ever have been burnt by not running with E_NOTICE for the last 8 years. I do want to get rid of the remaining issues though which is what PhpStorm is incredibly helpful for.

My plan was to enable E_NOTICE to make sure nobody creates new mistakes, but I don't want to trade in the nice and readable syntax for a bit of insurance. I'd rather review the commits going in and ask for beer if something isn't right :p