u/killerabbit37

I took this exam last week. Overall, I don't think much core programming is required, the focus is definitely more on the tools. As such, it would be good to familiarize yourself with tools for languages you don't normally use (package managers, etc.). I would definitely say there was more of a focus on ARM/DSC.

I took my exam last week and I did have a lab.

This is exactly it. When you modify the id mapping, you have to rebuild the db. If you want to wipe everything out, stop sssd, wipe out everything in /var/lib/sss/db/* and then start sssd back up.

For realmd, you can use the --automatic-id-mapping=no setting to disable it on join.

For the providers, you can cache all of those in a local folder and download them yourself. Downside is you are obviously on the hook for keeping those up to date since terraform will not automatically download them anymore. You will also have to download all dependencies yourself which once you see how terraform uses the providers you can download them while developing and not run into too many errors.

You can check out the following example (grabbed from this blog) for how to tell terraform to use a specific folder for plugins.

Unfortunately, I can't speak to the git repo issue. You could investigate overriding the terragrunt cache directory to make it a central folder? No idea if that's the solution or not but something to try.

So the terraform modules bit, I assume you are calling your modules in terragrunt with the

terraform {
  source = ../modules/vpc
}

What might be easier is to instead of using terragrunt, you can just call these modules with terraform:

module "vpc" {
  source = "../modules/vpc"
}
module "rds" {
  source = "../modules/rds"
}

And at that point you'd have everything in a single terraform script which I think in your use case would be easier to manage. Going back to my over engineering comment from before, if you do that and have everything in one terraform script, does it make sense to have your components split out into modules? If the code isn't getting reused in other places then modules wouldn't make too much sense. I'm not trying to discourage you, I would definitely use modules if you are trying to learn (because that's the best way to learn), just keep in mind that you can also keep things simple if you want to.

Like azjunglist05 said above, terragrunt was built for a very specific use case and can be unwieldy if you don't have that use case yourself. One alternative to research is terraform workspaces which is a good method for state management for multiple environments.

First off, since I think this might answer question 3, is everything you are deploying going into a single environment? Is anything you are deploying being replicated in any fashion (same deployment in multiple regions/accounts)? This is where terragrunt really shines is the duplication of terraform resources in multiple environments. If you aren't taking advantage of that then you might be making this more complicated for yourself.

Personally, I'm using terragrunt right now to manage our fleet of accounts from a baseline infrastructure level. I'm deploying the exact same thing to numerous accounts in all regions, trying to do that with vanilla terraform while keeping the state separate is pretty ugly (though it's getting a lot better with every new release).

So, to answer your questions..

1: From the sounds of it (might be wrong), you are using terraform modules as terraform source code in terragrunt. You might be able to simplify your code by having live-infrastructure/ha-website be terraform code that just imports all of the modules you need in one location.

But, in case I'm wrong, you can merge the local variables at a higher terragrunt level. For example, in here, it is saying that every terragrunt module is going to do that exact same locals parsing (assuming everything imports from parent folder which is what they are doing). That way you can put common terragrunt code at the top root level and more specific locals parsing at the environment level.

2: Haven't done this myself yet so can't speak to here, I know there's some CI/CD frameworks that are specific to terraform so you could see if those fit your use cases.

3: Hopefully answered most of it above. I think establishing clear dependencies is also key since it is very easy to over engineer it. Like is the vpc being used for anything else? If so, then it probably should be a dependency since multiple modules can import it as a dependency. If it's only being used by the website, then you can probably just package the code up together and there's no need for any dependency mapping.

You can also program macros into it that can record your delays, so you can have a macro bound to a key that will hit:

<space>  
delay 30ms
<space>
delay 30ms

repeat until the key is pressed again so you can toggle that constant jumping.

But programming the pad can be really easy just time consuming. The changes take effect immediately so you can ALT+TAB between the logitech software and your game until you have it just right which makes it easier.

The G13 also has three modes (the M1-3 buttons right above the G1-4 buttons) that can remap the entire pad for that mode. So G-4/10/11/12 typically used for WASD could be mapped to something completely different for a different mode. I played around with setting up one mode for CS:GO that is all buy script macros using the same method that I explained above with using the record macros with the delays recorded.

I found a RedHat 6.2 (Zoot) the other day and now I want to kill it.

We're using Password Manager Pro right now, I hate (hate, hate) the api for it since it is quite redundant. But +1 because it is RESTful. The documentation for the api also seemed to be a bit out of date and missing some key information like once you hit a mystery number of resources some of the endpoints will just stop returning results. The web interface can also get really weird, from what I've seen there is no way to sort the users you want to share resources with, they will show up in whatever order they were imported into the application.

Other than that it isn't too bad, it does AD groups and sharing really well. It does have some nifty features for clipboard support and rdp/ssh.

I don't have too much experience with laptop raid arrays but I would assume somewhere you would be able to tell a controller/motherboard to import your existing configuration. If you do that and it works like expected you should have your RAID 0 array back with no issues at all.

For safety I would recommend keeping track of which HDD was plugged into which port (port 0, 1) and when you recover it to plug it in exact same order/ports.

This is all I thought of

check_mk is amazing, I would highly recommend looking into it.

You could probably xpost this to /r/samplesize as well. I did that for my project and got quite a few responses unless of course you need local people to reply.

This is also on sale over at Massdrop as well if anybody still wanted one.

Or like this

Quickest way to do it is to convert it as a live machine. In converter you should have an option on the first screen of what kind of machine you want to convert. Select the online machine, Linux, and then give it root credentials. You'll have to have root ssh enabled like others have said. Also you'll need to fully qualify the host name since the helper vm will not have the DNS search paths set up. After you get a connection go through the rest of the converter steps and configuration. Double check the disk partitions as well. Converter will guess the sizes based on what it sees through ssh so it might be rounded weird. After that all checks out you can hit start and it will create a shell vm and then basically do a block transfer of the drives over and then it should be an identical clone. Haven't had any issues converting RHEL vms before so it should boot right up. Then of course go through any post convert steps like re-IP if you changed subnets.

I've got one, we were restaging a problematic hypervisor since it was having some strange behavior and it is apparently a really bad idea to have the LUNs to the cluster attached to the host when restaging, especially when the hypervisor install process looks at those LUNs to install the OS to... Of course it wiped a pretty important cluster (~150 VMs) and we spent the next 2 weeks restoring them.

Cortosis armor works really well against a lightsaber and gives the wearer an advantage since it will actually temporarily short out the lightsaber. Imperial Knights wore cortosis armor ~120ABY.

So far it is working fine.

Correct, with the amount you are talking about I don't think you'll run into any issues. The whole idea is to cache the logs between receiving them and indexing them. Indexing takes the longest amount of time and you really wouldn't want that getting backed up because then logs may be getting dropped. On my end I have to worry about over 10,000 nodes so definitely something I had to consider with the addition of making everything scale horizontally.

I heard that nxlog is really good for forwarding Windows logs to Logstash. I hadn't gotten around to playing around with it yet but if you search this subreddit for Logstash you'll get a bunch of hits and some really good discussions in the comments. I'm pretty sure there were a couple links on how to translate the event logs with nxlog and forward them to Logstash.

How big is your infrastructure? I added Redis in the mix and can give you an overview of my application stack if you are interested.

Yep it is free

/r/combinedgifs

Definitely take a look at Icinga 2 (different from Icinga 1 since it is a full rewrite). Native Graphite integration, built in Livestatus module, and much better configurations is a huge plus in my eyes.

If you are using Nagios, the check_openmanage plugin in a life saver. And it collects performance data! I can probably screenshot some of my graphs if you are interested.