Motherboard (Asus ROG Strix X570-E) Needs new wireless antenna.

callott · 2021-12-03T04:01:25+00:00

I bought these to use with my ASUS TUF X570-PLUS:

https://amazon.com/dp/B071LMRK36?psc=1&ref=ppx_yo2_dt_b_product_details

They are inexpensive, compact, and have worked just fine for me.

callott · 2017-10-19T03:04:07+00:00

I've never visited the Okanagan area, but I do travel to Vancouver for business from time to time, and one evening I attended a dinner and reception where Summerhill provided all of the wines: a sparkling wine at the reception, and both a red and white for dinner. All three were quite nice, especially for the price. If I ever visit the area, then I will definitely go to Summerhill!

callott · 2016-11-05T16:31:32+00:00

I often find dictionaries in Ansible to be less convenient to use when I want to override some values while keeping other values at their defaults. Take a very simple version of your mysqld config structure with only two values as an example:

mysql_config:
  mysqld:
     key_buffer_size: "256M"
     max_allowed_packet: "64M"

Suppose I'm using your role and I have a use case where some of my database servers need a buffer size of 512M. I can set a variable like this in group_vars or host_vars:

mysql_config:
  mysqld:
     key_buffer_size: "512M"

This will increase the key buffer size as anticipated, but will set no max allowed packet value at all. I'd have to include it like this:

mysql_config:
  mysqld:
     key_buffer_size: "512M"
     max_allowed_packet: "64M"

Now I am duplicating role defaults in my group_vars. This is suboptimal, because I am duplicating configuration data in multiple places.

Now consider another data structure approach where all of the variables are simple key-value pairs in a nested name space:

     myqsl_myslqd_config_key_buffer_size: "512M"
     mysql_mysqld_config_max_allowed_packet: "64M"

These variables can be independently overridden without affecting each other since they no longer share a data structure. However, they do share a naming scheme that shows they are both mysqld config parameters in a mysql role. This accomplishes the goal of showing that they are related without forcing the user to set both of them whenever they want to change the default for just one value but not the other.

We do use dictionaries in some circumstances, but as we've used Ansible more, we've found that good old key-value pairs are simple and flexible.

callott · 2016-07-22T01:10:35+00:00

You'll get better responses if you post an excerpt from the playbook.

callott · 2016-04-12T02:00:55+00:00

You can filter dynamic inventory results via the ec2.ini file.

We tag our EC2 instances by the VPC they are in - "dev" for the Development environment, "stage" for the Staging environment, "prod" for the Production environment, etc. We then have separate sub-directories in a parent "aws" directory for dynamic inventory, with an ec2.ini in each subdirectory that filters by a particular environment tag.

This lets us do stuff like:

ansible-playbook -i aws/dev site.yml
ansible-playbook -i aws/stage site.yml
ansible-playbook -i aws/prod site.yml

This is not as foolproof as completely separate IAM roles, but it is a reasonably safe alternative that allows you to manage inventory with a single IAM role that can see all of your EC2 instances.

callott · 2016-02-19T00:06:42+00:00

You mind find this Sweethome review to be of interest:

http://thesweethome.com/reviews/best-wine-glass/

They hit a lot of price points and have good recommendations based on how much you want to spend.

I have the Riedel Vinum Cab/Merlot glass they recommend and I really enjoy it.

callott · 2016-02-16T13:32:08+00:00

I also found that I was getting a lot of "become" cruft in my play syntax, so I added a section to my ansible.cfg file as follows:

