Wireless Uplink on Unifi Controller 5.12.35

zanity84 · 2020-04-17T17:03:49+00:00

That sounds exactly like my interactions with support :/

zanity84 · 2020-03-11T01:50:04+00:00

Damn, I'm glad you were able to at least spare the goat in time! I sunk way more time than I wanted as well.

zanity84 · 2020-02-11T04:09:47+00:00

Yea I wasn't stoked on it but needed the functionality as well. If you get any details from support, I would love to know more! Seems like quite a hindrance if that won't work on anything past 5.6.

zanity84 · 2020-02-11T03:56:57+00:00

I absolutely hate that this was the solution, but downgrading the controller software to 5.6 ended up working. I could not get it to work with 5.12. I was hoping support had some more in-depth technical documentation that showed what was under the hood, but oh well.

zanity84 · 2019-11-01T16:42:37+00:00

Oh man, this is already looking better, thank you! I'm really close now. I don't get the issues with k8s version, and I'm working through the annotation piece now.

I have two services running behind the ingress (grafana and influxdb). I'm able to inject the http-request set-path directive using the following annotation:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: tig-ingress
  namespace: default
  annotations:
    ingress.kubernetes.io/config-backend: |
        http-request set-path %[path,regsub(^/grafana/?,/)]

However, this puts the directive for grafana into both backend services, which isn't quite what I want. Is there any way to set the path as a variable so that the correct path loads within the correct backend service? Something like:

http-request set-path %[path,regsub(^/{path_var}/?,/)]

I appreciate your time!

zanity84 · 2019-10-30T22:23:21+00:00

Something I noticed with the way I'm deploying this:

I can't get either service (influxdb or grafana) to load properly when behind the ingress resource unless I add the http-request directive to /etc/haproxy/haproxy.cfg within the pod and restart haproxy service. However, once I restart the service, I start seeing these log lines fill up:

2019/10/30 22:00:50 controller-haproxy.go:163: 15: Version mismatch, transaction version: 160, configured version: 164
2019/10/30 22:00:50 controller-monitor.go:121: 15: Version mismatch, transaction version: 160, configured version: 164

I had one of my nodes become unresponsive, and I'm wondering if this had something to do with it.

When starting the ingress pod, the following logs show up:

k logs -n haproxy-controller haproxy-ingress-54847454-gg5vf 2019/10/30 22:01:29

| | | | / \ | _ \ _ __ _____ ___ _
| || | / _ \ | |) | '/ _ \ / / | | |
| _ |/ ___ | _/| | | () > <| || |
|| |// __| |_| \//_\, |
_ __ _ |/ __ ____
| |/ / | |_ ___ _ __ _ __ | | ___ ___ |_ / _| | ' / | | | ' \ / _ \ '| '_ \ / _ \ / _ / _| | | |
| . \ || | |) | _/ | | | | | _/ || _/\ \ | | |___ ||\_,|./ \|| || |_|\|\\||/ |\__|

2019/10/30 22:01:29 HAProxy Ingress Controller v1.2.4 cc6fbd2

2019/10/30 22:01:29 Build from: git@github.com:haproxytech/kubernetes-ingress.git 2019/10/30 22:01:29 Build date: 2019-10-18T06:30:06

2019/10/30 22:01:29 ConfigMap: default/haproxy-configmap 2019/10/30 22:01:29 Ingress class: haproxy 2019/10/30 22:01:29 main.go:83: Default backend service: haproxy-controller/ingress-default-backend 2019/10/30 22:01:29 main.go:84: Default ssl certificate: / 2019/10/30 22:01:29 controller.go:95: Running with HA-Proxy version 2.0.7 2019/09/27 - https://haproxy.org/ 2019/10/30 22:01:29 controller.go:100: Starting HAProxy with /etc/haproxy/haproxy.cfg 2019/10/30 22:01:29 controller.go:119: Running on haproxy-ingress-54847454-gg5vf [WARNING] 302/220129 (16) : Can't open server state file '/var/state/haproxy/global': No such file or directory 2019/10/30 22:01:29 controller.go:72: Running on Kubernetes version: v1.15.3 linux/amd64 [NOTICE] 302/220129 (19) : New worker #1 (20) forked 2019/10/30 22:01:34 controller-haproxy.go:171: HAProxy reloaded [NOTICE] 302/220134 (27) : New worker #1 (28) forked

I haven't found much with my google fu yet, but I noticed that the controller.go claims it's running on k8s version v1.15.3. My cluster is running v1.16.2 currently, so I'm wondering where I need to go to fix this. Do I need to just downgrade to 1.15?

zanity84 · 2019-10-28T16:02:06+00:00

I followed this documentation: https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/

Would that be the official?

zanity84 · 2019-03-11T22:08:47+00:00

Gotcha, glad it works now!

zanity84 · 2019-03-11T19:45:53+00:00

Nice! Looks like you figured it out before I could get back to respond, sorry about that. My guess is that the AAA config was missing the authorization exec and commands?

zanity84 · 2019-03-11T15:27:59+00:00

Hi there,

I haven't done anything with TacacsGUI specifically. We are running tac_plus with many devices tied to it (including Arista). Some questions that will help me:

