DHCPv6, Clonezilla, OVH, DevSecOps

DUID studied depths and details, so annoying. It seems that it's quite hard to tell what's the DUID of the system for Ubuntu systems. For some reason DHCPv6 server now assigns address which is detected as duplicate by DAD on the network and that significantly delays system start. Seems that RFC 6355 defines the type for. I got bit annoyed by seeing type four DUIDs, which weren't in the RFC, but I were looking the old - RFC 3315 -. Interestingly the server I'm using doesn't seem to recognize complete type 4 DUIDs which seem to be longer than DUID-LLT. Once again, more testing and debugging to see which configuration works, when documentation lacks and there's no source access. Also had to read RFC 6842 Which describes Client Identifier Option in DHCP Server Replies. Classic simple problem, but solution contains hundreds of pages of more or less conflicting and irrelevant documentation. In this case the problem after all seems to be that the ZyWALL doesn't support DUID type 4, which is longer than the other types. Finally ended up adding dhclient6.conf file with manually specified randomly generated DUID send dhcp-client-identifier 00:01:00:01:23:c7:69:81:00:19:99:fc:e5:8c which of course worked. One thing I found extremely annoying even verbose output from dhclient doesn't show the DUID request information, nor firewall logs show the DUID information. As expected many network guys suggested simple solution to finding out client DUID, using Wireshark or tcpdump. Sure, both do work. But it shouldn't be this complex after all. Interestingly a few leases in the .lease files got different client identifier than the default DUID defined in network manager configuration. Why? Who knows. As usual one big mess, if you want to really know how things work out, just go and read the source code. Thank god with open source you can do that, with closed source you'll end up with endless and extremely painful testing, let's see if this works out or ...
Once again strange problems with network, Clonezilla and disk image creation. Isolating the actual reason why it doesn't work seems elusive, once again. But now we're doing much more systematic tests to figure out the cause. There's no single obvious reason so far.
Daily Windows fun. Many user accounts are broken and can't login. "The Local Authority cannot be contacted". Great. Everything has been tried, nothing works. Except, deleting the affected user accounts and recreating those. It works like a charm. That's it, the Microsoft way of doing things.
Customer service trolling customers? Yeah, OVH has made it again. I sent some generic feedback about their control panel usability, which makes it really easy to make mistakes or it's a bug. Anyway, it's hard to get things done right, even if it's supposed to be easy. Their answer is that the "email address is unauthorized" and they can't do anything about it. That's awesome attitude. I didn't ask them to change anything, it was totally generic feedback. This is seems to be their standard attitude, first it takes two weeks and then they work hard to give stupidest possible explanation so that they don't need to address the real reason at all. - Anyway, it seems that all of my friends and colleagues whom have services at OVH have been receiving similar "customer service". How about just saying the GTFO? Some of the settings in the billing section are confusing + there's serious lag between the settings and the UI being updated. And the option to "cancel service" is always grayed out, the way to cancel service is to terminate payment and just leave next bill unpaid, then the service will be cancelled. But I would prefer to specifically cancel the services, that are supposed to be canceled.
Listened a few episodes of great show DevSecOps Days which is a OWASP sponsored show. And covers well, lot of legendary and business as usual stuff.
Something different? SOM cruise missile.

2020-04-05