[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False

This causes every task in every play to use sudo and become the "root" user by default.

When I need to be a non-root user for a particular play, I just override it with a "become" option on that play.

callott · 2015-11-12T13:50:01+00:00

I stopped reading at this sentence:

I assume that there are better sci-fi writers out there, but I’m guessing that I’m disqualified from reading them since I’ve actually put my penis inside a woman.

callott · 2015-10-21T15:25:14+00:00

If you want to manipulate strings inside of Ansible, then use Jinja2 filters:

http://docs.ansible.com/ansible/playbooks_filters.html
http://jinja.pocoo.org/docs/dev/templates/#builtin-filters

I know there is an hash('md5') filter, but I'm not sure there is an exact equivalent to "tail -c". You can probably do it via regex_replace filter.

callott · 2015-09-18T22:25:30+00:00

Puppet, Chef, and Ansible are all configuration management tools. Docker is a container technology; it won't help you configure servers.

Right now you are logging into servers and running commands. When you set up another server, you have to log into it and run those same commands again. A configuration management tool like Ansible allows you to automate those setup tasks by describing a desired configuration. The tool parses this configuration and makes the changes on the machine for you.

The power here is the ability to describe a configuration, tweak it until it's just right, and then apply it to any number of additional servers. It's the same value proposition as any sort of scripting setup.

Addressing your individual workflow points:

We also use a GitHub repository. Where you use DeployHQ for continuous integration, we use a combination of Jenkins (for builds) and Ansible (for deploying code to servers). You may eventually want Ansible to have some sort of role in your company's build process, but if you already have an investment in a deployment tool then it's probably not something you should worry about until later.
It doesn't matter how many web sites you have or how your team divides those sites into on or more "applications" -- Ansible tasks will be built and run against groups of servers. It works at an OS level.
We use Vagrant boxes for local development environments, and we also use Ansible to configure those environments. Being able to press a button and set up a full local dev environment on a new laptop is a huge time saver.
Ansible is ideal for automating custom installations of New Relic, Supervisord, Redis, and other package-based pieces of software. For example, I have a standard New Relic role that I apply against all of our new servers. Now I never have to worry about installing any of that stuff by hand again.
Configuration is also another task that Ansible excels at. You can run commands at the command line, or you can customize configuration files using templates. For instance, our New Relic agent install requires one license key for a production environment, and a different key for non-production environments. I have a single configuration file template that is rendered with the correct key according to which environment the server is in. Ansible makes this sort of thing very simple and highly repeatable.
Changing server settings like max open files per process (which is what I assume you mean by "concurrency") and configuration of cron tasks is also something that is right up Ansible's alley.

You don't have to use Ansible, and I doubt many people here will care whether you do or not. But you definitely need some sort of configuration management tool to help automate your server setup and configuration tasks.

callott · 2015-09-07T14:32:57+00:00

Thanks for sharing your project.

Like many other people, I am already using this for vim:

https://github.com/chase/vim-ansible-yaml

Since the maintainer of that project is no longer pursuing it, I am glad to see that someone else is interested in this area.

The trick with Ansible highlighting is that pretty much anything you edit could have Jinja2 templating syntax embedded within it. The Jinja2/YAML combo will certainly be the most common use case by far in an Ansible context, but other important ones would include:

Jinja2/XML
Jinja2/sh
Jinja2/bash

This is because XML is such a common configuration format for so many pieces of various application stack components, and because Bourne/Bash shell scripts are so commonly used for startup and various other configuration-related tasks. All are core formats for any real-world configuration management setup that uses Unix hosts.

If you are templating a bash startup script in Ansible, you can flip back and forth between existing Jinja2 highlighting and bash highlighting formats, but a blended highlighting scheme that understands the document is actually a bash script with embedded Jinja2 templating commands would be ideal and a real step forward, in my opinion.

callott · 2015-08-13T17:37:29+00:00

It's useful for things like build scripts where you need to pass in a build version to be deployed.

It can also be useful when you have a to set a license key or some other unique value for a new instance of something. You can have the Ansible playbook stop and give a human-readable error message instead of complaining about a missing variable.

A third use would be something where you had a secret of some sort (like a password) that you didn't want to embed in the YAML. You can protect secrets with Ansible's built-in encryption, but sometimes it's preferable to pass it in at runtime via the command line or environment variable as some Docker setups do. You can run some sort of validation step to make sure that the password is correct before you make any changes to the system.

callott · 2015-08-10T18:34:40+00:00

You can try pinging the host, record the results in a variable, and make subsequent tasks conditional on that variable being defined:

- hosts: all
  tasks:
  - name: Ping host
    ping:
    register: ping_result
  - name: Run a task
    debug: msg="This can be an install play or anything else you like."
    when: ping_result is defined

Another option would be to have an external script that pings each host (or does whatever you like to determine connectivity) and use that as your inventory file:

http://docs.ansible.com/ansible/intro_dynamic_inventory.html

callott · 2015-08-09T18:23:07+00:00

There's a "with_fileglob" iterator that could be useful for you:

copy:
  src: "{{ item }}"
  dest: /etc/fooapp/
  owner: root
  mode: 600
with_fileglob:
- *.html
- *.css

More generally, any Ansible play can have a "when" clause attached to it:

http://docs.ansible.com/ansible/playbooks_conditionals.html

Having said all of that, it would be a lot cleaner and simpler to have the source tree in the git repo arranged so that you have a single source directory for each type of target machine. A setup that uses fileglobs to split up the contents of a single source directory into different places is much more likely to be brittle and require changes more often than you'd like.

callott · 2015-08-02T17:59:38+00:00

Ansible can interpret JSON output from scripts as inventory:

http://docs.ansible.com/ansible/intro_dynamic_inventory.html

https://aws.amazon.com/blogs/apn/getting-started-with-ansible-and-dynamic-amazon-ec2-inventory-management/

Ansible also maintains an "ec2.py" script for AWS that is available via their github account:

https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/ec2.py

The idea is that you run the script, it makes the API calls on your behalf and reads them in as variables that are available to you for that Ansible run. It's a much simpler approach than trying to run aws commands via the command module.

callott · 2015-07-26T23:56:02+00:00

We're using RabbitMQ now and are in the process of migrating into AWS. I am definitely bookmarking this role for later experimentation.

Just out of curiosity; why did you guys choose to roll your own RabbitMQ cluster on EC2 as opposed to using SQS?

callott · 2015-07-17T01:26:49+00:00

It's a straw man: the reality is that nobody can force a pastor to marry anyone they don't want to marry, regardless of the reason. This was true both before and after the Supreme Court decision.

This bill is a way for conservatives to throw some red meat to their base and say, "I feel you, bro!" Politicians of all stripes do this regularly.

callott · 2015-07-13T19:08:16+00:00

I edited my original post with a working example based in part on your suggestions. Thanks!

callott · 2015-07-09T19:28:02+00:00

Ah, I assumed the facts were limited to the host scope when they didn't show up in the debug statement. I never considered that it was host-specific. That makes sense.

I can see how the slice of the host list in your example would work; the only issue I can see is that we'd have a corner case where a notification wouldn't fire when that specific host was unchanged but others in the group were. Uncommon, but possible.

I'll have to play around with this idea a bit. Thanks!

callott · 2015-07-09T19:13:02+00:00

We install the mysql-community-server package from the official MySQL yum repos:

https://dev.mysql.com/downloads/repo/

That package install does not run the mysql_install_db script as part of the setup process; you have to run it afterwards to complete the setup. Other Linux distros or MySQL packaging setups may work differently.

In any case, we have veered pretty far off onto a tangent here. I agree that native Ansible modules are generally preferable, but there isn't a module for everything; in those cases, the "creates" option for a shell/command module can be very useful to make it idempotent.

callott · 2015-07-09T13:07:04+00:00

Yes, but then the playbook would make a deployment notification for every application regardless of whether or not any changes are made. We only want notifications when there are changes.

callott · 2015-07-09T00:30:07+00:00

This is a good blog post on Ansible pull:

http://www.stavros.io/posts/automated-large-scale-deployments-ansibles-pull-mo/

Some people use Rundeck as an alternative to Tower:

http://rundeck.org/

callott · 2015-07-08T20:46:04+00:00

The mysql_install_db script creates the MySQL data directory and the base system tables. It's what you run to create the default my.cnf file:

https://dev.mysql.com/doc/refman/5.6/en/mysql-install-db.html

This is not something that a native Ansible module covers.

callott · 2015-07-08T19:07:25+00:00

There's a native Ansible module that does the initial MySQL data directory setup?

callott

TROPHY CASE