When attempting to debug issues with Desired State Configuration, I've found the following command invaluable;
start-dscconfiguration -wait -verbose -useexisting
This will (obviously) allow viewing of all the verbose logs.
The problem is that if the server needs to reboot as part of the configuration, or - more importantly - it's running normally (e.g. non-interactively as part of a pull configuration) it's not as easy to view these logs.
Is there any way to get the /exact/ same output logged to a specific location?
I do not have any .json files in the C:\Windows\system32\configuration\configurationstatus folder as suggested in one of the answers?
Set RebootNodeIfNeeded to false in meta configuration:
[DscLocalConfigurationManager()]
configuration Settings
{
Settings
{
ActionAfterReboot = 'StopConfiguration'
RebootNodeIfNeeded = $false
}
}
And run the existing configuration again:
Start-DscConfiguration -Wait -UseExisting -Verbose
(Adding this for posterity as other answers only contain links.)
Source: http://nanalakshmanan.com/blog/DSC-get-job-details-post-reboot/
You can follow the steps outlined in this blog to get the results post a reboot http://nanalakshmanan.com/blog/DSC-get-job-details-post-reboot/
You can also view the historical job logs as described in this blog http://nanalakshmanan.com/blog/Historical-Job-Logs/
Related
I've learned how to deploy .sh scripts to Azure with Azure CLI. But it seems like I have no clear understanding of how they work.
I'm creating the script that simply unarchives a .tgz archive in a current directory of Azure Web App, and then just deletes it. Quite simple:
New-Item ./startup.sh
Set-Content ./startup.sh '#!/bin/sh'
Add-Content ./startup.sh 'tar zxvf archive.tgz; rm-rf ./archive.tgz'
And then I deploy the script like this:
az webapp deploy --resource-group Group
--name Name
--src-path ./startup.sh
--target-path /home/site/wwwroot/startup.sh
--type=startup
Supposedly, it should appear in /home/site/wwwroot/, but for some reason it never does. No matter how I try. I thought it just gets executed and then deleted automatically (since I specified it as a startup script), but the archive is there, not unarchived at all.
My stack is .NET Core.
What am I doing wrong, and what's the right way to do what I need to do? Thank you.
I don't know if it makes sense, but I think the problem might be that you're using the target-path parameter while you should be using path instead.
From the documentation you cited, when describing the Azure CLI functionality, they state:
The CLI command uses the Kudu publish API to deploy the package and can be
fully customized.
The Kudu publish API reference indicates, when describing the different values for type and especially startup:
type=startup: Deploy a script that App Service automatically uses as the
startup script for your app. By default, the script is deployed to
D:\home\site\scripts\<name-of-source> for Windows and
home/site/wwwroot/startup.sh for Linux. The target path can be specified
with path.
Note the use of path:
The absolute path to deploy the artifact to. For example,
"/home/site/deployments/tools/driver.jar", "/home/site/scripts/helper.sh".
I never tested it, I am aware that the option is not described when taking about the az webapp deploy command itself, and it may be just an error in the documentation, but it may work:
az webapp deploy --resource-group Group
--name Name
--src-path ./startup.sh
--path /home/site/wwwroot/startup.sh
--type=startup
Note that the path you are providing is the default one; as a consequence, you could safely delete it if required:
az webapp deploy --resource-group Group
--name Name
--src-path ./startup.sh
--type=startup
Finally, try including some debug or echo commands in your script: perhaps the problem can be motivated for any permissions issue and having some traces in the logs could be helpful as well.
After installing the self-managed gitlab docker container, I'm facing an issue when trying to init a GitLab Kubernetes Agent.
First of all, I've added the .gitlab/agents/<agent-name>/config.yaml according to gitlab docs and it's possible to click the green integrate with GitLab Agent button, but then the dropdown is empty and the console returns an 500 internal server error without any interesting information.
The gitlab-kas configuration in /etc/gitlab/gitlab.rb was enabled by default with those configuration:
##! Settings used by the GitLab application
# gitlab_rails['gitlab_kas_enabled'] = true
# gitlab_rails['gitlab_kas_external_url'] = ws://gitlab.example.com/-/kubernetes-agent
# gitlab_rails['gitlab_kas_internal_url'] = grpc://localhost:8153
##! Enable GitLab KAS
# gitlab_kas['enable'] = true
Last but not least, found some more helpful logs in docker logs -f gitlab I guess:
Gitlab::Kas::Client::ConfigurationError (GitLab KAS is not enabled):
lib/gitlab/kas/client.rb:16:in `initialize'
ee/app/graphql/resolvers/kas/agent_configurations_resolver.rb:28:in `new'
ee/app/graphql/resolvers/kas/agent_configurations_resolver.rb:28:in `kas_client'
ee/app/graphql/resolvers/kas/agent_configurations_resolver.rb:16:in `resolve'
lib/gitlab/graphql/present/field_extension.rb:18:in `resolve'
lib/gitlab/graphql/generic_tracing.rb:40:in `with_labkit_tracing'
lib/gitlab/graphql/generic_tracing.rb:30:in `platform_trace'
lib/gitlab/graphql/generic_tracing.rb:40:in `with_labkit_tracing'
lib/gitlab/graphql/generic_tracing.rb:30:in `platform_trace'
lib/gitlab/graphql/generic_tracing.rb:40:in `with_labkit_tracing'
lib/gitlab/graphql/generic_tracing.rb:30:in `platform_trace'
app/graphql/gitlab_schema.rb:40:in `multiplex'
...
So it seams that the gitlab-kas service is not running, but how can I boot it up?
OMG ID10T incoming: after studying the /etc/gitlab/gitlab.rb config again, I found the error and it's kind of obvious. Changed settings is good, but if they were not included, it doesn't help at all.
In reference to the original question, within the provided config screenshot you can see, that the setting is actually a comment. After removing the # it works fine.
I met a problem with docker logging and after reading a lot of sources didn't find solution: is there a way to discard messages of docker daemon in /var/log/messages and select another location?
Ok, I know that this question is quite old but I don't think it has been answered well and no correct answer has been stated.
First of all the reason why it saves messages to that particular place starts in rsyslog configuration (/etc/rsyslog.conf) with the line:
$ModLoad imjournal # provides access to the systemd journal
So, because docker saves information to systemd journal it ends at /var/log/messages.
To be able to save it to other places, you have to create a rule like the following at /etc/rsyslog.d/docker.conf.
$FileCreateMode 0644
template(name="DockerLogFileName" type="list") {
constant(value="/var/log/docker/")
property(name="syslogtag" securepath="replace" \
regex.expression="docker/\\(.*\\)\\[" regex.submatch="1")
constant(value="/docker.log")
}
if $programname == 'dockerd' then \
/var/log/docker/combined.log
if $programname == 'dockerd' then \
if $syslogtag contains 'docker/' then \
?DockerLogFileName
else
/var/log/docker/no_tag/docker.log
$FileCreateMode 0600
I found the information for this configuration here:
https://www.simulmedia.com/blog/2016/02/19/centralized-docker-logging-with-rsyslog/
Configure rsyslog to isolate the Docker logs into their own file. To do this create /etc/rsyslog.d/10-docker.conf and copy the following content into the file.
# Docker logging
daemon.* {
/var/mylog
stop
}
In summary this will write all logs for the daemon category to /var/mylog then stop processing that log entry so it isn’t written to the systems default syslog file.
According to the Docker documentation, you can specify a different driver either as a command-line argument for the docker daemon or (preferably) in the daemon.json config file. Several drivers are available, e.g. for Syslog, HTTP-based logging, ...
Update
Here's an example configuration section for Syslog (from the documentation):
{
"log-driver": "syslog",
"log-opts": {
"syslog": "udp://1.2.3.4:1111"
}
}
I added a scripts.config file to .ebextensions at the root of my Node app deployed in beanstalk.I did not see the tags for the EC2 instances in the console. Nor did I see any mention of 1_add_tags in beanstalk logs. What did I do wrong and how do I find out if the commands in the script.config were called at all!
The config file in .ebextensions is as follows ....
01_add_tags:
command: ec2-create-tags $(ec2-metadata -i | cut -d ' ' -f2) --tag Environment=Production --tag Name=Proxy-Server --tag Application=something
env:
EC2_HOME: /opt/aws/apitools/ec2
EC2_URL: https://ec2.ap-southeast-2.ama...
JAVA_HOME: /usr/lib/jvm/jre
PATH: /bin:/usr/bin:/opt/aws/bin/
Cheers,
Prabin
Amazon's answer to the problem. (This worked for me) ...
You can utilise the ebextensions to execute certain commands on instance boot.
Supposing that you want to implement this on Linux based containers. I have formulated a sample config file for you and attached to this case.
Please follow below guidelines :
In the AWS Management console, check the IAM Role/Instance profile used by beanstalk. By default it uses "aws-elasticbeanstalk-ec2-role". Add permissions for this role to create new tags (ec2:CreateTags).
If you do not have ".ebextensions" folder at the root of your application or the "WEB-INF" folder, then create the folder.
Modify the key value pairs in the config file. Multiple pairs are separated by a space.
A sample snippet is as below:
{
"container_commands": {
"01_add_tags": {
"command": "aws ec2 create-tags --resources $(GET http://169.254.169.254/latest/meta-data/instance-id) --tags Key=ClientName,Value=testClient Key=NewTag,Value=new-value --region us-east-1"
}
}
}
Add the modified config file in the ".ebextensions" folder.
Upload this version to beanstalk. It should launch new instances and execute the config file.
Please give it sometime, preferably till the instances pass EC2 instance status checks. Refresh the page for the additional tags to be displayed.
Please note that we are using "Container_commands" instead of "Command" used in the blog.
Container Commands run after the application and web server have been set up and the application version file has been extracted, but before the application version is deployed. This is important as these commands have access to environment variables such as your AWS security credentials set by the instance-profile.
I would recommend you to go through the restrictions for AWS Resources tagging mentioned at http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#tag-restrictions
I would like to highlight that maximum number of tags per resource is 10.
Also check the table for tagging support for certain resource. For example, currently tagging is not supported for ELB.
I had the similar problem where I tried to install libjpeg using the ./ebextensions/foo.config file. I tried everything but was never able to find a good solution.
I was able to solve it though, by setting up a completely new Elastic Beanstalk Application and then deploying my same version on the new instance instead. When I did this everything was installed perfectly and working fine.
Check out my answers here:
https://stackoverflow.com/a/23109410/2335675
https://stackoverflow.com/a/23131959/2335675
Hope this fixes your issues as well.
I began modifying a profile and made some mistakes along the way.
Because of this I have PIDs in the profile which I'd like to delete entirely.
These can be seen in the fabric:profile-display default output shown at the bottom of this post.
They are:
http:
patch.repositories=http:
org.ops4j.pax.url.mvn.repositories=http:
I can't find the correct command to delete this. I've tried:
config:delete org.ops4j.pax.url.mvn.repositories=http:
which successfully completes. But the default profile still lists this pid.
I've also tried:
fabric:profile-edit --delete -p org.ops4j.pax.url.mvn.repositories=http: default
which fails with:
Error executing command: String index out of range: -1
This indicates a property path /property must be specified.
Appending simply / doesn't work either.
One more problem is that I have a pid with a seemingly empty name, as indicated by this line:
PID: (nothing follows this output prefix).
Output of fabric:profile-display default:
Profile id: default
Version : 1.0
Parents :
Associated Containers :
Container settings
----------------------------
Repositories :
mvn:org.fusesource.fabric/fuse-fabric/7.0.1.fuse-084/xml/features
Features :
fabric-agent
karaf
fabric-jaas
fabric-core
Agent Properties :
patch.repositories = http://repo.fusesource.com/nexus/content/repositories/releases,
http://repo.fusesource.com/nexus/content/groups/ea
org.ops4j.pax.url.mvn.repositories = http://repo1.maven.org/maven2,
http://repo.fusesource.com/nexus/content/repositories/releases,
http://repo.fusesource.com/nexus/content/groups/ea,
http://repository.springsource.com/maven/bundles/release,
http://repository.springsource.com/maven/bundles/external,
http://scala-tools.org/repo-releases
org.ops4j.pax.url.mvn.defaultRepositories = file:${karaf.home}/${karaf.default.repository}#snapshots,
file:${karaf.home}/local-repo#snapshots
Configuration details
----------------------------
PID:
PID: org.ops4j.pax.url.mvn
org.ops4j.pax.url.mvn.useFallbackRepositories false
org.ops4j.pax.url.mvn.disableAether true
org.ops4j.pax.url.mvn.repositories ${profile:org.fusesource.fabric.agent/org.ops4j.pax.url.mvn.repositories}
org.ops4j.pax.url.mvn.defaultRepositories ${profile:org.fusesource.fabric.agent/org.ops4j.pax.url.mvn.defaultRepositories}
PID: patch.repositories=http:
PID: org.ops4j.pax.url.mvn.repositories=http:
PID: http:
PID: org.fusesource.fabric.zookeeper
zookeeper.url ${zk:root/ip}:2181
I'd be extremely grateful if someone could point the correct command(s).
I had a look at the command-line code for fabric:profile-edit with --delete and unfortunately this function seems to be desgined for deleting key/value pairs from the PID, rather than deleting the PID itself.
(Here's the code for ProfileEdit.java on github)
So basically you can use that command to "empty out" the PIDs, but not to remove them.
fabric:profile-edit --delete --pid mypid/mykey=myvalue myprofile
Knowing that this doesn't help you much, I asked my colleague who sits next to me (and is much smarter than me) and he recommended the following:
Enable fuse management console with container-add-profile root fmc
Opem fmc in a browser (mine is on localhost at port 8181), go to the Profiles page, choose your profile from the list
Go to the Config Files tab, find the PID you want to nuke and click the cross (X).
Et voila, the pid should be gone. Interested to know if this works for you, including on the "blank" profile...
The following works in Fuse 6.2:
1) for property files (which become PID objects)
# create
profile-edit --resource foobar.properties default
# delete
profile-edit --delete --pid foobar default
2) for arbitrary files
# create
profile-edit --resource foobar.xml default
#delete
only via hawtio web console, see screenshot: