How to change the cloud-config to specify a specific version of etcd - coreos

I am using core-os and configuring it with cloud-config files. I need to use a etcd-service for my application.
This is the relevant part of the cloud-config file.
- name: etcd.service
command: start
content: |
[Unit]
Description=etcd
Requires=setup-network-environment.service
After=setup-network-environment.service
[Service]
EnvironmentFile=/etc/network-environment
User=etcd
PermissionsStartOnly=true
ExecStart=/usr/bin/etcd \
--name ${DEFAULT_IPV4} \
--addr ${DEFAULT_IPV4}:4001 \
--bind-addr 0.0.0.0 \
--discovery https://discovery.etcd.io/SOMEKEY \
--data-dir /var/lib/etcd \
--http-read-timeout 86400 \
--peer-addr ${DEFAULT_IPV4}:7001 \
--snapshot true
Restart=always
RestartSec=10s
I am not sure how to update the version of etcd.

Turns out etcd2 is already installed on coreos. It is currently shipped in the coreos-alpha 653 release, alongside etcd.
To change it in the cloud-config, you just have to change
ExecStart=/usr/bin/etcd
to
ExecStart=/usr/bin/etcd2
and remove some flags which are deprecated in etcd2.

I have a template generator and I can tell it to switch between etcd and etcd2 by setting a single environment variable. One thing I did was use the etcd2.service name or etcd.service (I didn't just put the etcd2 configuration in the etcd unit section). That could work, but, you might think about changing all etcd.service references in your file to etcd2.service. Anyway, here is the ExecStart section for etcd2:
ExecStart=/usr/bin/etcd2 \
--name ${d['etcd']['name']} \
--advertise-client-urls ${d['etcd']['advertise-client-urls']} \
--discovery ${d['etcd']['discovery']} \
--data-dir /var/lib/etcd \
--initial-advertise-peer-urls ${d['etcd']['initial-advertise-peer-urls']} \
--listen-client-urls ${d['etcd']['listen-client-urls']} \
--listen-peer-urls ${d['etcd']['listen-peer-urls']}
Here are my env variables for d['etcd']:
"etcd": {
"mver":"etcd2.service",
"discovery":"http://discovery.etcd.io/SOMEKEY",
"addr":"$private_ipv4:4001",
"name":"$private_ipv4",
"peer-addr":"$private_ipv4:7001",
"advertise-client-urls":"http://$private_ipv4:2379",
"initial-advertise-peer-urls":"http://$private_ipv4:2380",
"listen-client-urls":"http://0.0.0.0:2379,http://0.0.0.0:4001",
"listen-peer-urls":"http://$private_ipv4:2380,http://$private_ipv4:7001"
}
Somewhere I remember reading that $public_ipv4 was needed for one of these variables, put, I just went with the private ip for all of them. My environment here is digital ocean. Be sure to use coreos-alpha (at least I think that is still required at the time of this writing).

The cloud-config parser has built in support for etcd2 and the new configuration parameters: https://coreos.com/docs/cluster-management/setup/cloudinit-cloud-config/#etcd2
An example:
#cloud-config
coreos:
etcd2:
# generate a new token for each unique cluster from https://discovery.etcd.io/new?size=3
discovery: https://discovery.etcd.io/<token>
# multi-region and multi-cloud deployments need to use $public_ipv4
advertise-client-urls: http://$public_ipv4:2379
initial-advertise-peer-urls: http://$private_ipv4:2380
# listen on both the official ports and the legacy ports
# legacy ports can be omitted if your application doesn't depend on them
listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
listen-peer-urls: http://$private_ipv4:2380,http://$private_ipv4:7001

Related

How to setup RPC Node of solana?

I want to setup a full node of solana not a validator or voter node jsut to get the data of blockchain on local machine how could I do it?
If you want a local RPC node, know that the specs required are very high, currently 12 cores, 256GB RAM, and 1TB of NVME SSD space. More info at https://docs.solana.com/running-validator/validator-reqs
If you want to run an RPC node, the only additional command line argument that you must provide is --no-voting, and you don't need the voting args, so for example, you'd run:
solana-keygen new -o identity.json
solana-validator \
--rpc-port 8899 \
--entrypoint entrypoint.devnet.solana.com:8001 \
--limit-ledger-size \
--log ~/solana-validator.log \
--no-voting \
--identity identity.json
Otherwise, you can follow all of the instructions at https://docs.solana.com/running-validator/validator-start

SHAREDLIBRARYNAME Utimaco is not referring When I start signserver with docker

I start signserver with docker:
docker run -it --rm --name signserver \
-p 80:8080 -p 443:8443 \
-e CRYPTO_SERVER_IP=**** \
-v /ca-cert.pem:/mnt/external/secrets/tls/cas/ManagementCA.crt \
signserver:1.0
Now, i need connect signserver to PKCS11 on HSM.I has changed signserver-deploy.configuaration:
cryptotoken.p11.lib.30.name=Utimaco
cryptotoken.p11.lib.30.file=/opt/utimaco/p11/libcs_pkcs11_R3.so
Then I add PKCS#11 crypto worker from template,and i change the configuration:
WORKERGENID1.SHAREDLIBRARYNAME=Utimaco
The PKCS#11 crypto worker status is offline,so i active it and enter authentication Code.but i get errors:
- Failed to initialize crypto token: SHAREDLIBRARYNAME Utimaco is not referring to a defined value
Could you please help me
Thank you so much!
This is being discussed at the SignServer CE project's GitHub Discussions page where it is being answered that:
The current SignServer CE container does not support changing configuration in the signserver_deploy.properties.
A theoretical short-term solution for doing this could be something like this:
Find where the signserver.ear is in the container (probably under the appserver deployments folder and it might be folder instead of a ZIP file).
Find the JAR file which has the configuration, likely lib/SignServer-Common.jar
Find the properties file in that JAR file, something like org/signserver/common/.../signservercompile.properties
Change the property in that file and save it back to the ZIP file

gitlab-ci terraform state lock file eradication

While trying to migrate my backend config to use the new state storage with gitlab, I have run into this glorious problem: My state is locked.
I cannot force-unlock the state because the backend needs to be reinitialized
I cannot force-unlock -force the state unlock because the backend needs to be reinitialized
I cannot set up the backend with -lock=false because the same credentials that started this entire mess cannot seem to push things other than toxic lock tokens:
Error: Error copying state from the previous "local" backend to the newly configured
"http" backend:
Failed to upload state: POST http://internal.host/api/v4/projects/14/terraform/state/project-name giving up after 3 attempts
I'm at my patience's end. I did try to check whether the chatter in /var/log/gitlab/gitlab-rails/production_json.log delivers something relevant or not, and came away no more sure and little less sane for it.
Is there a sudo pretty-please-with-sugar-on-top-clean-the-fn-lock command that doesn't have any gatekeeping on it?
I have run into the same problem while migrating the terraform state files from s3 to gitlab.
I caused the problem because I had a typo in the backend_config unlock_address and I inserted Control+C while init was still running.
The terraform init did not ask me to migrate states from s3 to gitlab, but I got locked and force unlock would not work in any way.
The solution I came with:
Configure backend.tf to use as unlock address the previously used lock_address and re-initialize terraform.
Terraform plan should work fine now.
Reconfigure backend.tf to continue with state migration. Re-initialize terraform state URLs with the ones you want by migrating again.
For example, this is the terraform init I used where the desired adress was <TF_State_Name> and I had a typo <TF_State_Name_B> .
I interrupted with control+C:
terraform init \
-backend-config="address=https://<gitlab_url>/api/v4/projects/<ProjectID>/terraform/state/<TF_State_Name>" \
-backend-config="lock_address=https://<gitlab_url>/api/v4/projects/<ProjectID>/terraform/state/<TF_State_Name>/lock" \
-backend-config="unlock_address=https://<gitlab_url>/api/v4/projects/<ProjectID>/terraform/state/<TF_State_Name_B>/lock" \
-backend-config="username=<user>" \
-backend-config="password=<password>" \
-backend-config="lock_method=POST" \
-backend-config="unlock_method=DELETE" \
-backend-config="retry_wait_min=5"
And this is how I re-configured terraform init in order to by-pass the lock.
terraform init \
-backend-config="address=https://<gitlab_url>/api/v4/projects/<ProjectID>/terraform/state/<TF_State_Name_B>" \
-backend-config="lock_address=https://<gitlab_url>/api/v4/projects/<ProjectID>/terraform/state/<TF_State_Name_B>/lock" \
-backend-config="unlock_address=https://<gitlab_url>/api/v4/projects/<ProjectID>/terraform/state/<TF_State_Name_B>/lock" \
-backend-config="username=<user>" \
-backend-config="password=<password>" \
-backend-config="lock_method=POST" \
-backend-config="unlock_method=DELETE" \
-backend-config="retry_wait_min=5"
Finally, you should reconfigure to the desired address.

Helm - Spark operator examples/spark-pi.yaml does not exist

I've deployed Spark Operator to GKE using the Helm Chart to a custom namespace:
helm install --name sparkoperator incubator/sparkoperator --namespace custom-ns --set sparkJobNamespace=custom-ns
and confirmed the operator running in the cluster with helm status sparkoperator.
However when I'm trying to run the Spark Pi example kubectl apply -f examples/spark-pi.yaml I'm getting the following error:
the path "examples/spark-pi.yaml" does not exist
There are few things that I probably still don't get:
Where is actually examples/spark-pi.yaml located after deploying the operator?
What else should I check and what other steps should I take to make the example work?
Please find the spark-pi.yaml file here.
You should copy it to your filesystem, customize it if needed, and provide a valid path to it with kubectl apply -f path/to/spark-pi.yaml.
kubectl apply needs a yaml file either locally on the system where you are running kubectl command or it can be a http/https endpoint hosting the file.

Create DNS in lightsail entry using aws cli

Does anyone have an example of how to create a dns entry, for a lightsail hosted domain, using the aws cli?
I haven't been able to find an example of the format for the --domain-entry parameter of the create-domain-entry sub-command.
I made use of Mike's syntax to create a TXT record for DMARC. (Thank you Mike!)
I'd been trying to create it in the UI. I kept getting this error: Input error: Target should be enclosed in quotation marks: ""v=DMARC1; p=none; rua="mailto:dmarc#YOURDOMAINNAME.com"".
After trying several times with different recommended quote configurations, I bailed on the UI, and used Mike's syntax in a bash script. In my case, I also removed the extra quotes I had around the email address inside the rua portion. This may have been the source of my errors in the UI.
Here's what successfully created the DMARC record for me:
#!/usr/bin/bash
aws lightsail --region us-east-1 \
create-domain-entry \
--domain-name 'YOURDOMAINNAME.com' \
--domain-entry '{"name":"_dmarc.YOURDOMAINNAME.com","target":"\"v=DMARC1; p=none; rua=mailto:dmarcreports#YOURDOMAINNAME.com\"","isAlias":false,"type":"TXT"}'
Of course, replace YOURDOMAINNAME with your domain name, and the mailto name with the email at which you want to receive DMarc reports.
The command below will create an A record using the CLI
aws lightsail create-domain-entry \
--domain-name mikegcoleman.com \
--region us-east-1 --domain-entry \
name=blog.mikegcoleman.com,target=52.40.235.176,isAlias=false,type=A
Note that you need to specify the region as all domain actions with the Lightsail CLI need to be performed against us-east-1
For a TXT record the following should work. I think there is some funkiness with the CLI that it doesn't like the inline domain entry, and needs the JSON to do the TXT record, so it's formatted difrerently from above:
aws lightsail --region us-east-1 \
create-domain-entry \
--domain-name 'mikegcoleman.com' \
--domain-entry '{"name":"test.mikegcoleman.com","target":"\"response\"","isAlias":false,"type":"TXT"}'
Yes!
The answer from #binarybelle to create a BASH script and add the command as the JSON version worked for me too in order to add a TXT entry for DKIM.
The extra trick with a long DKIM entry is to split the text key into 2 parts, so lots of escaping the extra double-quotes :-)
#!/bin/bash
/usr/local/bin/aws lightsail --region us-east-1 \
create-domain-entry --domain-name 'mydomain.co.uk' \
--domain-entry '{"name":"default._domainkey.mydomain.co.uk","target":"\"v=DKIM1; h=sha256; k=rsa; \" \"p=MIIBIjxxxxxxxxxxxiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAurVgfLc8xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9cRHBTEOIR4lmIgatpit\" \"t+v7oQzngmfKpBNoTeyxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQIDAQAB\"","isAlias":false,"type":"TXT"}'

Resources