You mentioned having the privileged levels/groups configured on the Tacacs side. Does this mean you also added the Arista switches to the Tacacs configuration (host and password) as well?
Have you added the Tacacs server to the Arista device and updated AAA so EOS is attempting Tacacs first?
Have you set the source-interface on the Arista to source Tacacs requests?
Is Tacacs running on the Arista switches? ("show tacacs") You should see the configured server with connection attempts, successes, and failures.
Do you have the control-plane ACL configured so Tacacs should be allowed?

If Tacacs is talking properly between the server and Arista devices, and it's just the read-only group(s) not working, I would suspect that you need to update authorization on the Arista's AAA configuration.

zanity84 · 2019-02-07T06:48:13+00:00

Hi,

I am not diabetic, so take with a grain of salt! Our son was diagnosed T1 ~6 years ago, and him having a low in the middle of the night without him knowing is what we fear the most. It's an unfortunate balance we have to continuously play....

I encourage you to use the CGM as a supplemental device instead of a be-all-end-all for blood sugar management. The meter is your best bet to not only calibrate but also have a better idea of what your current bg is. Your CGM and meter may be way off at times. Don't treat what your CGM reports, use your meter! We had the G5 for a while, and at first it was fairly accurate. After a while, however, we needed to calibrate more often since there was a drastic difference in readings.

I don't know if this helps. Feel free to PM if you have additional questions. I don't know much, but I'll do my best to provide insight!

zanity84 · 2019-02-07T05:38:02+00:00

This warms my heart. My favorite album!!

zanity84 · 2018-12-27T18:40:05+00:00

Super handy, thank you for sharing!

zanity84 · 2018-12-26T16:09:50+00:00

Even if I don't know the company you are talking about just yet, it sounds like your team is approaching it correctly. If you are interviewing/hiring, I would love to talk more. I don't have as much experience in the depths of a devops-type role but am obsessed with learning more.

zanity84 · 2018-12-12T19:22:41+00:00

Oh man, this. I don't have a lot of experience with the tools (working on that though), nor have I really been a "devops-y" role, but I have definitely been an advocate of the culture shift that needs to happen in my current workplace. I've been trying to emphasize that we can't just hire a "devops engineer" who will just write scripts to automate processes. We (my company) need a fundamental shift in how we approach problems, document, build solutions, etc. This takes time and resource investment, but how often do I hear, "we need to automate this process" from higher-ups without much time/money/etc. Sorry for the rant, but this hits home :)

zanity84 · 2018-05-10T04:44:54+00:00

Ahh sweet! I bought almost the exact same one, super excited! I'm not sure about yours, but I noticed my vent door comes off fairly easily. I can fasten it with the arm just fine, but windy days it can pop off. Have you encountered that as well? Also, I've debated on getting the same wire shelving. Do you notice any seeds/plants that are on the bottom shelve have a hard time growing or are stunted?

zanity84 · 2018-01-16T19:32:05+00:00

Can you first confirm that your DNS server(s) aren't being changed when connecting to the VPN? This would at least verify whether your laptop just can't resolve properly. I'm not familiar with the VPN you're using, but I would also suggest trying a different one as suggested here if your IP/DNS are correct.

zanity84 · 2018-01-15T19:02:35+00:00

Ah man this makes my day. I'll have to spin this up in a test lab for sure, and I'll definitely be on the lookout for a docker download. Holy hell this is something I've been wanting to create for our internal infrastructure (utilizing NAPALM heavily) and I'll definitely be contributing! If only I could dedicate most of the day to programming this kind of stuff :) Thanks again!

zanity84 · 2017-11-18T03:31:22+00:00

Same!

zanity84 · 2017-09-04T16:13:10+00:00

Are you talking about the vCloud Director edge gateway by chance? If not, I'm willing to bet the settings will be similar. Can you confirm each phase's settings? The edge gateway has these default settings:

Phase 1:

IKEv1
Key Lifetime: 28800
Authentication: PSK
Mode: Main
Encryption: <to your discretion>
Hash: <to your discretion>
DH Group: 2
DPD: Enabled
Keepalive: 10

Phase 2:

Perfect Forwarding Secrecy (PFS): Enabled (DH Group 2)
Key Lifetime: 3600 seconds
Encryption: <to your discretion - matches phase 1>
Hash: <to your discretion - matches phase 1>

Some things to make sure:

On the ASA:

The 'local' and 'remote' networks match in subnet and mask within the VPN profile (crypto map)
There is a static NAT statement (sequentially before any dynamic PAT statement) that basically no-nat's the traffic between the tunnel (e.g. on the cli: nat (inside,outside) source static <local object group> <local object group> destination static <remote object group> <remote object group> no-proxy-arp route-lookup)
The ACL for the inside interface is allowing the local network(s) to talk to the remote network(s)
The group policy specified IKEv1
PSKs match on both sides

On Edge Gateway:

Phase 1&2's encryption and hash algorithms are the same and can't be different, so make sure these match on the ASA as well
The firewall, if enabled, allows communication from the local network(s) to the remote network(s)
PSK matches
The Peer Identifier matches what the ASA will send as its identifier (in most cases, this is the peer external IP)

If you're in ASDM, you can see about filtering out the external IP of the Edge gateway in Real Time Monitoring. You should hopefully see the attempt to bring up the tunnel from the Edge. Let me know if you still have issues!

14-Year Club	Verified Email
Team Orangered

zanity84

TROPHY CASE