text:
two blocks persistently failed to migrate to phys03

blocks
/JPsiToMuMu_PT-0to100_pythia8-gun/Run3Winter24MiniAOD-KeepSi_133X_mcRun3_2024_realistic_v8-v2/MINIAODSIM#699b90af-18b1-4ccc-a9d3-3426b2822b15
/JPsiToMuMu_PT-0to100_pythia8-gun/Run3Winter24MiniAOD-KeepSi_133X_mcRun3_2024_realistic_v8-v2/MINIAODSIM#ff7e1305-3415-4bd7-8be3-14ead7bf0906

when trying to migrate in CRAB Publisher the migration request always fails with (status=9)
In such cases the Publisher deletes the migration and submits a new one, which solves rare issues related to e.g. servers restarts while migrations were going on).
But for those thow blocks any new request keeps failing. Since more than ten days.
Can you look in logs from your side ?
Latest example:
2024-11-27 14:50:26,509:INFO: Submitting 2 block migration requests to DBS3 ...
2024-11-27 14:50:26,509:INFO: Submitting migration request for block /JPsiToMuMu_PT-0to100_pythia8-gun/Run3Winter24MiniAOD-KeepSi_133X_mcRun3_2024_realistic_v8-v2/MINIAODSIM#ff7e1305-3415-4bd7-8be3-14ead7bf0906 ...
2024-11-27 14:50:26,965:ERROR: Migration request refused by server.
2024-11-27 14:50:26,965:ERROR: Migration refusal reason: migration request /JPsiToMuMu_PT-0to100_pythia8-gun/Run3Winter24MiniAOD-KeepSi_133X_mcRun3_2024_realistic_v8-v2/MINIAODSIM#ff7e1305-3415-4bd7-8be3-14ead7bf0906 is already exist in DB with id=4889789
2024-11-27 14:50:27,043:INFO: Existing migration id=4889789 is terminally failed (status=9)Delete it and try again at next iteration
2024-11-27 14:50:27,439:INFO: Submitting migration request for block /JPsiToMuMu_PT-0to100_pythia8-gun/Run3Winter24MiniAOD-KeepSi_133X_mcRun3_2024_realistic_v8-v2/MINIAODSIM#699b90af-18b1-4ccc-a9d3-3426b2822b15 ...
2024-11-27 14:50:27,859:ERROR: Migration request refused by server.
2024-11-27 14:50:27,859:ERROR: Migration refusal reason: migration request /JPsiToMuMu_PT-0to100_pythia8-gun/Run3Winter24MiniAOD-KeepSi_133X_mcRun3_2024_realistic_v8-v2/MINIAODSIM#699b90af-18b1-4ccc-a9d3-3426b2822b15 is already exist in DB with id=4889788
2024-11-27 14:50:27,931:INFO: Existing migration id=4889788 is terminally failed (status=9)Delete it and try again at next iteration
2024-11-27 14:50:28,399:INFO: 2 block migration requests failed to be submitted.

culprit seems to be this
Message:unable to find parent lfn /store/mc/Run3Winter24Reco/JPsiToMuMu_PT-0to100_pythia8-gun/AODSIM/KeepSi_133X_mcRun3_2024_realistic_v8-v2/2540000/deab1d58-e1f5-4498-8642-da601a52cb51.root

that makes little sense since that file exists in DBS with valid status
https://cmsweb.cern.ch/das/request?instance=prod/global&input=block+file%3D%2Fstore%2Fmc%2FRun3Winter24Reco%2FJPsiToMuMu_PT-0to100_pythia8-gun%2FAODSIM%2FKeepSi_133X_mcRun3_2024_realistic_v8-v2%2F2540000%2Fdeab1d58-e1f5-4498-8642-da601a52cb51.root
something wrong in DBS code ?
full error message seems to complain about SQL but it is possibly a consequence of the file not found
[2024-11-27 13:23:15.509599491 +0000 UTC m=+1377063.689315803] migrate.go:1116: insert bulkblocks for mid 4889788 error DBSError Code:101 Description:DBS DB error Function:dbs.bulkblocks.InsertBulkBlocksConcurrently Message:unable to find parent lfn /store/mc/Run3Winter24Reco/JPsiToMuMu_PT-0to100_pythia8-gun/AODSIM/KeepSi_133X_mcRun3_2024_realistic_v8-v2/2540000/deab1d58-e1f5-4498-8642-da601a52cb51.root Error: nested DBSError Code:103 Description:DBS DB query error, e.g. mailformed SQL statement Function:dbs.GetID Message: Error: sql: no rows in result set

hi @belforte looking into it

hi @todor-ivanov
any hint on what may be going on ? Should I conclude that those migrations are impossible and stop CRAB Publisher from trying ? Did you try a "simple" restart of the migration server ? All in all this never happened after the initial shacking/debugging. It is is a "once a year" thing, we can live with it.

hi @belforte
I was not able to spot anything more than what you were already reporting. The parent lfn is indeed in DBS. A a last resort
I restarted the service few minutes ago, as you suggested. Please let me know if the error persists. I am also watching the logs on the dbs-phys03-migration server side.

thanks Todor, I will let you know how it goes in next iteration

still failing. I will force Publisher to ignore the corresponding requests

Hi @belforte how many were those?

two tasks. retrying sine beginning of November. Publication in DBS is the default for CRAB, in this case chances are that the user does not even care. Yet it is the first time that we have a "permanently failed" migration  in all of DBS history. Until now those could always be recovered.

authors: belforte todor-ivanov


text:
Deleting connection Analytics removes all connectors

Description of bug
If you have a Google Analytics connection set up and you want to remove that connection, that is not possible.

You can not just remove the ua-code and hit save
if you choose 'delete connection', you destroy the Connectors part. The connections setting just says "Setup your connections to easily share content and more". So there is no Analytics and no Azure connectors anymore

Steps to reproduce
Go to COnnectors, save a ua-code, remove the ua-code (does not work) and click 'delete connection'.
Expected behavior

If I empty the ua-code field, I would like to be able to save that. Or have a 'reset-button;. But it must be possible to remove a ua-code.
whatever the 'delete connection' button is supposed to do, probably not this.

Error information
Message:Object reference not set to an instance of an object.
StackTrace:
at DNN.Connectors.GoogleAnalytics.GoogleAnalyticsConnector.GetConfig(Int32 portalId)
at DNN.Connectors.GoogleAnalytics.GoogleAnalyticsConnector.HasConfig(Int32 portalId)
at Dnn.PersonaBar.Connectors.Services.ConnectorsController.b__1_0(IConnector x)
at DotNetNuke.Collections.CollectionExtensions.ForEach[TType](IEnumerable1 source, Action1 action)
at Dnn.PersonaBar.Connectors.Services.ConnectorsController.GetConnections()
at lambda_method(Closure , Object , Object[] )
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass10.b__9(Object instance, Object[] methodParameters)
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.Execute(Object instance, Object[] arguments)
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary2 arguments, CancellationToken cancellationToken) --- End of stack trace from previous location where exception was thrown ---    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)    at System.Web.Http.Tracing.ITraceWriterExtensions.<TraceBeginEndAsyncCore>d__181.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ApiControllerActionInvoker.d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Tracing.ITraceWriterExtensions.d__18`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ActionFilterResult.d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Filters.AuthorizationFilterAttribute.d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ExceptionFilterResult.d__0.MoveNext()
InnerMessage:
InnerStackTrace:
Source:DNN.Connectors.GoogleAnalytics
Affected version
9.6.1 but as this part has not changed much, I think newer versions as well.

This issue is solved in #4457 as @Tychodewaard pointed out to me.

source: gharchive/issue

authors: Tychodewaard skamphuis

license: mit

license_type: permissive

license_source: bigquery


text:
DNN-6562 Browsercaching

DNN-6562 - Add cache buster to uris for images and other resources accessed from the browser via a FileUrl

@RichardHowells: Thanks for the detailed feedback. I understand all of your arguments.
IMHO, your HTML module scenario shows the big problem: Even if the module is clever enough to update the image URLs if the file changes you have the same problem with external sources that refer to your resources (websites or maybe search engines) because they can't know that a resource (and it's URL) has been updated.
I would suggest the following: Instead of (automatically) adding a version token to the URLs, DNN provides functionalities (for administrator) to define (client-side) cache times (for files and/or folders). At the moment in a default DNN 7.4.0 installation there is a default cache time of 365 days for static resources defined in the web.config:

Depending on the frequency a resource changes, cache times could be defined (for logos a cache time of 7 days could be reasonable). Of course, suggestion does not fix the problem that there is some delay before all clients get the new resources, but this feature will not introduce any other drawbacks. If a developer wants to make sure that clients always gets the most recent version, he could either use some custom logic or the abstract FolderProvider provides a new method GetFileUrl(IFileInfo file, bool disableCache) which is implemented by all file providers.
Btw: Maybe a default caching of 365 day is a bit too long and one should decrease the default caching (for example to one day) and override the default value with a higher one for files/folders that most likely won't change. But this question should not be discussed in the pull request.

This change was originally introduced in 7.3.0 (673d5fd91ae6e3c2ca59531197d051bd1a931fd8).  I agree that the MaxAge value is overly aggressive and should be reduced to a 1 day cache value.  I think users will derive more performance benefit from moving the resource to a CDN than creating an extremely long caching duration.  I think this enhancement would be better than adding cache busting logic to the platform.

@janjonas Do you have access to the MVP forum? There is a thread there relevant to this subject.  I'd value your views. http://www.dnnsoftware.com/forums/forumid/228/threadid/515268/scope/posts

@RichardHowells Jan doesn't currently have access to MVP forums. This is the better place to have the discussion since it is open to anyone in the community who is interested in this feature.

Hi Joe,
May I present a different point of view?

moving content to a CDN is a choice that is already in the user's hands. (S)he can run the tests/simulations/whatever and decide.  They don't need us.

cache headers are in the users' hands.  They have to be tech savvy enough to add the right web config lines or click the right pieces in the IIS manger GUI but they don't need us.  Now we even do it for them.  By doing it we prevent them properly controlling their own content.

cache busting is something the user has no chance of doing alone.  Ok they could create a custom fork of the DNN source code, but that is a pretty major thing to do.  Only we can do cache busting.

Cache busting is an essential corollary to caching.  It's the only way to keep the browser cache under control.  We already recognize the fact by adding the magic "Current host version" to most resources injected into the page.  That is a massive contribution.  The argument about "how long should we cache for" is pointless.  Any chosen duration is wrong.  Worse it puts the developers and the site managers in an impossible position.  We cannot know what near random collection of scripts, images, CSS files and other resources any particular user's browser may have cached.  The immense number of combinations makes it impractical to test what we release.  It causes support calls and encourages call handlers to insist on 'clearing the cache' before they do anything useful.  Nobody likes to lose all their saved passwords and cookies, but real call handlers cannot make the distinction.
There is only one proper duration for caching - forever.  In practice the relevant RFC says one year max and that's close enough to forever.  I won't repeat the arguments.  This article [1] is great, does it better than I can, and has diagrams.
Even with a CDN you still require caching, cache headers, and proper cache busting.  The CDN may be 'closer' but nothing will beat the zero cost of serving a resource from the local cache.  Inadequate cache busting will result in the CDN serving the wrong resource.  Having the wrong resource faster is no comfort.
A CDN may give better performance than cache and cache busting.  CDN's are expensive and many, even quite large sites, will not have the budget.  Adding cache headers is free, we've already done it.  We should complete the job by doing cache busting as well as we can.  We've covered part of the job with the "Current host version".  Pull request #300 (https://github.com/dnnsoftware/Dnn.Platform/pull/300) is another part of the job.
[1]   http://blog.httpwatch.com/2007/12/10/two-simple-rules-for-http-caching/

@RichardHowells: What about adding your logic in the a new FolderProvider (that may extends the StandardFolderProvider)? This special FolderProvider could be part of a separate extension. Of course, to benefit from these FolderProvider the administrator has install the extension and use configure the the folders to use the FolderProvider.
This would keep the StandardFolderProvider as "clean" as possible. IMHO, this special cache busting is nothing that should be added to a StandardFolderProvider. It's just a standard folder provider, as the name implies, so there should be no magic :).

@JanJonas: Thank you for the suggestions.  IMHO cache busting is not special.  Caching and cache control measures are essential to the operation of the internet.
Cache busting has been a standard part of DNN through the "Current host version" setting for a significant time.  Adding cache headers is standard in new DNN7.3 installs.  These things are built in standard features.
I think it introduces a significant extra barrier if an administrator has to install an extension to get control over something we introduce automatically.

source: gharchive/pull-request

authors: RichardHowells janjonas jbrinkman


text:
Add JsonIgnore Attribute

Fixes #5005
Summary
Anywhere there was an XmlIgnore attribute we have added a JsonIgnore attribute from the Newtonsoft.Json library. This will help to ensure serializing to Json is mirroring the XML serialization objects.

/azp run

/azp run

YAY passing build.

authors: mtrutledge valadas


text:
Fix windows console colours, include installer script for windows

Fix for #59 by replacing direct ANSI escape code injection with fatih/color library.
Also added a batch script for windows installs: .exe is renamed and moved to a directory which is then added to the user's execution PATH. It is required that the script is in the same directory as the downloaded binary when it is run, so I would suggest placing both in a zip file together.

I was about to merge this https://github.com/dnote-io/cli/commit/1914f311e86483b69dc4a5ab800fc42c9e829ed3 You beat me by few minutes.. haha
Could you update the dependency lock file by running dep ensure? https://github.com/golang/dep

Ah, sorry - I should have let you know I was working on it to avoid duplication of effort. Still, I've dep ensured it now.

authors: FearNotDaniel sungwoncho

repo: dnote-io/cli


text:
Fix version regexp

Since Icinga2 version 2.11 the version string in API /v1/status/IcingaApplication is without "v" prefix.
The scheduled downtimes are not reported in the "Unhandled Services" so I have filtered them out of the "Problems" section.

Please split the two commits into 2 PRs. I agree on the version fix, the other one is not related to here and needs a second thought.

I've cherry-picked the first commit to master, the second commit corrects something with the problem lists, but only for downtimes not acknowledgements or host being down. Since 2.11 introduces the handled attribute, such implementations will become even easier in the future.

The other thing better fits into the implementation for #73 which I've done there.

authors: dnsmichi petr-castulik

license: MIT

license_source: github-api


text:
fix incorrect env

Fixes-###
#358
What
Why
How Tested
build and test in development environment

@mritunjaysharma394 already did this , so I will close this pr.

repo: docker-slim/docker-slim


text:
Add ability to pass in substitution args into an Error

Signed-off-by: Doug Davis dug@us.ibm.com

@duglin Per our conversation, we are going to do the following in this PR:

The Message field comes back to Error. It is populated upon calling WithArgs. The Message field will always be populated with the english version, but the contents of Args may be saved.
The addition of the Args field to Error will be held off until we know we need it in the error protocol.
The type jsonError is no longer required, since this functionality is covered by Error.

In a separate PR, we will add package documentation detailing use and best practices. One such best practice is keeping use of error codes in protocol related handler (http handlers and rpc handlers).

@stevvooe sorry for the delay - was on vacation and then in email catch-up mode (still am :-) ).
I made the changes we discussed.  I couldn't remove jsonError because we need something to tell the serialization code to wrapper the Error json with "errors".  See what you think.
Any idea about the ci error?  I don't think its related to my code changes.

@stevvooe also, during our chat at DockerCon you mentioned that you were hoping that the WithArgs func would be fairly "set in stone" but that the underlying impl might change based on how we deal with args.  One thing that I felt I should bring up is signature of WithArgs()  Right now its just a slice of interface{} because we use Sprintf to do the insertion into the message string.  Which is fine for now since we haven't picked a translation package to use.  However, some packages don't use slices, instead they use maps where each arg is given a name. Then the substitution is done by template/naming rather than positional.
I see us having two choices:
1 - keep what we have now in this PR since its simple and works for our Sprintf logic. With this choice we accept that based on what translation package we choose the signature of WithArgs() may change. However, this is an internal interface and not one that is expected to end users so it would just impact docker devs.
2 - assume that whatever package we choose will use a map for the list of args and switch over to that now with the hopes that it'll match whatever the translation package we use will have.  Like option 1, this has the risk that we may still need to change the signature of WithArgs() but probably in a less drastic way. This would also require us to create (or borrow) a name-based template insertion mechanism.
Anyway, I'm ok with either and option 1 is certainly less work but if you would prefer a solution that is closer to where we'll probably end up then option 2 might be the right choice.
Thoughts?

@duglin I think the issue with option 2 is that it assumes the format strings will be named and not positional. Commonly, most i8n systems seem to be positional. Such a system would likely have a different interface.

@stevvooe yup which is why I'm ok with option 1 (positional) for now. I just wanted to make sure you were aware that based on what we do later on we may need to change the signature.

@stevvooe think I got 'em all

LGTM

Removed the extra "cast" - repushed.

@endophage fixed the WithArgs() func and added some tests for it (as well as WithDetails).

Cool, LGTM.

authors: duglin endophage stevvooe

repo: docker/distribution


text:
Some tests fails despite correct configuration

Hi,
I ran several times the security tests against my local installation (CentOs7), but some critical tests fails despite the following configuration file :
{
  "icc": false,
  "data-root": "/docker",
  "log-driver": "syslog",
  "experimental": false,
  "live-restore": true,
  "userland-proxy": false,
  "no-new-privileges": true
}

The service starts with the following configuration:
● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since mer. 2019-08-28 19:07:59 CEST; 2h 25min ago
     Docs: https://docs.docker.com
 Main PID: 4805 (dockerd)
    Tasks: 14
   Memory: 103.6M
   CGroup: /system.slice/docker.service
           └─4805 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --config-file=/etc/docker/daemon.json

août 28 21:21:50 localhost.localdomain d19e2b760438[4805]: [INFO] 6 - Docker Security Operations
août 28 21:21:50 localhost.localdomain d19e2b760438[4805]: [INFO] 6.1  - Perform regular security audits of your host system and containers
août 28 21:21:50 localhost.localdomain d19e2b760438[4805]: [INFO] 6.2  - Monitor Docker containers usage, performance and metering
août 28 21:21:50 localhost.localdomain d19e2b760438[4805]: [INFO] 6.3  - Backup container data
août 28 21:21:50 localhost.localdomain d19e2b760438[4805]: [INFO] 6.4  - Avoid image sprawl
août 28 21:21:50 localhost.localdomain d19e2b760438[4805]: [INFO]      * There are currently: 1 images
août 28 21:21:51 localhost.localdomain d19e2b760438[4805]: [INFO] 6.5  - Avoid container sprawl
août 28 21:21:51 localhost.localdomain d19e2b760438[4805]: [INFO]      * There are currently a total of 2 containers, with 1 of them currently running
août 28 21:21:51 localhost.localdomain dockerd[4805]: time="2019-08-28T21:21:51.260261049+02:00" level=info msg="ignoring event" module=libcontainerd ...kDelete"
août 28 21:21:51 localhost.localdomain dockerd[4805]: time="2019-08-28T21:21:51.264254704+02:00" level=warning msg="d19e2b760438675ca1041302b5140e679959cd2ae3...
Hint: Some lines were ellipsized, use -l to show in full.

I've read the code and tried the following:
(grep "icc" "/etc/docker/daemon.json" | sed 's/.*: //g' | tr -d \", | grep "false" >/dev/null 2>&1;) && echo OK || echo KO

It returns "OK" so my guess is something can't read properly the Docker configuration files.
For the record, here is how I ran the security tests:
docker run -it --net host --pid host --userns host --cap-add audit_control     -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST     -v /etc:/etc:ro     -v /usr/bin/docker-containerd:/usr/bin/docker-containerd:ro     -v /usr/bin/docker-runc:/usr/bin/docker-runc:ro     -v /usr/lib/systemd:/usr/lib/systemd:ro     -v /var/lib:/var/lib:ro     -v /var/run/docker.sock:/var/run/docker.sock:ro     --label docker_bench_security     docker/docker-bench-security

Here are the results:
# ------------------------------------------------------------------------------
# Docker Bench for Security v1.3.0
#
# Docker, Inc. (c) 2015-
#
# Checks for dozens of common best-practices around deploying Docker containers in production.
# Inspired by the CIS Docker 1.13 Benchmark.
# ------------------------------------------------------------------------------

Initializing Wed Aug 28 19:37:21 GMT 2019

[INFO] 1 - Host Configuration
[WARN] 1.1  - Create a separate partition for containers
[INFO] 1.2  - Harden the container host
[PASS] 1.3  - Keep Docker up to date
[INFO]      * Using 19.03.1 which is current as of 2017-03-01
[INFO]      * Check with your operating system vendor for support and security maintenance for Docker
[INFO] 1.4  - Only allow trusted users to control Docker daemon
[INFO]      * docker:x:995:mbodin
[PASS] 1.5  - Audit docker daemon - /usr/bin/docker
[INFO] 1.6  - Audit Docker files and directories - /var/lib/docker
[INFO]      * Directory not found
[PASS] 1.7  - Audit Docker files and directories - /etc/docker
[WARN] 1.8  - Audit Docker files and directories - docker.service
[WARN] 1.9  - Audit Docker files and directories - docker.socket
[INFO] 1.10 - Audit Docker files and directories - /etc/default/docker
[INFO]      * File not found
[PASS] 1.11 - Audit Docker files and directories - /etc/docker/daemon.json
[INFO] 1.12 - Audit Docker files and directories - /usr/bin/docker-containerd
[INFO]      * File not found
[INFO] 1.13 - Audit Docker files and directories - /usr/bin/docker-runc
[INFO]      * File not found

[INFO] 2 - Docker Daemon Configuration
[WARN] 2.1  - Restrict network traffic between containers
[PASS] 2.2  - Set the logging level
[PASS] 2.3  - Allow Docker to make changes to iptables
[PASS] 2.4  - Do not use insecure registries
[PASS] 2.5  - Do not use the aufs storage driver
[INFO] 2.6  - Configure TLS authentication for Docker daemon
[INFO]      * Docker daemon not listening on TCP
[INFO] 2.7  - Set default ulimit as appropriate
[INFO]      * Default ulimit doesn't appear to be set
[WARN] 2.8  - Enable user namespace support
[PASS] 2.9  - Confirm default cgroup usage
[PASS] 2.10 - Do not change base device size until needed
[WARN] 2.11 - Use authorization plugin
flag provided but not defined: --format
See 'docker info --help'.
[PASS] 2.12 - Configure centralized and remote logging
[WARN] 2.13 - Disable operations on legacy registry (v1)
[WARN] 2.14 - Enable live restore
[PASS] 2.15 - Do not enable swarm mode, if not needed
[PASS] 2.16 - Control the number of manager nodes in a swarm (Swarm mode not enabled)
[PASS] 2.17 - Bind swarm services to a specific host interface (Swarm mode not enabled)
[WARN] 2.18 - Disable Userland Proxy
[PASS] 2.19 - Encrypt data exchanged between containers on different nodes on the overlay network
flag provided but not defined: --format
See 'docker info --help'.
[INFO] 2.20 - Apply a daemon-wide custom seccomp profile, if needed
[WARN] 2.21 - Avoid experimental features in production
[PASS] 2.22 - Use Docker's secret management commands for managing secrets in a Swarm cluster (Swarm mode not enabled)
[PASS] 2.23 - Run swarm manager in auto-lock mode (Swarm mode not enabled)
[INFO] 2.24 - Rotate swarm manager auto-lock key periodically

[INFO] 3 - Docker Daemon Configuration Files
[PASS] 3.1  - Verify that docker.service file ownership is set to root:root
[PASS] 3.2  - Verify that docker.service file permissions are set to 644 or more restrictive
[PASS] 3.3  - Verify that docker.socket file ownership is set to root:root
[PASS] 3.4  - Verify that docker.socket file permissions are set to 644 or more restrictive
[PASS] 3.5  - Verify that /etc/docker directory ownership is set to root:root
[PASS] 3.6  - Verify that /etc/docker directory permissions are set to 755 or more restrictive
[INFO] 3.7  - Verify that registry certificate file ownership is set to root:root
[INFO]      * Directory not found
[INFO] 3.8  - Verify that registry certificate file permissions are set to 444 or more restrictive
[INFO]      * Directory not found
[INFO] 3.9  - Verify that TLS CA certificate file ownership is set to root:root
[INFO]      * No TLS CA certificate found
[INFO] 3.10 - Verify that TLS CA certificate file permissions are set to 444 or more restrictive
[INFO]      * No TLS CA certificate found
[INFO] 3.11 - Verify that Docker server certificate file ownership is set to root:root
[INFO]      * No TLS Server certificate found
[INFO] 3.12 - Verify that Docker server certificate file permissions are set to 444 or more restrictive
[INFO]      * No TLS Server certificate found
[INFO] 3.13 - Verify that Docker server key file ownership is set to root:root
[INFO]      * No TLS Key found
[INFO] 3.14 - Verify that Docker server key file permissions are set to 400 or more restrictive
[INFO]      * No TLS Key found
[PASS] 3.15 - Verify that Docker socket file ownership is set to root:docker
[PASS] 3.16 - Verify that Docker socket file permissions are set to 660 or more restrictive
[PASS] 3.17 - Verify that daemon.json file ownership is set to root:root
[PASS] 3.18 - Verify that daemon.json file permissions are set to 644 or more restrictive
[INFO] 3.19 - Verify that /etc/default/docker file ownership is set to root:root
[INFO]      * File not found
[INFO] 3.20 - Verify that /etc/default/docker file permissions are set to 644 or more restrictive
[INFO]      * File not found

[INFO] 4 - Container Images and Build Files
[INFO] 4.1  - Create a user for the container
[INFO]      * No containers running
[INFO] 4.2  - Use trusted base images for containers
[INFO] 4.3  - Do not install unnecessary packages in the container
[INFO] 4.4  - Scan and rebuild the images to include security patches
[PASS] 4.5  - Enable Content trust for Docker
[PASS] 4.6  - Add HEALTHCHECK instruction to the container image
[PASS] 4.7  - Do not use update instructions alone in the Dockerfile
[INFO] 4.8  - Remove setuid and setgid permissions in the images
[INFO] 4.9  - Use COPY instead of ADD in Dockerfile
[INFO]      * ADD in image history: [docker/docker-bench-security:latest]
[INFO] 4.10 - Do not store secrets in Dockerfiles
[INFO] 4.11 - Install verified packages only

[INFO] 5 - Container Runtime
[INFO]      * No containers running, skipping Section 5

[INFO] 6 - Docker Security Operations
[INFO] 6.1  - Perform regular security audits of your host system and containers
[INFO] 6.2  - Monitor Docker containers usage, performance and metering
[INFO] 6.3  - Backup container data
[INFO] 6.4  - Avoid image sprawl
[INFO]      * There are currently: 1 images
[INFO] 6.5  - Avoid container sprawl
[INFO]      * There are currently a total of 3 containers, with 1 of them currently running

My 2 cents:
Some informations are available through docker info: 'icc' status could be resolved from there. Run the following command to get data as JSON:
docker info --format '{{json .}}'

It could be piped to jq for parsing and data extraction. It may be a reliable way to get Docker configured states.

Hi @mathieubodin and thanks for reporting this.
Could you please run the script (w/o Docker) or rebuild docker/docker-bench-security locally using the master branch?

Hi,
I ran the following commands:
git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security
sudo sh docker-bench-security.sh

Then I got the following results:
# ------------------------------------------------------------------------------
# Docker Bench for Security v1.3.5
#
# Docker, Inc. (c) 2015-
#
# Checks for dozens of common best-practices around deploying Docker containers in production.
# Inspired by the CIS Docker Benchmark v1.2.0.
# ------------------------------------------------------------------------------

Initializing mer. sept.  4 12:15:07 CEST 2019

[INFO] 1 - Host Configuration

[INFO] 1.1 - General Configuration
[NOTE] 1.1.1  - Ensure the container host has been Hardened
[INFO] 1.1.2  - Ensure Docker is up to date
[INFO]        * Using 19.03.1, verify is it up to date as deemed necessary
[INFO]        * Your operating system vendor may provide support and security maintenance for Docker

[INFO] 1.2 - Linux Hosts Specific Configuration
[WARN] 1.2.1 - Ensure a separate partition for containers has been created
[INFO] 1.2.2  - Ensure only trusted users are allowed to control Docker daemon
[INFO]        * docker:x:995:mbodin
[WARN] 1.2.3  - Ensure auditing is configured for the Docker daemon
[INFO] 1.2.4  - Ensure auditing is configured for Docker files and directories - /var/lib/docker
[INFO]        * Directory not found
[PASS] 1.2.5  - Ensure auditing is configured for Docker files and directories - /etc/docker
[WARN] 1.2.6  - Ensure auditing is configured for Docker files and directories - docker.service
[WARN] 1.2.7  - Ensure auditing is configured for Docker files and directories - docker.socket
[INFO] 1.2.8  - Ensure auditing is configured for Docker files and directories - /etc/default/docker
[INFO]        * File not found
[INFO] 1.2.9  - Ensure auditing is configured for Docker files and directories - /etc/sysconfig/docker
[INFO]        * File not found
[PASS] 1.2.10  - Ensure auditing is configured for Docker files and directories - /etc/docker/daemon.json
[WARN] 1.2.11  - Ensure auditing is configured for Docker files and directories - /usr/bin/containerd
[INFO] 1.2.12  - Ensure auditing is configured for Docker files and directories - /usr/sbin/runc
[INFO]         * File not found

[INFO] 2 - Docker daemon configuration
[PASS] 2.1  - Ensure network traffic is restricted between containers on the default bridge
[PASS] 2.2  - Ensure the logging level is set to 'info'
[PASS] 2.3  - Ensure Docker is allowed to make changes to iptables
[PASS] 2.4  - Ensure insecure registries are not used
[PASS] 2.5  - Ensure aufs storage driver is not used
[INFO] 2.6  - Ensure TLS authentication for Docker daemon is configured
[INFO]      * Docker daemon not listening on TCP
[INFO] 2.7  - Ensure the default ulimit is configured appropriately
[INFO]      * Default ulimit doesn't appear to be set
[WARN] 2.8  - Enable user namespace support
[PASS] 2.9  - Ensure the default cgroup usage has been confirmed
[PASS] 2.10  - Ensure base device size is not changed until needed
[WARN] 2.11  - Ensure that authorization for Docker client commands is enabled
[PASS] 2.12  - Ensure centralized and remote logging is configured
[PASS] 2.13  - Ensure live restore is Enabled
[PASS] 2.14  - Ensure Userland Proxy is Disabled
[PASS] 2.15  - Ensure that a daemon-wide custom seccomp profile is applied if appropriate
[PASS] 2.16  - Ensure that experimental features are not implemented in production
[PASS] 2.17  - Ensure containers are restricted from acquiring new privileges

[INFO] 3 - Docker daemon configuration files
[PASS] 3.1  - Ensure that docker.service file ownership is set to root:root
[PASS] 3.2  - Ensure that docker.service file permissions are appropriately set
[PASS] 3.3  - Ensure that docker.socket file ownership is set to root:root
[PASS] 3.4  - Ensure that docker.socket file permissions are set to 644 or more restrictive
[PASS] 3.5  - Ensure that /etc/docker directory ownership is set to root:root
[PASS] 3.6  - Ensure that /etc/docker directory permissions are set to 755 or more restrictive
[INFO] 3.7  - Ensure that registry certificate file ownership is set to root:root
[INFO]      * Directory not found
[INFO] 3.8  - Ensure that registry certificate file permissions are set to 444 or more restrictive
[INFO]      * Directory not found
[INFO] 3.9  - Ensure that TLS CA certificate file ownership is set to root:root
[INFO]      * No TLS CA certificate found
[INFO] 3.10  - Ensure that TLS CA certificate file permissions are set to 444 or more restrictive
[INFO]       * No TLS CA certificate found
[INFO] 3.11  - Ensure that Docker server certificate file ownership is set to root:root
[INFO]       * No TLS Server certificate found
[INFO] 3.12  - Ensure that Docker server certificate file permissions are set to 444 or more restrictive
[INFO]       * No TLS Server certificate found
[INFO] 3.13  - Ensure that Docker server certificate key file ownership is set to root:root
[INFO]       * No TLS Key found
[INFO] 3.14  - Ensure that Docker server certificate key file permissions are set to 400
[INFO]       * No TLS Key found
[PASS] 3.15  - Ensure that Docker socket file ownership is set to root:docker
[PASS] 3.16  - Ensure that Docker socket file permissions are set to 660 or more restrictive
[PASS] 3.17  - Ensure that daemon.json file ownership is set to root:root
[PASS] 3.18  - Ensure that daemon.json file permissions are set to 644 or more restrictive
[INFO] 3.19  - Ensure that /etc/default/docker file ownership is set to root:root
[INFO]       * File not found
[INFO] 3.20  - Ensure that the /etc/sysconfig/docker file ownership is set to root:root
[INFO]       * File not found
[INFO] 3.21  - Ensure that /etc/default/docker file permissions are set to 644 or more restrictive
[INFO]       * File not found
[INFO] 3.22  - Ensure that /etc/default/docker file permissions are set to 644 or more restrictive
[INFO]       * File not found

[INFO] 4 - Container Images and Build File
[INFO] 4.1  - Ensure a user for the container has been created
[INFO]      * No containers running
[NOTE] 4.2  - Ensure that containers use only trusted base images
[NOTE] 4.3  - Ensure that unnecessary packages are not installed in the container
[NOTE] 4.4  - Ensure images are scanned and rebuilt to include security patches
[PASS] 4.5  - Ensure Content trust for Docker is Enabled
[PASS] 4.6  - Ensure that HEALTHCHECK instructions have been added to container images
[PASS] 4.7  - Ensure update instructions are not use alone in the Dockerfile
[NOTE] 4.8  - Ensure setuid and setgid permissions are removed
[PASS] 4.9  - Ensure that COPY is used instead of ADD in Dockerfiles
[NOTE] 4.10  - Ensure secrets are not stored in Dockerfiles
[NOTE] 4.11  - Ensure only verified packages are installed

[INFO] 5 - Container Runtime
[INFO]   * No containers running, skipping Section 5

[INFO] 6 - Docker Security Operations
[INFO] 6.1  - Ensure that image sprawl is avoided
[INFO]      * There are currently: 1 images
[INFO] 6.2  - Ensure that container sprawl is avoided
[INFO]      * There are currently a total of 3 containers, with 0 of them currently running

[INFO] 7 - Docker Swarm Configuration
[PASS] 7.1  - Ensure swarm mode is not Enabled, if not needed
[PASS] 7.2  - Ensure that the minimum number of manager nodes have been created in a swarm (Swarm mode not enabled)
[PASS] 7.3  - Ensure that swarm services are bound to a specific host interface (Swarm mode not enabled)
[PASS] 7.4  - Ensure that all Docker swarm overlay networks are encrypted
[PASS] 7.5  - Ensure that Docker's secret management commands are used for managing secrets in a swarm cluster (Swarm mode not enabled)
[PASS] 7.6  - Ensure that swarm manager is run in auto-lock mode (Swarm mode not enabled)
[PASS] 7.7  - Ensure that the swarm manager auto-lock key is rotated periodically (Swarm mode not enabled)
[PASS] 7.8  - Ensure that node certificates are rotated as appropriate (Swarm mode not enabled)
[PASS] 7.9  - Ensure that CA certificates are rotated as appropriate (Swarm mode not enabled)
[PASS] 7.10  - Ensure that management plane traffic is separated from data plane traffic (Swarm mode not enabled)

[INFO] 8 - Docker Enterprise Configuration
[INFO]   * Community Engine license, skipping section 8

[INFO] Checks: 76
[INFO] Score: 30

For me, it enlighten there are differences between the Docker image and the source.
Many thanks for the tip !

Just a note: Why checking /var/lib/docker is audited when i configured another folder ?

@mathieubodin yeah, there's inconsistency between source and docker image, but I'll bump the image as soon as more tests have been done.
It's following the CIS Benchmark but should probably be more like mountpoint -q -- "$(docker info -f '{{ .DockerRootDir }}')". I'll look into it.

authors: konstruktoid mathieubodin

repo: docker/docker-bench-security


text:
Fix a typo

Proposed changes
Replace the word translation with translate to make the grammar correct.

Unreleased project version (optional)

Related issues (optional)

The page where I fix a typo at is here.

The page where I fix a typo is here.

@tkeiyama Thanks for your PR. The existing text looks good and is grammatically correct. I'm closing your PR for this reason. Feel free to continue the conversation after I close.

authors: tkeiyama usha-mandya


text:
Update remove.md

Proposed changes

Unreleased project version (optional)

Related issues (optional)

Thanks, @scjane 👍

authors: johndmulhausen scjane


text:
Remove bad, breaky advice

yum remove docker-selinux and yum remove docker-engine-selinux result into a prompt to remove container-selinux package, which, in turn, is a dependency for docker-ce, which results into a prompt to remove it as well.

Proposed changes

Unreleased project version (optional)

Related issues (optional)

Deploy preview for docsdocker ready!
Built with commit bd77b434fe067ddf8285579631ba98b0bfe8cdbd
https://deploy-preview-7975--docsdocker.netlify.com

authors: Drugoy GordonTheTurtle


text:
Sync published with master

Proposed changes
Sync published with master
Unreleased project version (optional)

Related issues (optional)

LGTM @ollypom

Deploy preview for docsdocker ready!
Built with commit 96202f47eb316339038a212a30649f614618596a
https://deploy-preview-9088--docsdocker.netlify.com

authors: GordonTheTurtle ollypom usha-mandya


text:
SOCKS support for docker client

Supporting access to tcp:// docker ports over SOCKS is necessary to access docker-machine hosts that are on the other side of a ssh bastion host. With most other applications, this works by starting a SOCKS tunnel via ssh -D <port> bastion.host and setting the environment variable all_proxy=socks5://localhost:<port>. Poking at Go's proxy support and docker's usage of it, only http:// proxies are supported.
Tidying this up will make using docker-machine on private clouds doable without a ton of manual handholding.

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

I am absolutely certain this is a dup... but GH search is being terrible.

I was surprised to not find an issue about it. I even plowed through some
google searches for different variations of "docker socks" and came up
empty handed.
--
Sent from Gmail Mobile

Here we go, thank you google: #5989
Closing as this is a dup.

repo: docker/docker


text:
Daemon config setting to disable 'legacy' mode on the default bridge

It would be hugely helpful if there was a daemon config setting to disable 'legacy' mode on the default bridge so it can participate in multi-network setups in docker-compose. Or, alternatively, maybe legacy mode is disabled by default when the daemon is started with the -b config parameter to specify a replacement default bridge.

With "legacy mode" you mean the "legacy links"? If you're using the docker compose V2 file format, you'll automatically get the new networking; https://docs.docker.com/compose/compose-file/#versioning

no, it's more to do with how docker-compose uses aliases. If you try to setup a front and a back network where the back network is the default bridge then docker-compose complains with:

Network-scoped alias is supported only for containers in user defined networks

If, like me, you have overridden the default bridge (in my case, with Ubuntu's Fan Network stuff) and you want to present a limited number of containers from a docker-compose group on that default bridge so others containers can talk to them then at the moment you can't do it.

e.g. as a pseudocode example:
version '2'
services:
  web:
    image: nginx
    networks:
      - front
      - default
  db:
    image: mysql
networks:
  front:
    external:
      name: bridge

We won't make changes to the default (bridge) network because that would break backward compatibility. Is would it be an option to create your own bridge, and use that for your custom ("front") network?
docker network create \
  --opt "com.docker.network.bridge.name=mybridge" \
  --subnet=192.168.5.0/24 \
  towernet

I assume the --opt setting is to tell docker to use an existing interface on the host. I guess this is something that I could work out how to script via Salt and write a conditional test for so the network isn't re-added multiple times etc.
But the main advantage of using the default bridge network for the fan network is that it is used by default by all containers without people having to remember to specify an alternative. My suggestion was to provide an advanced flag in the daemon config (defaulting to false) that deactivates the special legacy mode for the default bridge, possibly only if the bridge has also been replaced using -b. An alternative suggestion might be to allow defining of a 'default custom network' that is automatically defined on daemon startup and used by default for all created containers using run etc. but it seems to me that this is simply repeating what the default bridge does.
TBH, the default bridge being in legacy mode makes no difference to me other than the docker-compose error Network-scoped alias is supported only for containers in user defined networks so maybe the problem is a docker-compose one. I'll raise an issue with docker-compose as well :)

The "Network-scoped alias is supported only for containers in user defined networks" is because the legacy links (which are used on "bridge"), don't use DNS-based discovery

Yeah, I do understand the difference but having the only globally defined, auto-used network as a 'legacy' one that you can't then intermix with other networks via docker-compose is a bit of a blocker to easy setup of some pretty basic network configurations. I completely agree with you about not wanting to break legacy support and totally understand why the default bridge has a legacy mode, I'm just suggesting the ability to optionally switch the default bridge over to 'new, shiny' mode.
Or, alternatively, as I suggest, allow for the automatic creation (on daemon startup) of a custom default network that is used in preference to the default bridge network for all containers run without specifying a network using --net or equiv.
Out of curiosity, if you had a managed (in my case via SaltStack) multi-machine cluster that had an existing 'overlay' network and you wanted to deploy docker into this environment and have containers share this network as well as creating their own private networks via docker-compose etc. then how would you do it? In a way where people can just use docker run without needing to remember to supply a --net parameter or add a block of custom network config to the bottom of their docker-compose files?
If there's a better way that I'm missing then I'm open to hear it as I just want to get things working :)

@far-blue in v2 mode, compose automatically creates custom networks without the need for any additional configuration. Infact, if it is run on top of Swarm, it automatically creates an overlay network that is multi-machine cluster capable.
I don't understand your use-case though. Yes, it will be convenient to have all of the networks (legacy and user-defined) support all the features. But we had specific requests not to do that, especially for backward compatibility reasons as @thaJeztah mentioned.
I guess it will help if we understand your use-case better to see if we have a reasonable alternative.

fair enough :)
I have an existing mesh network which doesn't rely on docker overlays or docker-based networking plugin. My wish is to have containers and some other non-container services all available on this mesh network. Specifically being able to share the network between containers and non-containers is important. I can currently do this by configuring the docker daemon to replace the default docker0 bridge with my existing network interface and by controlling the IP range docker uses on each machine using the cidr settings etc. This all works fine for individual containers launched via docker run. Containers don't need to port-map to the host and they can talk to each other via 'exposed' ports. External access to services on the network is via proxies on each host.
But then we have docker-compose. Maybe I'm thinking of container groups managed by docker-compose incorrectly but I consider each container group to be an 'island' with its own little private network. Only the specific container(s) and port(s) that I wish to be accessible to the rest of the mesh network should be exposed to the mesh network and the rest is self-contained. So I'd expect each docker-compose container group to have a private network auto-generated - which works. But then I'd also expect to be able to specify which containers and possibly also which ports on those containers are exposed to the mesh network.
And that's where things break.
I have 2 problems - an inconvenience and a blocker.
The inconvenience (raised in another issue) is that the auto-generated bridge networks are 'class B' /16 subnets on 172.n.0.0/16 which seems to be non-configurable. I do understand that if I wanted to use an overlay network setup instead that I could do that with something like consul - and I have played successfully with this - but I don't currently need it because I don't need the containers within a container group to be spread across multiple hosts.
The blocker is that you can't add the default bridge network (which, if you remember, is my existing network) to the v2 container network configuration in docker-compose because you end up with an error about Network-scoped alias is supported only for containers in user defined networks.
What I'm aiming for is everything I've described - most of which is working - plus the ability to create these container group 'islands' with their own private networks and specific bridges over to the mesh network.
To my way of thinking, the problem is either:

that docker's default bridge network runs in a 'legacy' mode (for very good reasons, as I agree above) or
that docker-compose can't cope with mixing custom and legacy bridge networking

My suggestion in the issue I've raised here is that while legacy mode for the default bridge network is very helpful and will be beneficial in most cases, maybe it would be a good idea to have a config parameter that allows the default bridge network to work in 'custom network' mode, like a custom-defined network. As suggested above, this could maybe even be limited to when docker0 isn't being used or when ip-masq is disabled or other such conditions. This would allow docker-compose to treat the default network the same as all custom bridge networks while still maintaining the existing behaviour described above where containers launched via docker run still use the mesh network without any additional per-container configuration.
An alternative would be to modify docker-compose but this seems more of a work-around. After all, is the plan to keep docker0 in 'legacy' mode for ever? Or is there a plan to migrate it at some point? If so, then a config flag will be needed at that point anyhow.
What I'm after is a bridge network that:

Has configurable ip, interface and cidr - which docker can do
Is initiated automatically when docker daemon starts - which docker can do
Is used by default by all containers created via docker run without needing additional parameters - which docker can do
Can be used with docker-compose v2 networking - which can't currently be done

And just to repeat so I'm completely clear, I am not suggesting removing legacy mode for the default bridge. I am suggesting an advanced daemon config option to allow the default bridge to be switched from legacy mode to new-style mode if and only if the person doing the configuration really wants to and understands that it breaks backwards compatibility etc.

authors: far-blue mavenugo thaJeztah


text:
fix typos, grammar, more concise wording

Signed-off-by: Liana Lo liana.lixia@gmail.com

Saweet.  Thank you. LGTM  You know we are looking for a writer.  HINT

Seems that my pull request was caught in a broken build last night. Should I push again to restart the build, or can the Docker team do this manually?
As for being a technical writer -- I'm flattered. :) But for now, I'll continue developing my skills as a software engineer. I am very glad to see that Docker has high regard for good docs!

@lolilo no worries. I've seen that failure before.  We'll pull this anyway, I just need to do an internal check.
Best of luck with your engineering pursuits.  I'm sure you'll be wonderful.

LGTM - @lolilo do you have time to make those 2 lines wrapped at 80 chars?

@SvenDowideit I can fix the line breaks after the bday. I need to retest the flow after all the tweaking this week.

authors: SvenDowideit lolilo moxiegirl


text:
Remove duplicated period in link

Signed-off-by: Charles Chan charleswhchan@users.noreply.github.com

LGTM

LGTM

authors: SvenDowideit charleswhchan cpuguy83


text:
Minor typo

Signed-off-by: Hu Keping hukeping@huawei.com

LGTM waiting janky

LGTM
might be good to slip minor changes like this into other PRs - just not sure an extra space in a comment is worthy of its own PR  :-)

This was catched when I review the code about OOM notify mechanism and find nothing else to fix :) , I am agree with you that this typo should be left to other PRs.

authors: HuKeping duglin runcom


text:
Fixed /etc/defaults/docker to /etc/default/docker

/etc/default/docker is the correct file location in my system, and also according Docker's own documentation at https://github.com/docker/docker/blob/master/docs/articles/configuring.md#configuring-docker

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "patch-1" git@github.com:jbruni/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

@jbruni can you sign-off your commit using the instructions that @GordonTheTurtle gave?
LGTM once signed-off

I've done all at GitHub... just created another PR... sorry for the mess

authors: GordonTheTurtle jbruni thaJeztah


text:
Fix error for env variables example in docker reference

- What I did
Fix a typo in a small example using env variables in a command
- How I did it
See previous
- How to verify it
I created & ran a dockerfile that used a RUN command that passed an env variable as an arg.  (Also the correct syntax is used ~10 lines up)
- Description for the changelog
Fix docker reference error for env variables example
- A picture of a cute animal (not mandatory but encouraged)

thanks! LGTM

authors: clawconduce thaJeztah


text:
cli: remove unnecessary initErr type

- What I did
Removed unnecessary initErr type. It closes #22754
- How I did it
Took @runcom suggestion from #22754 and applied it
- How to verify it
Compile docker and try commands
- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

ping @aaronlehmann @runcom @vdemeester

Ok, it doesn't work :D

LGTM (assuming the other way @aaronlehmann isn't feasible)

LGTM 🐯

LGTM


text:
Make archive links absolute

The archive is only available on docs.docker.com, and not when doing a "make docs", so relative links will not resolve.
Making these links absolute, so that they always point to the live "docs.docker.com" domain.
/cc @sfsmithcha

LGTM

author LGTM

authors: sfsmithcha thaJeztah


text:
[19.03 backport] Entropy cannot be saved

backport of https://github.com/moby/moby/pull/39336 for 19.03
Remove non cryptographic randomness.

ping @justincormack @cpuguy83 ptal

repo: docker/engine


text:
hyperledger/fabric-peer/manifests/latest 500 ERROR

(HTTP code 500) server error - {"message":"Get https://registry-1.docker.io/v2/hyperledger/fabric-peer/manifests/latest: net/http: TLS handshake timeout"}

Go to https://hub.docker.com/r/hyperledger/fabric-peer/tags/
Observe no latest tags were created for that image
Select a different tag in Kitematic (if one exists)
🎉  enjoy container running.

Ideally you open an issue with the repo owner to let them know how frustrating it is that they don't have a latest image tagged

authors: FrenchBen spyhole

repo: docker/kitematic


text:
Problems instance docker

Expected behavior
Actual behavior
Information about the Issue
Docker instances eliminated
Steps to reproduce the behavior

... When rebooting machine
...It has happened more than once.

When you say instance, do you mean containers? Take a look at proper container deployment:
https://docs.docker.com/engine/admin/start-containers-automatically/


text:
hyperledger fabric

Expected behavior
Actual behavior
Information about the Issue
Steps to reproduce the behavior

...
...

No information provided or steps to replicate - Closing 😞

De : French Ben notifications@github.com
Envoyé : mardi 13 mars 2018 00:59:56
À : docker/kitematic
Cc : DIBI KOUADJO JEAN MARTIAL; Author
Objet : Re: [docker/kitematic] hyperledger fabric (#3640)
Closed #3640https://github.com/docker/kitematic/issues/3640.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/docker/kitematic/issues/3640#event-1517512958, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Ae66QF_mra-a8Xfna6Ylh3W28wGl8NoCks5tdwv8gaJpZM4Sj7ea.

authors: DIBI-KOUADJO FrenchBen


text:
Command line for Maven step, requires a manual Ctrl-C to Break. The output in the document needs to be updated.

** PLEASE ONLY USE THIS ISSUE TRACKER TO SUBMIT ISSUES WITH THE DOCKER LABS TUTORIAL CONTENT **

If you have a bug working with Docker itself, not related to these labs, please file the bug on the Docker repo *
If you would like general support figuring out how to do something with Docker, please use the Docker Slack channel. If you're not on that channel, sign up for the Docker Community and you'll get an invite. *
Or go to the Docker Forums *

Please provide the following information so we can assess the issue you're having
Which lab is it that you're having issues with?

Description

Steps to reproduce the issue, if relevant:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
(paste your output here)

Output of docker info:
(paste your output here)

Additional environment details (AWS, Docker for Mac, Docker for Windows, VirtualBox, physical, etc.):
At step to run: mvn -f docker-java-sample/pom.xml install -Pdocker
The output hanging at the [INFO] DOCKER> [hellojava:latest]: Waited on log out 'Hello World!' 506 ms, as the docker is running in the foreground. The document needs to mention this. It will require a Ctrl-C to break.

Which lab is this regarding?

Workshop, Docker for Java Developer
Sent from my Sony Xperia™ XZ smartphone
---- Mano Marks wrote ----
Which lab is this regarding?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/docker/labs/issues/242#issuecomment-294582057, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ATKzd7oHX6vnQnTSXXHLGMJMVtwvjYAHks5rw8r3gaJpZM4M_gam.
WARNING - CONFIDENTIALITY NOTICE
This e-mail and any attachments may contain confidential and privileged
information.
Any use, disclosure, copying or dissemination of this information by a
person other than an intended recipient is not authorized and may be
illegal.
If you are not an intended recipient, please notify the sender
immediately by return e-mail, delete this e-mail and destroy any copies.
Thank you.

@arun-gupta

authors: ManoMarks WilliamYan-BCAA

repo: docker/labs


text:
Issue running dockersamples/static-site on Raspbian (Raspberry Pi 3)

Please provide the following information so we can assess the issue you're having
Which lab is it that you're having issues with?
https://github.com/docker/labs/blob/master/beginner/chapters/webapps.md
Description
When running docker run --name static-site -e AUTHOR="Your Name" -d -P dockersamples/static-site, the container seems to start, and it returns the container id. However, docker port static-site does not return anything, and docker ps returns no rows (other than the header).
docker ps -a indicates the container started, and exited a few second later with exit code 1.
738cc5bf48f5        dockersamples/static-site   "/bin/sh -c 'cd /usr…"   12 seconds ago      Exited (1) 10 seconds ago                         static-site
docker info returns 0 running containers.
When trying to run the container again, it returns an error message that the container name is already in use by the container (and gives the container id of that container). When using sudo docker rm <id> it returns the container id. Issuing the command once more, returns that there is no such container (as expected).
Steps to reproduce the issue, if relevant:

Install Docker through the install script (Raspbian on Raspberry Pi 3)
(sudo) docker run --name static-site -e AUTHOR="Your Name" -d -P dockersamples/static-site
(sudo) docker ports static-site

Describe the results you received:
Nothing.
Describe the results you expected:
443/tcp -> 0.0.0.0:32772
80/tcp -> 0.0.0.0:32773

(or similar)
Additional information you deem important (e.g. issue happens only occasionally):
hello-world, ubuntu and alpine images ran fine.
Output of docker version:
Client:
 Version:       18.02.0-ce
 API version:   1.36
 Go version:    go1.9.3
 Git commit:    fc4de44
 Built: Wed Feb  7 21:23:59 2018
 OS/Arch:       linux/arm
 Experimental:  false
 Orchestrator:  swarm

Server:
 Engine:
  Version:      18.02.0-ce
  API version:  1.36 (minimum version 1.12)
  Go version:   go1.9.3
  Git commit:   fc4de44
  Built:        Wed Feb  7 21:20:04 2018
  OS/Arch:      linux/arm
  Experimental: false

Output of docker info:
Containers: 9
 Running: 0
 Paused: 0
 Stopped: 9
Images: 4
Server Version: 18.02.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9b55aab90508bd389d7654c4baf173a981477d55
runc version: 9f9c96235cc97674e935002fc3d78361b696a69e
init version: 949e6fa
Kernel Version: 4.9.35-v7+
Operating System: Raspbian GNU/Linux 8 (jessie)
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 970.9MiB
Name: raspberrypi
ID: TNR5:GC45:QSRR:D5NV:F2VF:6QRV:A3DI:GTRP:3YDU:JEFS:XGY7:FIEB
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: No cpuset support

Additional environment details (AWS, Docker for Mac, Docker for Windows, VirtualBox, physical, etc.):
Physical Raspberry Pi 3.

I have this exact problem as well, did you ever find a way round this?

same issue here, but no solution :(

Still happening a year later...

authors: FudgementDay braunschweig brunoRyckaert dodds2009


text:
Proposal: Channel reference identifiers

Background
Currently the libchan protocol does not define the mechanism for connecting both ends of a channel.  This leaves it up the implementer to either use the underlying spdy stream id or something custom.  Using the spdy stream id should not be used since the identifier is part of a lower and separate layer and depending on the spdy implementation may not be accessible.  In order for clients to be compatible the protocol should have channels define an identifier in the same way as byte streams and communicate that identifier through the spdy headers.  The channel header can use the same reference id space as byte streams and be distinguished by the existance of a parent identifier (which byte streams do no have since they do not have hiearchy).
Proposal
I am proposing adding  a 'libchan-parent-ref' spdy header to be used when creating channels and requiring both channels and byte streams to make use of the existing 'libchan-ref' header.  The decision on whether a new stream is a channel will then be made by the existance of 'libchan-parent-ref' rather the absence of 'libchan-ref'.  The msgpack object will then communicate the reference identifer rather than anything custom or the spdy stream id.

Already in master and will be in 0.1.0 tag

repo: docker/libchan


text:
Container in the default network cannot access a mapped port from a custom network

This is with docker 1.9.1
To duplicate:
docker network create test
docker run -p 8888:80 --rm --name=nginx --net=test nginx

# success from host
wget -T 1 http://$(docker-machine ip default):8888/

# success from container on same network
docker run --rm --net=test busybox wget -T 1 http://$(docker-machine ip default):8888/

# timeout from container on default network
docker run --rm busybox wget -T 1 http://$(docker-machine ip default):8888/

The "docker-machine ip default" is the same in all three cases, and represents the docker host's ip
I'd expect that the container on the default network should still be able to access the mapped port from the test network, since from it's perspective it is just trying to reach some external ip, and that external ip/port is reachable outside the container.
If the wget container is run on a different host than the nginx one, then the connection succeeds.
Tagging @sanimej as he helped verify this as an issue on irc

This issue should be fixed since 1.11.x.
Can you please confirm ? Thanks.

@wr0ngway It has been detected that this issue has not received any activity in over 6 months. Can you please let us know if it is still relevant:

For a bug: do you still experience the issue with the latest version?
For a feature request: was your request appropriately answered in a later version?

Thank you!
This issue will be automatically closed in 1 week unless it is commented on.
For more information please refer to https://github.com/docker/libnetwork/issues/1926

authors: GordonTheTurtle aboch wr0ngway

repo: docker/libnetwork


text:
Server snapshot

This builds on top of #329 to add optional server side snapshotting.

Looks like we would not be able to merge this PR because of merge conflicts. Please rebase, fix conflicts, and force push to your branch.

I think there might be a bug in the way we generate the code coverage:  server/snapshot/snapshot.go is not covered, but I guess because nothing ever calls it no coverage report was produced?  I filed https://github.com/docker/notary/issues/337 for it.
But it would be awesome to add some test coverage for that :D

Yeah, was planning to add coverage for snapshot.go.

2 non-blocking nitpicks:  https://github.com/docker/notary/pull/332#discussion_r46746874 and https://github.com/docker/notary/pull/332#discussion_r46744670, which can be addressed in a separate PR if necessary.  Otherwise LGTM!  :D

authors: GordonTheTurtle cyli endophage

repo: docker/notary


text:
what happend to docker swarm when i restart all nodes in swarm at the same time?

CST 16:31.
I have encountered with a problem when I do something with docker swarm cluster.'cos I need multi image sources to get tarball to start my containers,when I start the no.1 docker service(with the order docker service create),I changed the docker image sources by modift /etc/default/docker and then restart the docker service at the same time(to my swarm cluster, all 3 nodes are all manager).when I run the order 'docker node ls',yes ,it's ok, but when I do something with the serices which started before, it does not work gracelly(the output may like this, Error response from daemon: rpc error: code = 4 desc = context deadline exceeded or Error response from daemon: rpc error: code = 2 desc = raft: no elected cluster leader  ).
how could i fix the 'bugs',and the phenomenon caused by restart docker service at the same time(by ansible scripts)

@KielChan your issue is related to Docker Swarm Mode, which is different from the github.com/docker/swarm project. See "Swarm Disambiguation" for details: https://github.com/docker/swarm/blob/master/README.md
I'm closing this issue, but can you please open this issue on the github.com/docker/docker repo?

authors: KielChan nishanttotla

repo: docker/swarm


text:
Fix doc for NODE column

Swarm docker ps output nolonger have NODE column, So this updates the doc
Fixes: #2081
Signed-off-by: Kai Qiang Wu(Kennan) wkqwu@cn.ibm.com

LGTM

authors: HackToday vieux


text:
add featured content to webervice config

adds featuredContentUrl to webservice config to set in dockstore.yml

Is there any place to add documentation for this?

repo: dockstore/dockstore


text:
Custom ISO

Is your question not already answered in the FAQ?

[X] I made sure the question is not listed in the FAQ.

Is this a general question and not a technical issue?

[X] I am sure my question is not about a technical issue.

Question
Hi,
This is my Docker Compose file. It doesn't take my custom ISO.
I don't understand why ?
services:
windows_1:
image: dockurr/windows
container_name: windows_1
environment:
RAM_SIZE: "4G"
CPU_CORES: "4"
USERNAME: "admin"
VERSION: "tiny11"
PASSWORD: "changeme!"
DISK_SIZE: "20G"
devices:
  - /dev/kvm
volumes:
  - /home/mike/docker_config/windows/windows.iso:/custom.iso
  - /home/mike/docker_config/windows/vms_1:/storage

cap_add:
  - NET_ADMIN
ports:
  - "8001:8006"
  - "3390:3389/tcp"
  - "3390:3389/udp"
stop_grace_period: 2m

Bad ISO :)

repo: dockur/windows


text:
cannot install "ember-validations": "2.0.0"

It says version not found when doing npm install

try "ember-validations": "~ 2.0.0" or ember-validations": "2.0.0-alpha.3"

I get

Error while processing route: details.index Could not find module ember-validations imported from fluvax/controllers/details

bower ember-validations#~2.0.0-alpha.4          install ember-validations#2.0.0-alpha.4
bower install
├── ember#2.1.0
├── ember-cli-shims#0.0.6
├── ember-cli-test-loader#0.2.1
├── ember-data#2.1.0
├── ember-load-initializers#0.1.7
├── ember-qunit#0.4.11
├── ember-qunit-notifications#0.1.0
├── ember-resolver#0.1.21
├── jquery#1.11.3
├── loader.js#3.3.0
└── qunit#1.19.0

fluvax/controllers/details
import Ember from 'ember';
import EmberValidations from 'ember-validations';

export default Ember.Controller.extend(EmberValidations,{
 ...
}

Seems odd but I get
PS D:\Ember\fluvax> npm list ember-validations
fluvax@0.0.0 D:\Ember\fluvax
└── (empty)

npm ERR! code 1

and
PS D:\Ember\fluvax> npm list ember-validations@2.0.0-alpha.4
fluvax@0.0.0 D:\Ember\fluvax
└── ember-validations@2.0.0-alpha.4

Is there something wrong with the package files?
Noel

I know this is an old issue, but I thought I should put the solution here for those who are googling it:
Make sure you ember-validations is set to 2.0.0-alpha.4 in package.json.  Then run rm -rf dist tmp bower_components node_modules to clear any caches or anything, followed by npm install and bower install.  The next time you build or serve, it should work then.

I am going to close this issue for now, feel free to reopen this issue if you feel like it's still relevant and we should take a look at it.

authors: BenjaminHorn ColtonProvias MohamadAtieh martndemus nsharrok

repo: dockyard/ember-validations


text:
Ensuring we get correct properties to compare to when model property is blank

We are loading our validations from the database and they are coming from model properties. We have some validation lengths set to 0, and it's saying the length is invalid because it was previously checking if the option existed vs the actual model property. This checks the option property against the correct value now.

@bcardarella anything else I need to do to get this merged in?

I recognize this as an issue but I believe this is better addressed by the effort I'm making to allow validations to grab property paths regardless of the validator. So, I'm addressing this is the base class with streams. The problem I see with this solution is that paths in Ember convey the idea that I can change the value and the state of the validator will change. This solution only reads when the associated property value changes, not when one of the option's property path value changes.

Thanks for the response. Are your base changes close? If not would it be possible to merge this in to fix it temporarily and release a new version (alpha 4) so that we can get the fixes committed past the last v2.0.0-alpha.3 release?

@aaronbhansen it doesn't make sense to pull in a temp change to only go in a different direction. My plan is to have a 2.0 RC for ember-validations by early June

@aaronbhansen for the other Q, I have not begun the changes to the base class. I have in mind what needs to be done, if you wanted to tackle it that would be much appreciated :smile:

If you want to write an RFC describing the changes, or put in here, I can look at making the changes. I won't have time for a couple of weeks, but then I should.

I am going to close this PR for now, feel free to reopen this PR if you feel like it's still relevant and we should take a look at it. If you do, please make sure the code is rebased against master.

authors: aaronbhansen bcardarella martndemus


text:
Don't unschedule orphanRemoval for null

Fixes #1255.
This fixes an issue where adding null to a PersistentCollection (or overwriting an element with null) would try to unschedule orphanRemoval for that object.

ping @gabma

@malarzm @alcaeus Nice! That fixed it. :+1:
Thanks for your prompt replies guys!

authors: alcaeus gabma malarzm

repo: doctrine/mongodb-odm


text:
Please add License file

sorry for the spam, just adding the issues to each repo for documentation (heh) purposes.

Fixed in 48446f60f324e75272e152db7728a3f12f678cf7

authors: tmcw waldyrious

repo: documentationjs/gulp-documentation


text:
Send On Behalf Of isn't sent in some methods

I noticed the part where the accounts SOBOUserID field is attached to the request is only in some but not all methods.  Is there a reason for this?  For example the basic Envelope.Create method that accepts a filepath does not do it, but the other versions do.  Same with the Account.LoginDirect method.

@joepetrakovich are you using SOBO for your solution? I'm just curious to see if you're actually using this capability. I suspect SOBOUserID is missing from some things simply because we didn't use it for our integrations and forgot to add it. We can certainly add it to Envelope.Create()
As for LoginDirect() I'm not sure that makes sense. can you explain why you would need it there? SOBO is a mechanism of using 1 user for authentication while sending on behalf of another user, so that you don't actually need to login anyone else. Care to elaborate about your scenario?

@InbarGazit Yeah I believe we will need to use SOBO in our solution, that's what someone from DocuSign told us anyway, I'm just the developer in the trenches ;)
I think my mistake was assuming it needed to be added to both login and envelope creation.  Apparently not!  So really the issue I'm bringing up is that SOBO is left out of Envelope.Create(filePath).
It also seems to be left out if the authentication format is XML.

authors: InbarGazit joepetrakovich


text:
Resolve npm vulnerabilities

Has resolution for frontend and backend dependencies. As well as some styling resolutions for material ui and bootstrap.

Should be good to go. The majority of the line changes are a result of running the script pretty in package.json Frontend. This formats the project to conform to eslint rules for tab spacing and using single quotes for strings.

Handled todays merge conflicts and took out some unused variables

Handled some more merge conflicts should be good again

repo: dod-advana/gamechanger-web


text:
🛑 Dogchef partners is down

In 6a0b1c1, Dogchef partners ($DOGCHEF_PARTNERS_URL?$BF) was down:

HTTP code: 403
Response time: 119 ms

Resolved: Dogchef partners is back up in 58f8b36.

repo: dogchef-be/uptime-monitor


text:
fix windows build notes location in readme

This fixes the link to the windows build instructions in the README. Closes https://github.com/dogecoin/dogecoin/issues/1667.

Hi! Thanks, this was already fixed for 1.14.3-dev - we're getting really close to release now, so the master branch will be reflecting this soon too.

authors: patricklodder slightlyskepticalpotat

repo: dogecoin/dogecoin


text:
Issues with https://staging.doi.org/the-identifier/resources/factsheets/key-facts-on-digital-object-identifier-system

Under Standardization, the link to DOI System and Standard Identifier Schemes is broken.
Under Documentation, the link to DOI Handbook is broken.

Fixed in ef260ed

authors: cazinc wkreth

repo: doi-foundation/doi-website


text:
Wiki: Aco is now the default for AMD RADV (Mesa 20.0)

The Wiki refers to use:
RADV_PERFTEST=aco
for AMD RADV. However this now default since mesa 20.0:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/0c569e22d1d038f651d5b5aa3cc46e7a5c6e152f

Just changed the recommended version to 20.2 which iirc was the one that enabled ACO by default.

Just changed the recommended version to 20.2 which iirc was the one that enabled ACO by default.

authors: Thaodan doitsujin

repo: doitsujin/dxvk

license: Zlib


text:
NieR Automata: Lighting artifacts

Description: When Ingame looking at areas with direct lighting, artifacts appear all over the place. When looking at a shadow spot which doesn't have any direct lighting, the artifacts don't show (it happens with or without Fullscreen Mode, I just happened to be on Windowed mode when taking the second screenshot).

@kd-11 also managed to get this artifact output before when developing with Vulkan for RPCS3 and mentioned that it was a memory barrier issue, if that helps narrowing down the issue.
Software information
NieR Automata via Wine Steam
Tested several graphical settings combinations including minimal, none fix the issue
System information

GPU: GeForce 960M
Driver: Proprietary NVIDIA 387.34
Wine version: wine-3.6 Staging (also tested on wine-3.5 Staging)
DXVK version: 0.42 (also tested on 0.41, unfortunately I'm not able to build the project to check the latest git as well)

Apitrace file(s)
I will provide one as soon as I'm able to, need someone to indicate how to set Wine back to using the default D3D11 DLLs so I can capture it as I haven't found a way to do so
Log files

d3d11.log: NieRAutomata_d3d11.log
dxgi.log: NieRAutomata_dxgi.log

You might want to update your driver, that version is ancient and known to have issues with DXVK.

Thanks for the heads up, nvidia-387 is actually the latest drivers Ubuntu 17.10 offers so I didn't even notice there were new ones.
I have now added the ppa:graphics-drivers/ppa and am installing nvidia-396, will report back as soon everything is updated.

__GL_NextGenCompiler=0

Graphical Issues are fixed on nvidia-396
__GL_NextGenCompiler=0 also provides a speed boost over not using it, bringing performance to about the same as on Windows (suffering from the same slow motion issue you mentioned on the linked thread above becuase it's a 960M but that's the card being well below game requirements)
Anyways, DXVK looking really cool, hoping that Special K injection will eventually work under Wine for that sweet performance boost, already finished the game on my Windows Desktop once and it's truly deserving of the love it's receiving :smile:
Closing the issue as solved

authors: AniLeo doitsujin libcg


text:
Global buffer

Basically do the vkd3d-proton thing of only creating one single VkBuffer per memory allocation whenever possible to open up some larger refactor. Works best if both maintenance4 and maintenance5 are supported, we still support creating a regular VkBuffer if necessary.
Needs testing with various games and various drivers.

Seems like these commits were merged into master. Shouldn't this PR be closed?

authors: artemyto doitsujin


text:
[GUI] - Device Detail - Problem with boolean data

When a boolean attribute is selected, no one data is shown.

authors: betefaber fernandoMessias

repo: dojot/dojot


text:
[GUI] "Device timeout" attribute is not editable when an "Actuator" attribute has been added to the template

Steps to reproduce the problem:

Click "New Template"
Add an actuator attribute
Add "Device Timeout" configuration attribute

Test OK.


text:
change vanilla theme's variables color to a different one than the string color (in python)

makes coding a bit harder when i cant tell strings and variables apart; in default vscode theme the string color is a dark orange while variables are blue; so you can tell if it's a variable or string

here's default vscode theme; its alot easier to differentiate strings from variables

repo: doki-theme/doki-theme-vscode


text:
Building assets with Grunt/Gulp

Please, help me to figure out what I can do to make dokku-alt start building my static assets with Gulp (or Grunt) after push, but before ./manage.py collectstatic (I am deploying Django app).
Can I use some plugin or I need to write a hook for myself? It seems to be a common task and I think that I just missing it in the docs. Thanks!

Solved the problem with the following configuration:
.env:
export BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-python.git

.buildpacks:
https://github.com/fedosov/heroku-buildpack-nodejs-gulp-bower
https://github.com/heroku/heroku-buildpack-python.git

repo: dokku-alt/dokku-alt


text:
Property scrollEl doesn't work

There is no possibility to use custom scrollEl the following issue is showing in the browser console.
Uncaught DOMException: Failed to execute 'querySelector' on 'Document': '[object HTMLDivElement]' is not a valid selector.
I suppose, after your commit https://github.com/dollarshaveclub/stickybits/commit/50d47c70e9c032298fd2e1f1f46c0de71c5250aa, you have added this line of code
https://github.com/dollarshaveclub/stickybits/blob/50d47c70e9c032298fd2e1f1f46c0de71c5250aa/src/stickybits.js#L61
and forgot to remove this, or vise versa
https://github.com/dollarshaveclub/stickybits/blob/50d47c70e9c032298fd2e1f1f46c0de71c5250aa/src/stickybits.js#L165

Seems so.

Please provide a codepen so we can test this.

Here is an example hosted by codesandbox: https://codesandbox.io/s/y5k2oo0xx.
I found that this issue exist when useStickyClasses: true, otherwise everything works correct.

Here is an example hosted by codesandbox: https://codesandbox.io/s/y5k2oo0xx.
I found that this issue exist when useStickyClasses: true, otherwise everything works correct.
P.S. But if I don't use useStickyClasses: true it doesn't work at all. Element does not follow the page while scrolling.

Mh, is this reproducible with normal setups and codepens using the latest version?

@DanielRuf, I've created another example by using codepen: https://codepen.io/mahotskyi/pen/vdJGBR. Take a look when you will have a little time.

@enheit Thank you for catching this!!!

authors: DanielRuf enheit yowainwright

repo: dollarshaveclub/stickybits


text:
[auto-bump] dependency by max-hoffman

:coffee: An Automated Dependency Version Bump PR :crown:
Initial Changes
The initial changes contained in this PR were produced by go geting the dependency.
$ cd ./go
$ go get github.com/dolthub/<dependency>/go@<commit>
$ go mod tidy

Before Merging
This PR must have passing CI and a review before merging.
After Merging
An automatic PR will be opened against the LD repo that bumps the bounties version there.

This PR has been superseded by https://github.com/dolthub/bounties/pull/1483

repo: dolthub/bounties


text:
[auto-bump] dependency by JCOR11599

:coffee: An Automated Dependency Version Bump PR :crown:
Initial Changes
The initial changes contained in this PR were produced by go geting the dependency.
$ cd ./go
$ go get github.com/dolthub/<dependency>/go@<commit>
$ go mod tidy

Before Merging
This PR must have passing CI and a review before merging.
After Merging
An automatic PR will be opened against the LD repo that bumps the bounties version there.

This PR has been superseded by https://github.com/dolthub/bounties/pull/1523


text:
[auto-bump] dependency by andrew-wm-arthur

:coffee: An Automated Dependency Version Bump PR :crown:
Initial Changes
The initial changes contained in this PR were produced by go geting the dependency.
$ cd ./go
$ go get github.com/dolthub/<dependency>/go@<commit>
$ go mod tidy

Before Merging
This PR must have passing CI and a review before merging.
After Merging
An automatic PR will be opened against the LD repo that bumps the bounties version there.

This PR has been superseded by https://github.com/dolthub/bounties/pull/922


text:
Request args model inheritance

My code is as following, generated documentation however contains documentation only for properties of "CustomDtoExtended" class, it seems to be unable to resolve comments of the base class, is there something I'm missing?
   public class CustomDtoExtended : CustomDto
    {
        /// <summary>
        /// Some other property
        /// </summary>
        public int OtherProp { get; set; }
    }

    public abstract class CustomDto
    {
        /// <summary>
        /// ID of the Group
        /// </summary>
        public int Id { get; set; }

        /// <summary>
        /// Current Name of the group
        /// </summary>
        public string Name { get; set; }
    }

    /// <summary>
    /// Creates or modifies Group
    /// </summary>
    /// <param name="data">Group data</param>
    /// <returns></returns>
    [HttpPost]
    public async Task<ActionResult<int>> Post([FromBody]CustomDtoExtended data)
    {

    }

Inheriting of XML comments is not currently supported by Swashbuckle and I've no plans to add this anytime soon.

Any news here?

I don't intend on adding this functionality

I don't intend on adding this functionality

authors: Kshopper93 brunolau domaindrivendev


text:
No automatic response generation for IAsyncEnumerable with Newtonsoft Json

Hello,
When using IAsyncEnumerable to stream the result of a list, Swagger UI does not recognize the type correctly and does not generate the 200 response correctly.
The generated schema looks like this
"200": {   "description": "Success",   "content": {     "application/json": {       "schema": {         "$ref": "#/components/schemas/MyModelIAsyncEnumerable"       }     }   } }
There is a workaround, by manually setting the responses like this, but you also have to set the error responses too.
[ProducesResponseType(typeof(IEnumerable<MyModel>), StatusCodes.Status200OK)]
The issue is also mentioned here: https://github.com/domaindrivendev/Swashbuckle.AspNetCore/pull/1398#issuecomment-727796704
The version I use:
Swashbuckle.AspNetCore 6.3.0
Swashbuckle.AspnetCore.Newtonsoft 6.3.0
Best regards
David

This is also happening if you're returning an object that has an IAsyncEnumerable as a property. I.e. this doesn't work properly:
[DataContract]
public record class PageResponse<TResult>
{
    [DataMember]
    public required Guid QueryId { get; init; }
    [DataMember]
    public DateTimeOffset TimeStamp => DateTimeOffset.UtcNow;
    [DataMember]
    public required IAsyncEnumerable<TResult> Results;
}

The Results properly is not serialized.

This is fixed in DotSwashbuckle 3.0.9

authors: DavidFlamme Havunen JohnGalt1717


text:
GatherElements

This will cause an error: action.settings.ElementAffect is undefined

Hi xlshen,
ElementAffect is initialised with a default value. Can you provide a case that can cause action.settings.ElementAffect to be undefined? I'm not sure it's possible for the GatherElements function to be triggered with the action.settings.ElementAffect property to not be defined (unless you explicitly set it to undefined).
Code submitted is fine, just making sure there's a use case :)
Cheers
Dom

Hi domsammut,
When the document is loading and if your document contains these opreations below, these operations will execute first when you called ScrollAppear  function,
$.each(['after', 'append', 'appendTo', 'before', 'clone', 'detach', 'empty', 'html', 'insertAfter', 'insertBefore', 'prepend', 'prependTo', 'remove', 'replaceAll', 'replaceWith', 'unwrap', 'wrap', 'wrapAll', 'wrapInner'], function (index, trigger) {
        var prev = $.prototype[trigger];
        if (prev) {
            $.prototype[trigger] = function () {
                var passthrough = prev.apply(this, arguments);
                $.prototype.ScrollAppear('DomUpdate');
                return passthrough;
            };
        }
    });

It will cause $.prototype.ScrollAppear('DomUpdate');
DomUpdate: function () {
            action.InternalSettings.ShowElements = [];
            action.InternalSettings.ResetElements = [];
            action.GatherElements();

        },

At this time, My function like this has not called yet. But the DomUpdate has operated and each time it will call action.GatherElements();. In this circumstance, the error will happen.
$('.homepage-part3').ScrollAppear({
        ElementAffect: ".scrollAppear",
        AddClass: 'appear',
        ElementsToShow: 12,
        PixelOffset: 200
    });

This is my example:
var shortcut = $('body').shortcut(); shortcut.gotop.init(); This is code before calling the ScrollAppear function.  In it, I used appendTo operation like this:
 topLink.click(function () {                     $('html,body').animate({ scrollTop: 0 }, 200);                     return false;                 }).appendTo($('body'));
When I called $('.homepage-part3').ScrollAppear({         ElementAffect: ".scrollAppear",         AddClass: 'appear',         ElementsToShow: 12,         PixelOffset: 200     });
It will execute the above appendTo operation first and at this moment, the action.settings is undefined yet.
jquery.scrollappear.js?V=635983835888361325:73 Uncaught TypeError: Cannot read property 'ElementAffect' of undefined
You can test a case like this. If there is something unclear, let me know.

authors: domsammut xlshen

repo: domsammut/jQuery-ScrollAppear