Improve Nginx Documentation

Pico's Nginx documentation is practically non-existent.  It should be improved and provide some detailed examples equivalent to what is provided for Apache in .htaccess.
A discussion has already begun on https://github.com/picocms/Pico/commit/d8f916691809b19b05104906ee3700c5cf3f8407.  It seems there is a lot to consider when using a Regex Location Block for Pico's rewriting, as Nginx will only use the first matching rule it finds.  Since a typical Nginx setup also uses Regex to detect when to send a page to PHP, a misconfiguration can easily break PHP detection altogether.
The solution seems to be placing the PHP Location Block above any Pico rewrite blocks, that way any requests to index.php get properly matched.
In the current example, location ~ ^/pico(.*) matches both the Page ID you're trying to rewrite (eg /pico/page) and also the index itself (at /pico/index.php, resolved from the URI /pico/?page).
Since /pico/index.php matches location ~ ^/pico(.*), Nginx has succeeded in finding a match and will not move on to match it to location ~ \.php$.  The PHP page gets served as a download file instead of interpreted by PHP.

Hi, I'm the same Robby from IRC. While your proposed solution works, the solution I'm using is actually to include the PHP location block in each location block where I need it. To avoid having to duplicate this in too many places I put the PHP location block in a snippet file and include it in each location block as needed.
The reason I'm currently doing it like this is because of the following.
Not sure if this is useful for the situation described in this issue, but here is a problem I had:
The other day I was looking to password protect some specific directories of another PHP application with nginx and http auth and I found that PHP was still getting executed instead of requesting http auth.
The following links has relevant reading material on nginx and (nested) location blocks:
https://serverfault.com/questions/375961/nginx-basic-http-authentication-on-php-script
https://serverfault.com/questions/119076/how-to-use-fastcgi-globally-and-basic-auth-in-sublocations-in-nginx
Back to pico.
Note: I'm not using a subdirectory for pico anymore, I've put it in the root directory instead.
So, I noticed pico has an .htaccess file and I wanted to do some nginx equivalent of protecting for example pico's config directory, by doing this:
location /config/ {
  return 403;
}

But, the above does not block access to /config/config.php (a blank page is shown instead of a 403).
So, taking into account the information in the 2 links I mentioned above, the following location block does block access to /config/config.php:
location /config/ {
  location ~ [^/]\.php(/|$) {
    return 403;
  }
}

Other than that, my current location block for pico is like this:
location ~ ^/(.*) {
  include snippets/fastcgi-php-custom.conf;
  index index.php;
  try_files $uri $uri/ /?$1&$args;
}

My snippets/fastcgi-php-custom.conf contents, based on the information in this link:
location ~ [^/]\.php(/|$) {
  fastcgi_split_path_info ^(.+?\.php)(/.*)$;
  if (!-f $document_root$fastcgi_script_name) {
    return 404;
  }
  fastcgi_pass unix:/var/run/php5-fpm.sock;
  fastcgi_index index.php;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_param PATH_INFO $fastcgi_path_info;
  include fastcgi_params;
}

Note that I'm not knowledgeable about regex, so most likely there's a better way to do some of the things I mentioned. I just wanted to share my findings.

In order to block access to config or other folders, I think you'd need to match it with regex similar to this:
location ~ /(config|content|content-sample|lib|vendor)/.* or location ~ /config/.*
The important part being that you'd need to tell it to match anything in the config folder, not just the folder itself.
If you haven't checked it out yet, there's some more examples at https://github.com/picocms/Pico/commit/d8f916691809b19b05104906ee3700c5cf3f8407.  The discussion started there, but should really be continued here.
It's a really funny coincidence that you brought up the Nginx issues when you did because I just decided to check it out.  Together it seems we've generated a bit of interest on the topic.
Not sure if I'd agree with the idea of including the php block in every location block... but I didn't even know you could nest location blocks.  I've got a lot of similar sections across several different site configs, so I plan to explore using include to simplify that process a bit.
So far it sounds like we have three different approaches to the subject that each have some benefits and drawbacks.
Ultimately, there may not be a "right" answer, but we'll have to decide what would be the best configuration for new users.  An experienced Nginx user will likely be able to take whatever example we provide and fit it to their own needs/preferences anyway.

So, there's a few criteria that I think should be focused on for the example config:

Ease of Use - The easier to implement, the better.  If it can be configured in a way that requires almost no user interaction (like being as simple as adding .htaccess), that should be the goal.  If possible, require no editing by the user.  Perhaps it's just a config file that they add to their site config using include.

Performance - One of the biggest benefits of Nginx is the performance it brings.  From the brief research I've done, it seems that different solutions can have vastly different performance.  They even have a section of their documentation titled Things to Avoid at all Costs.  I'm not sure, for example, if using Location to rewrite the url vs using rewrite has any sort of performance difference.  They both seem like valid options, but if I had to guess I'd say rewrite is more taxing.  While this difference is probably not enough to matter, we should still treat each situation as if it will be a production level deployment with tons of simultaneous users.

Simplicity - Why write in 50 lines what can be done in 10.  The example should be simple and easy to read.  Unfortunately, I think it'll be hard to draw the line between what counts as "configuring Pico" and "general Nginx configuration".  Do we hold the user's hand to make sure they get PHP configured properly or should this be up to Nginx tutorials?  As I've described, I had a lot of difficulty with PHP due to the way Nginx processes Locations.  The information on this issue was surprisingly hard to find and not something that was immediately obvious to me when I encountered difficulty.  We could write probably write pages and pages about different configuration solutions, so I'm really not sure where the line would be drawn.  Perhaps provide a simple example config, but an entire page of additional reading if the user is interested.

Just some food for thought to hopefully spark more discussion.

@smcdougall To block access to folders and files this rule is enough, no need for more regex.
location ~* /(config|content|content-sample|lib|vendor)
The essential part is WHERE you place this. It MUST be before the php processing rule in order to block also php files. Processing order is the word. I testet it and posted a config here: d8f9166

Ah, that makes sense.  Good to know.
Do you have any other input on the criteria I thought up?  You seem like you're probably the most experienced of the four of us right now. :smiley:

So what has worked well for me was a separate pico-common config that I include in all my Pico sites.  It contains all the access rules and the php rule.  The main benefit being that it gives me one place to edit the common settings for all my sites.  I also have a second pico-root config that contains the rewrite rule currently in Pico's docs.  Most of my sites have Pico in the Document Root, so I just include pico-root for quick access to that configuration.  The one site I have setup with dual Pico subfolders has it's own configuration instead of including pico-root.  Here are the two examples:

pico-common

        index index.html index.htm index.php;

        location ~* /\.ht {
                deny all;
        }

        location ~* /(config|content|content-sample|lib|vendor) {
        return 404;
        }

        location ~ \.php$ {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
        }

pico-root

       location ~ ^/(.*) {
                try_files $uri $uri/ /?$1&$args;
        }

Pico-root (or a manual rewrite configuration) gets included after pico-common in the server block.
What I'm aiming for here is simplicity.  I like writing something once and using it everywhere.
Just wanted to share what seems to be working well for me.
I plan to draft up a Docs page about Nginx configuration sometime later today.  My plan is to extend the existing section slightly, then link to another page entirely about Nginx.  The page will be able to go in depth about the how's and why's of different configuration tips.  It'll touch on important points, like Nginx's processing order, the fact that Nginx uses a centralized configuration (and how that makes configuring Pico a little harder), etc.
Obviously I'm by no means an expert on the topic, but I think I've gathered enough information to provide a good write-up on the subject.  After I get the initial write-up done, it'd of course be open to further contribution.  @iwedler, I'd especially like it if you could weigh in a little on your config, such as why you prefer your @pico fallback location over the regex location method (Pros, cons, etc).
I'll link the page and the PR here once I've written it.

Great to hear! Looking forward to your PR :+1: :smiley:
Just a minor suggestion: You don't need a regex when installing Pico to the root directory (the regex's objective is to remove the subdirectory part of the URL). The following works just fine in this particular case:
location / {
    try_files $uri $uri/ /?$uri&$args
}

That's true I suppose.  It got lost somewhere in my quest for a universal config. :laughing:   Would you rather I restore that example to the Docs and use the location ~ ^/pico(.*) as an optional "How to configure Pico in a subfolder" example?

I'm not sure yet, depends on how the docs page will look like.

Random discovery:
SetEnv PICO_URL_REWRITING 1 in Apache is
fastcgi_param PICO_URL_REWRITING 1; in Nginx (in the PHP location block)
No more $config['rewrite_url'] = true; :smile:
That'll definitely be going in the Nginx page.  I'm partway done with it so far, but it's taking longer than I though.  Probably won't have it up today, but it's definitely in progress.

I finished a rough draft of the page.  Take a look at #345.  Any input is appreciated. :smiley:

Looks great so far! The only issue is the php example location block, it poses a security risk. It is best to use the example from the nginx wiki due to security reasons mentioned here, using the example mentioned in the first link doesn't require fiddling with the cgi.fix_pathinfo (it says so in the Notes section on the bottom) setting as it can break things that rely on PATH_INFO/PHP_SELF.

It should be sufficient to let the PHP location match index.php only. Pico doesn't require PATH_INFO either.

I had forgotten about cgi.fix_pathinfo.  Since PHP configuration is a little out-of-scope for Pico's docs, it sounds like the best solution would be to match only index.php.  I'll probably add a brief explanation and/or a link with more details about why we've chosen this.
Also, I'd like to make the PHP block as simple as possible.  While the other blocks are meant to be copied, the PHP block is really just an example.  I'll try to emphasize this a little more.  Since PHP configuration is somewhat dependent on the user's system, I don't want them to just copy and paste it.  It should only be used as a reference.

:confused: I've actually flip-flopped on this and I think I'd rather just mention cgi.fix_pathinfo as a warning.
I've had time to reread my page and remember that I planned to link to a php-fpm tutorial anyway.
I don't like the Nginx Wiki's example because it uses an if statement and I'm trying to keep the configuration as lean as possible.
Although I like the elegance of specifically matching index.php, I feel like it would be over-complicated to explain.  I think it would require extra effort as well, such as:

If you used location /index.php$ You'd have to either have Pico in your Document Root or configure it to include your subfolder.
If you used location ~ /index.php$, you wouldn't have to configure anything, but I feel you'd still be vulnerable to the security risk described above.

On top of that, I think I'd have to break PHP Configuration into "Document Root" and "Subfolder" sections, which would make it more confusing.

I know its meant as an example, but people are people and will copy paste, so its better to have a secure example in there in the first place. Also, do keep in mind people who may also wish to run other .php files on a Pico site, I'm sure there's people out there that would or do.
What's the problem with the if? It's perfectly fine to use it there. For Pico's case, and since the consensus here seems to have become to lock it down to index.php only, I guess the if statement is not needed, but otherwise it should be there.

Reading the above, I feel more than one example configuration seems to be needed. For people that use Pico and also have other .php files, so it can't be locked down to just index.php (and then the if statement becomes a must-have for security).

Nah, now that I've thought about it, I don't want to lock it down to index.php either.
And Nginx even states that If is Evil. :laughing:
The thing is though, if they haven't followed another guide to properly setup php-fpm, then it's not going to be listening on that socket anyway.  The copied Nginx rule won't do anything as far as I know.
I think a good, "Warning:" should be sufficient to inform a user about the security issue.  Ultimately though, nothing we're providing in this example is at fault for the security issue. :confused:

Yeah, I've seen that If is Evil page, but note that they also say that it is perfectly fine to use it there in the Notes section at the bottom of the PHP example page. Then there also becomes no need to even touch or mention cgi.fix_pathinfo at all.

It's a tough call.  I really don't want to make the example code more complicated than it has to be.  Also, to me, it feels a lot like a workaround to what is clearly an insecure default setting for php-fpm.  I don't like workarounds, lol, I'd rather a proper fix.
I will give it credit that it's the official recommendation of the Nginx Wiki though.  I can see merits to doing it either way.
@PhrozenByte, @iwedler, what do you think?  I'll go whichever way the crowd goes on this issue.

I don't feel like having the appropriate background knowledge to tell what solution is better...
The only thing I can say is that Pico neither uses PATH_INFO nor needs to execute any other file than index.php. Security always comes first, simplicity second. If both solutions have the same security level, choose the simpler one.

I'll likely include the if statement.  The only extra security it brings is security from the user's own misconfiguration, but that is still extra security.
Ultimately, if the user wants to remove that line because they feel they know better, they can!
A user who isn't as experienced though would benefit from this extra included protection.
I suppose it's on the same level as blocking .htaccess or denying Indexes in Apache.  These are safety measures that should be set by an experienced user, but they're provided nonetheless.

On the subject of .htaccess, I've been wondering what would be more secure: Denying access to the file, or returning 404.
The general example floating around the web is to use deny all to prevent access.  But technically this does still inform a malicious party that there is a file there, it's just being denied.
Returning 404 on the other hand, would be the same response they'd get if the file really didn't exist.
I'm sure there's a good reason that deny all is used in every example I've come across, so I'm not about to change it.  It's just something I've been wondering about.

Just a short question about the PATH_INFO topic: What happens if you remove both the fastcgi_split_path_info directive and if statement? Wouldn't be a try_files $uri =404; sufficient then?

I don't know.  I don't think so, because the issue is with php-fpm, not Nginx.  Nginx doesn't actually try to load the .php file, it just passes the path along to php-fpm.  If we put a try_files in there, my suspicion is that it would either:

Try to serve the .php file as a download if it was before fastcgi_pass, or
Ignore try_files altogether if placed after fastcgi_pass.

@PhrozenByte On a side note, how does the document read to someone who's not familiar with Nginx?  I tried to make it both informative and easy to skim over for someone who already knows Nginx.

I've tried it in a virtual machine with Debian Jessie and the following config works just fine for me. By the way, Debian's default config uses try_files, too (plus some extra lines which seem to make PATH_INFO work, but that's none of our business :smile:).
location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
}

I haven't read the document in whole yet, but the parts I've read yet look great. I'll catch up on that after you've finished your work :smiley:

I'll try out that example in a little bit and see if I can't break it. :smiling_imp:
I'd love for the solution to be that simple, but I have my doubts.
Overall, I think the content of the page is done.  I've reread it a few times and it seems pretty good to me.  I'm just looking for things that may not come across as clear as I thought they did.
I've also got to decide what to do with _docs/config.md.  I need to figure out if it's feasible to boil down the examples and fit just the important bits on that page, or if I'll have to take the section out and just provide a link to the new Nginx page.

That that is Debian's default config doesn't mean its safe, though. ;)

I just noticed that this is one of the solutions described in the nginx wiki: https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#passing-uncontrolled-requests-to-php :smile:

Oh, I was just editing my post. :)

Yeah, according to the comments in the file the additional lines are about making PATH_INFO work, thus we shouldn't need them.

Huh... neat.  Makes me wonder why it's not the example included in Ubuntu.  It's probably been added more recently.
That makes me wonder if that solution works on all versions of Nginx.  The version in 14.04 is really old (1.4.6).  It came out shortly before 14.04's release.  Really need to find the time to either upgrade my server to 16.04 or migrate it to Arch. :unamused:
I'll test out the example and double-check that it works okay on my older version of Nginx.

@smcdougall

On the subject of .htaccess, I've been wondering what would be more secure: Denying access to the file, or returning 404.

The general example floating around the web is to use deny all to prevent access. But technically this does still inform a malicious party that there is a file there, it's just being denied.

Returning 404 on the other hand, would be the same response they'd get if the file really didn't exist.

I'm sure there's a good reason that deny all is used in every example I've come across, so I'm not about to change it. It's just something I've been wondering about.

I've come up with an elegant way to fix this:
location ~* /(config|content-sample|lib|plugins|vendor|CHANGELOG.md|composer.json|composer.lock|CONTRIBUTING.md|LICENSE.md|README.md) {
  return 404;
  error_page 404 /?$uri&$args;
}

This makes Pico return its own 404 instead of nginx's own errors, which is even better I think.

@smcdougall

On the subject of .htaccess, I've been wondering what would be more secure: Denying access to the file, or returning 404.

The general example floating around the web is to use deny all to prevent access. But technically this does still inform a malicious party that there is a file there, it's just being denied.

Returning 404 on the other hand, would be the same response they'd get if the file really didn't exist.

I'm sure there's a good reason that deny all is used in every example I've come across, so I'm not about to change it. It's just something I've been wondering about.

I've come up with an elegant way to fix this:
location ~* /(config|content|content-sample|lib|plugins|vendor|CHANGELOG.md|composer.json|composer.lock|CONTRIBUTING.md|LICENSE.md|README.md) {
  error_page 404 /?$uri&$args;
  return 404;
}

This makes Pico return its own 404 instead of nginx's own errors, which is even better I think.
Note that I'm using Pico in the root directory, so for Pico installations in subdirectories, paths should be adjusted.

If you mean the path for config, content, etc, I don't think you'd have to adjust it for a subdomain.  Since your regex doesn't begin with ^, it'll match it anywhere in the url, not just at the beginning.  You'd still have to change the path on the error_page line, so perhaps that's what you meant.
I hadn't thought of adding those other files to the 404 rule.  That's a good idea.  I'll test it out sometime and add something similar to the example.  @PhrozenByte Those files should probably be added to Pico's .htaccess as well.
This doesn't actually answer the question you quoted from me though.  I was asking specifically about the .htaccess file itself.  Is it better to deny access to it or to return 404?  All the examples online suggest using deny, but my own logic tells me that using return 404 would be "safer".

Your thoughts about the reasons for using 404 Not Found instead of 403 Forbidden are completely right (plus some minor other "technical" reasons about how Apache works). Some other projects (like ownCloud) do it the same way.
Unfortunately I don't like extending the config|content|... rule to these fully static files in the base directory. I don't see a reason why we should block access to them by default. @Robby-, can you please explain your thoughts?

My assumption for his reasoning is that these are files that are included by default in Pico, but not intended to be accessed on the webserver.  Although they pose no security risk, they are files that a determined user could navigate to.
I don't know if they should be blocked or not, but I had never thought about the fact that they can be accessed.  When I read his comment, I had a moment where I thought "you can't do that... can you?".  Sure enough, if I navigate to /README.md on one of my Pico sites, it does indeed fetch me Pico's readme as a download.  (Well, it would, if it wasn't NotePaper's readme I have stored there...)
It just feels a little uncomfortable.  I just went through the "Pico Showcase" on the Wiki... all but three entries willingly offered me their README.md file.  And one of those three appeared to be down altogether, so I can't really count that.  Two of the readme's weren't even for Pico. :laughing:
I don't know what else to say about it (plus, I'm tired and his is going to be my last comment for the night).  I just hadn't even thought about the fact that obviously these files would be accessible.  I'd assume the same probably holds true for the owners of all the Pico sites I just probed. :unamused:
Anyway, I still don't know if they should be blocked by default, but was my reaction after reading @Robby-'s comment.

I should never say something is my last comment for the night :unamused:
Just caught up on some of the commits from the last few hours.  I'll add .git to the Nginx 404 rule like in https://github.com/picocms/Pico/commit/49cb6c144a6c8a11b408667138046c61978e92cc and see about rewriting it to Pico's internal 404 document as well.

Starting with Pico 1.1 you can use try_files $uri $uri/ index.php; no matter Pico is installed in a subdirectory or not, see 6465c2b0a99b5262f25083af70b94668c1cac6af for details.

I'll have a chance to finish this up tomorrow (4/27).  Do you want me to focus on 1.1 for it or focus on getting instructions finished for Pico's current version?
I should be able to easily get the existing examples finalized, merged, and then work on 1.1 afterward.

I should be able to easily get the existing examples finalized, merged, and then work on 1.1 afterward.

That's probably the best way to deal with it :smiley:

I thought so too. :+1:
I'm going to finish it up with the examples we had finalized a few days ago.  Things like using Pico's internal error page can be an enhancement for 1.1.  It's a simple enough idea, but it will take a little more debugging before I'm sure we have a bullet-proof example.  With that in mind, it might as well be done with the new infrastructure in 1.1.

Sorry for the late response.
@smcdougall I also think 404 is the better response, instead of a 403.
@PhrozenByte My reason for adding these files to the 404 block is just personal preference I guess.
I do not wish these files to be served at all to someone who probes the webserver for seemingly random files, I guess I could just remove them manually on each Pico installation, but this method seems much more practical. Also changelog files and the like can be used to determine or find out if any vulnerable software may be installed on the webserver.

Indeed.  I think it still deserves more discussion going forward.  For now I'm working to finalize what we had, and we can address the rest afterward.  In 1.1, it'll be much easier to use Pico's internal error page for things as well.
I could also potentially add a tip near the bottom about blocking access to those other files.  I definitely understand where you're coming from.

Hmm... Yeah, hiding the version number isn't a bad idea (i.e. blocking access to composer.json, composer.lock and CHANGELOG.md - even though I don't know other composer projects doing this), but what's about README.md, LICENSE.md and CONTRIBUTING.md? Sure, they actually don't provide information what isn't accessible in another way (and the MIT license doesn't require a user to let a website visitor know the license of the software used), but they still may help a visitor of a website to determine which software is being used - maybe he wants to use it, too. Furthermore a user can still remove the files or block access to them manually. What do you think about adding composer.json, composer.lock and CHANGELOG.md as compromise? Or can you think of reasons why blocking access to README.md, LICENSE.md and CONTRIBUTING.md has more advantages than disadvantages?

I'm really not sure where I stand on the issue.  I'd rather keep the examples simple, but if it could be a security issue then maybe it needs to change.
Right now, I'm looking at keeping feature parity with .htaccess.  If we decide to block these files, I feel it should be in both places.
By the way, I noticed something that might need to be fixed in .htaccess because it needed to be fixed for Nginx.  When you added .git to the rewrite rule in .htaccess, you forgot to account for .'s meaning in regex.  A period would match any character, so while it would technically work, it should probably be changed to \. to escape it.
I've done that in my current copy of Nginx.md, and I've also combined the .htaccess rule with the rest of the Pico folders, since they're all return 404 now anyway. :smiley:

I think I've addressed most of the concerns we've discussed here, minus the ones postponed for 1.1.  I'd call this page ready for review now.  There's probably still some last minute fixes to make, so tell me what you think.  Go ahead and tear it apart. :wink:
http://smcdougall.github.io/Pico/nginx/
http://smcdougall.github.io/Pico/docs/#nginx-configuration

Great, now I need to update it again. :unamused:
(:laughing:)

@smcdougall's nginx configuration page finally got merged and he IMHO did a great job! :smiley: You can find the final document at http://picocms.org/in-depth/nginx/. Any further thoughts about this @all?
@smcdougall, @Robby-, @iwedler


How to use android selector on pressed change item background color

I am trying to  change item background color on press, not when released.
I have previously got that behaviour by using in my android project drawable/catalog_item_selector:
<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
  <item android:state_pressed="true" android:drawable="@color/brand_yellow"/>
  <item android:drawable="@color/itemBackground"/>
</selector>

I have used this with a recyclerview and adapter where each item is rendered as a relative layout with background set as
android:background="@drawable/catalog_item_selector"
The effect I get is when pressed the background is highlighted.
In order to achieve the same with FlowListView I am trying to use native renderer which does not work:
[assembly: ExportRenderer(typeof(FlowListViewInternalCell), typeof(FlowListViewInternalCellRenderer))]
namespace Ui.Droid.XamForms.Renderers
{
    public class FlowListViewInternalCellRenderer : ViewCellRenderer
    {
        protected override Android.Views.View GetCellCore(Cell item, Android.Views.View convertView,
            Android.Views.ViewGroup parent, Android.Content.Context context)
        {
            var cell = base.GetCellCore(item, convertView, parent, context);

            cell.SetBackgroundResource(Resource.Drawable.catalog_item_selector);

            var listView = parent as Android.Widget.ListView;
            if (listView != null)
            {
                //listView.SetSelector(Resource.Drawable.catalog_item_selector);
                listView.CacheColorHint = Android.Graphics.Color.Transparent;
            }

            return cell;
        }
    }
}

I am not setting any background color on any item template each cell can take background from the native renderer, nut still it does not change background on pressed.
Is there any other way to achieve item background change on press.

You can use somthing like this: http://www.mrgestures.com
Or implement a custom View (which will be your cells root view) and implement tap gestures via custom renderers.


De-duplicate test logging

Right now we get double the messages:
[2016-09-09 23:56:24,681|root|INFO]: Response from marathon: {'portDefinitions': [{'port': 0, 'protocol
[2016-09-09 23:56:24,681] INFO: Response from marathon: {'portDefinitions': [{'port': 0, 'protocol': 'tcp',

/me wonders if we should find a way to de-duplicate all the local logging basicConfig stuff....
That said, this looks good as is.
:ship:


cloudflare: failed to create TXT record: Authentication error (10000) with DNS certresolver

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you do?

This gives the following output:
time="2022-11-22T00:16:02Z" level=debug msg="Looking for provided certificate(s) to validate [\"my.domain\"]..." providerName=letsencryptDns.acme ACME CA="https://acme-staging-v02.api.letsencrypt.org/directory"
time="2022-11-22T00:16:02Z" level=debug msg="Domains [\"my.domain\"] need ACME certificates generation for domains \"my.domain\"." providerName=letsencryptDns.acme ACME CA="https://acme-staging-v02.api.letsencrypt.org/directory"
time="2022-11-22T00:16:02Z" level=debug msg="Loading ACME certificates [my.domain]..." ACME CA="https://acme-staging-v02.api.letsencrypt.org/directory" providerName=letsencryptDns.acme
time="2022-11-22T00:16:02Z" level=debug msg="Building ACME client..." providerName=letsencryptDns.acme
time="2022-11-22T00:16:02Z" level=debug msg="https://acme-staging-v02.api.letsencrypt.org/directory" providerName=letsencryptDns.acme
time="2022-11-22T00:16:03Z" level=debug msg="Using DNS Challenge provider: cloudflare" providerName=letsencryptDns.acme
time="2022-11-22T00:16:03Z" level=debug msg="legolog: [INFO] [my.domain] acme: Obtaining bundled SAN certificate"
time="2022-11-22T00:16:03Z" level=debug msg="legolog: [INFO] [my.domain] AuthURL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/4399196724"
time="2022-11-22T00:16:03Z" level=debug msg="legolog: [INFO] [my.domain] acme: Could not find solver for: tls-alpn-01"
time="2022-11-22T00:16:03Z" level=debug msg="legolog: [INFO] [my.domain] acme: Could not find solver for: http-01"
time="2022-11-22T00:16:03Z" level=debug msg="legolog: [INFO] [my.domain] acme: use dns-01 solver"
time="2022-11-22T00:16:03Z" level=debug msg="legolog: [INFO] [my.domain] acme: Preparing to solve DNS-01"
time="2022-11-22T00:16:05Z" level=debug msg="legolog: [INFO] [my.domain] acme: Cleaning DNS-01 challenge"
time="2022-11-22T00:16:05Z" level=debug msg="legolog: [WARN] [my.domain] acme: cleaning up failed: cloudflare: unknown record ID for '_acme-challenge.my.domain.' "
time="2022-11-22T00:16:05Z" level=debug msg="legolog: [INFO] Deactivating auth: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/4399196724"
time="2022-11-22T00:16:06Z" level=error msg="Unable to obtain ACME certificate for domains \"my.domain\"" error="unable to generate a certificate for the domains [my.domain]: error: one or more domains had a problem:\n[my.domain] [my.domain] acme: error presenting token: cloudflare: failed to create TXT record: Authentication error (10000)\n" rule="PathPrefix(`/dashboard`)" providerName=letsencryptDns.acme ACME CA="https://acme-staging-v02.api.letsencrypt.org/directory" routerName=https-dashboard@file

But weirdly enough, if I go inside the container and copy-paste the output of cat /run/secrets/cloudflare-my-domain-dns-edit and cat /run/secrets/cloudflare-zone-read, and then use these for the following command:
podman run -it --env CLOUDFLARE_DNS_API_TOKEN=<contents of cloudflare-my-domain-dns-edit> \
                            --env CLOUDFLARE_ZONE_API_TOKEN=<contents of cloudflare-zone-read> \
                            docker.io/goacme/lego \
                            --email <my email> \
                            --dns cloudflare \
                            --domains my.domain run

I get the following output:
[...]
2022/11/22 00:48:10 [INFO] [my.domain] acme: Waiting for DNS record propagation.
2022/11/22 00:48:18 [INFO] [my.domain] The server validated our request
2022/11/22 00:48:18 [INFO] [my.domain] acme: Cleaning DNS-01 challenge
2022/11/22 00:48:20 [INFO] [my.domain] acme: Validations succeeded; requesting certificates
2022/11/22 00:48:21 [INFO] [my.domain] Server responded with a certificate.

Thus, the API tokens are definitely correct, yet when Traefik tries to use them I get cloudflare: failed to create TXT record: Authentication error (10000).
Things I've tried
Rerolling both tokens, setting the scope of both tokens to all zones, storing the secrets files with a newline at the end or without a newline at the end.
What version of Traefik are you using?
v2.9.5
What is your environment & configuration?
traefik.yml
global:
  checkNewVersion: true
  sendAnonymousUsage: false

entryPoints:
  http:
    address: :8080
    http:
      redirections:
        entryPoint:
          to: https

  https:
    address: :8443
    http:
      tls:
        options: modern
        certResolver: letsencryptDns
        domains:
          - main: my.domain
      middlewares:
        - auth

log:
  level: DEBUG

api:
  dashboard: true

certificatesResolvers:
  letsencryptDns:
    acme:
      email: <my email>
      storage: /root/acme.json
      dnsChallenge:
        provider: cloudflare
      caServer: https://acme-staging-v02.api.letsencrypt.org/directory  # Staging environment

providers:
  file:
    directory: /root/conf
    watch: true

Inside /home/traefik/containers/traefik/conf/ I have:
modern.yml
tls:
  options:
    modern:
      minVersion: VersionTLS13

auth.yml
http:
  middlewares:
    auth:
      basicAuth:
        users:
          - "<username>:<password hash>"

dashboard.yml
http:
  routers:
    dashboard:
      rule: PathPrefix(`/dashboard`)
      service: api@internal

If applicable, please paste the log output in DEBUG level
I can provide the full log if that's interesting.

The decision of the bot has been validated by a human.
Your error is indicative of a problem with your token.
Inside Traefik, the env vars are handled by lego itself, there is no specific code in Traefik for that.
If you need more help come to the community forum.

Note you are not using the same env vars in your 2 examples:
CF_ZONE_API_TOKEN_FILE and CF_DNS_API_TOKEN:
--secret cloudflare-zone-read \
	--env CF_ZONE_API_TOKEN_FILE=/run/secrets/cloudflare-zone-read \
	--secret cloudflare-my-domain-dns-edit \
	--env CF_DNS_API_TOKEN=/run/secrets/cloudflare-my-domain-dns-edit \
	--volume /home/traefik/containers/traefik/acme.json:/root/acme.json:Z 'docker.io/library/traefik:v2.9.5'

CLOUDFLARE_DNS_API_TOKEN and CLOUDFLARE_ZONE_API_TOKEN:
podman run -it --env CLOUDFLARE_DNS_API_TOKEN=<contents of cloudflare-my-domain-dns-edit> \
                            --env CLOUDFLARE_ZONE_API_TOKEN=<contents of cloudflare-zone-read> \

If you want to use a file to store your token the suffix _FILE is required.

@ldez I know, that's because I directly pasted in the contents of the file to do the second step. If you want I can try using files for the second step as well, and see if that works.

Alright, using files I get the same error with Lego. So either that's a bug in Lego or I did something wrong. Thanks for poking me to look deeper into it.

I only see now that I was using CF_DNS_API_TOKEN instead of CF_DNS_API_TOKEN_FILE. I have no idea how I missed that, sorry for the noise.


Document dependencies required to build rav1e.

I decided to try out rav1e this weekend. There were dependencies that I needed to install but weren't explained in the documentation. It's a good idea to note that we need these libraries and how to install them.

Thanks! Yeah, this happens because we now inherit all libaom deps.

Cool, I'm a contributor now!

Actually did you need to install these deps for "cargo build" to work? I'm trying to drop at least the wx dep.

My memory is fuzzy now but I think so.


Naigaras sap6 arg

Description
As part of our Hackathon 2024 activities, we added 20 ARG queries to the SAP checklist.
Related Issue
non

Checklist

[x] I've tested my changes to ensure they are ready for review.
[x] I've read the CONTRIBUTING.md guide.
[ ] I've updated the documentation (if applicable).
[x ] Resource Graph queries have been included (and tested) for recommendations where ever possible[^note].
[ ] Resource Graph queries have NOT been included (please explain below).

Additional Information
Lines 613 and 1140 are highlighted (red), but there were no problems with the execution results of the query itself.
Reviewer Notes
Is there a specific area you’d like feedback on? Please highlight it here. We're here to help and learn together! 💡
review_checklist (SAP)_nonmacro_Naoki+Syed.xlsx
[^note]:
Details on how to add Azure Resource Graph queries to recommendations can be found here.

Hello @erjosito !
Thank you for pointing that out!
I've corrected all the things you pointed out, but there are still many == cases remaining. Would it be better to change them all to =~?

I would suggest to do that. By using =~ your queries will be more solid, in case the PG changes the casing of provider names or property keys or values.

Hey @erjosito ,
i modified all the character from == to =~ .
please check it!

Fantastic thanks a lot @NaokiIgarashi !


Propose HttpActionScopeSeedDataInterceptor

At Faire, we want to be able to have ActionScoped values in all of our scopes. For example we want to seed something like an ActionInfo data class, which contains the type of action (Job, HTTP request, RPC, etc), as well as some metadata about the Action (perhaps path). We could use to help tag metrics with the action type they came from.
Currently there is no way to modify the seed data that Misk passes to the ActionScope. This is a proposal to change that, and allow users to bind their own seed-data interceptors, modifying the map before passing it to ActionScope::enter.

Works locally, but it seems the tests are refusing to run w/ Github Actions

Yeah, test failure looks unrelated.
ClientServerTraceTest > traceHopsFromClientToServerToServer() FAILED
    java.lang.IllegalArgumentException: no spans!
        at misk.testing.ConcurrentMockTracer.take(ConcurrentMockTracer.kt:20)
        at misk.testing.ConcurrentMockTracer.take(ConcurrentMockTracer.kt:29)
        at misk.tracing.ClientServerTraceTest.traceHopsFromClientToServerToServer(ClientServerTraceTest.kt:109)


feature request: cssInJs template literal tag instead of function

I love inline-css, but I don't like the mental gymnastics I need to do to convert css into a js object.
Could we use the power of template literal tags to allow us to write more vanilla css?
for example we could convert this:
const styles =  cssInJs({
  myButton: {
    border: 'solid 1px #ccc',
    backgroundColor: 'lightgray',

    ':hover': {
      borderColor: '#ddd',

      ':active': {
        borderColor: '#eee'
      }
    },

    '[disabled]': {
      opacity: .5,
    }
  },

  '@media only screen and (max-width: 480px)': {
    myButton: {
      borderWidth: 0
    }
  }
})

to
const styles =  cssInJs`
  .myButton {
    border: solid 1px #ccc
    background-color: lightgray

    :hover {
      border-color: #ddd

      :active {
        border-color: #eee
      }
    }

    [disabled] {
      opacity: .5
    }
  }

  @media only screen and (max-width: 480px) {
    .myButton: {
      border-width: 0
    }
  }
`

the output would be the same
const styles = {
  myButton: 'example_js_styles_button'
}

👍

babel does some silly things with tagged template literals, going to simplify and try to just add support for string literal instead

added proof of concept with passing unit test:
https://github.com/Pyrolistical/babel-plugin-css-in-js/blob/95e9ef58095b90864f318762a58ca5d665d43d46/test/index.js#L99-L106

Hi @Pyrolistical, nice work! Could you please provide a proper PR that I can merge? Also please add a few lines to the README explaining the new feature. Thanks!


Cannot get code exec to work

I have tried to test out this project, and I have followed the guide through every step, but upon rebooting I still cannot see the log in /private/var/haxx. Are there any known issues I should be aware of which would affect this?

it’s recommend that you create an empty file at /private/var/haxx.log first

I tried it with the log created before a reboot, which helped. If I execute fileproviderctl_internal manually, there is output to the log file - but running /usr/bin/fileprovderctl does not produce any log and there is also no log output upon reboot.

Closing this issue because I upgraded to iOS 15.6


Improve docs for self-hosted agent

Maybe we can improve the docs by explicitly stating that ".complete" files need to be created. Whilet here is pointer to GitHub where this is explained, this requirement seems unusual and unexpected enough that it would be worth calling it out here.
see also: https://developercommunity.visualstudio.com/content/problem/804581/pipelines-how-to-configure-side-by-side-python-con.html?childToView=812906#comment-812906

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 9d52f9bd-a63c-d65f-ad92-7f245e4eb5c0
Version Independent ID: 51ce0fb6-3195-6593-bd62-57c1c0157989
Content: Use Python Version task - Azure Pipelines
Content Source: docs/pipelines/tasks/tool/use-python-version.md
Product: devops
Technology: devops-cicd
GitHub Login: @brcrista
Microsoft Alias: brcrista

Someone already did this work, so I'll resolve the ticket.


R0.8: Update proxy sha to 7792fbdd71cc2c070a3080c4a279b61378be9715

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: JimmyCYJ, qiwzhang
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: mandarjog
Assign the PR to them by writing /assign @mandarjog in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: JimmyCYJ, qiwzhang, rkpagadala
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: mandarjog
Assign the PR to them by writing /assign @mandarjog in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@qiwzhang: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
9494568a5af19e890c21ab9beb6dce2318c3df14
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
9494568a5af19e890c21ab9beb6dce2318c3df14
link
/test istio-unit-tests

prow/istio-presubmit.sh
9494568a5af19e890c21ab9beb6dce2318c3df14
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: JimmyCYJ, qiwzhang, rkpagadala
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: mandarjog
Assign the PR to them by writing /assign @mandarjog in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: JimmyCYJ, qiwzhang, rkpagadala
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: mandarjog
Assign the PR to them by writing /assign @mandarjog in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: JimmyCYJ, qiwzhang, rkpagadala
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: mandarjog
Assign the PR to them by writing /assign @mandarjog in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@qiwzhang: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test e2e-bookInfo

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test e2e-bookInfo

prow/e2e-bookInfoTests-v1alpha3.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test e2e-bookInfo-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test e2e-bookInfo

prow/e2e-bookInfoTests-v1alpha3.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test e2e-bookInfo-envoyv2-v1alpha3

prow/istio-pilot-e2e.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test e2e-bookInfo

prow/e2e-bookInfoTests-v1alpha3.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test e2e-bookInfo-envoyv2-v1alpha3

prow/istio-pilot-e2e.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test istio-pilot-e2e

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

New changes are detected. LGTM label has been removed.

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test istio-pilot-e2e

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-bookInfoTests-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test e2e-bookInfo-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
ca7970c1c8872ada72f8285a940e462369f6becf
link
/test istio-pilot-e2e

prow/e2e-bookInfoTests-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test e2e-bookInfo-envoyv2-v1alpha3

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test e2e-bookInfo-envoyv2-v1alpha3

/test istio-pilot-e2e-envoyv2-v1alpha3

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-bookInfoTests-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test e2e-bookInfo-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test e2e-bookInfo-envoyv2-v1alpha3

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test e2e-bookInfo-envoyv2-v1alpha3
/test istio-pilot-e2e-envoyv2-v1alpha3

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-bookInfoTests-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test e2e-bookInfo-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test e2e-bookInfo-envoyv2-v1alpha3

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test e2e-bookInfo-envoyv2-v1alpha3
/test istio-pilot-e2e-envoyv2-v1alpha3

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-bookInfoTests-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test e2e-bookInfo-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test e2e-bookInfo-envoyv2-v1alpha3

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Please grab the latest envoy update as well.

Sure,  waiting for proxy-postsubmit job to be done in order to generate proxy artifacts

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test e2e-bookInfo-envoyv2-v1alpha3

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
2352f42a63df608f0355148a984922b2197368e8
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/istio-pilot-e2e.sh
7b8834ecdf73c100f023d330e2a834256f7a92e0
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
7b8834ecdf73c100f023d330e2a834256f7a92e0
link
/test istio-pilot-e2e

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
7b8834ecdf73c100f023d330e2a834256f7a92e0
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
7b8834ecdf73c100f023d330e2a834256f7a92e0
link
/test istio-pilot-e2e

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
7b8834ecdf73c100f023d330e2a834256f7a92e0
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test istio-pilot-e2e-envoyv2-v1alpha3

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
7b8834ecdf73c100f023d330e2a834256f7a92e0
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/istio-pilot-e2e.sh
7b8834ecdf73c100f023d330e2a834256f7a92e0
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@qiwzhang: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
7b8834ecdf73c100f023d330e2a834256f7a92e0
link
/test istio-pilot-e2e

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
7b8834ecdf73c100f023d330e2a834256f7a92e0
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

The test failures look concerning, as it is pretty green in postsubmit.
https://k8s-testgrid.appspot.com/istio-postsubmits#circleci-e2e-pilot-noauth-v1alpha3-v2
Could you take a look?

replaced with https://github.com/istio/istio/pull/5807


Use support-v7 AlertDialog

+some removing of unused imports / indentation

:+1:

yes, default is 2x4 spaces.


default to the version specified in rust-toolchain.toml when rust-toolchain-version not provided

I use cargo's rust-toolchain.toml to pin my rust version to a specific stable release.
This enforces that developers and CI all run the same version of rust.
It also allows me to set CI to fail if any rustc or clippy warnings occur without violating the "not rocket science" rule.
I think this should be the standard way to set what rust version to use, with the rust-toolchain-version acting as override and automatically setup when the user hasnt created a rust-toolchain.toml
I think the following logic would work:

If a rust-toolchain.toml specifies a channel (the toolchain version) then:

cargo dist init should not set a rust-toolchain-version

If a rust-toolchain.toml specifies a channel (the toolchain version) and cargo dist's rust-toolchain-version is unset then:

cargo dist generate-ci should not include the name: Install cargo-dist section. The rust-toolchain.toml will cause rustup to automatically install the specified toolchain the first time cargo is invoked in a directory containing rust-toolchain.toml or one of its subdirectories)

i think this is an interesting idea, @rukai - thanks for submitting! given that the project has a goal to fit well into rust workflows, respecting rustup configs makes sense to me.
when you get a sec, i'm curious what your thoughts are @Gankra?

This is now at the top of my queue, rust-toolchain.toml is clearly just a better/official version of what i hacked up, and i should probably deprecate my config in favour of this.


bufio.Scanner: token too long

I use graphite-clickhouse buuild from current master,
config:
[common]
listen = ":9090"
max-cpu = 8
memory-return-interval = "0s"
max-metrics-in-find-answer = 0

[clickhouse]
url = "http://<IP_ADDRESS>:8123/"
extra-prefix = ""
data-table = "graphite.points_cluster"
data-timeout = "1m0s"
rollup-conf = "/etc/graphite-clickhouse/graphite_rollup.xml"
index-table = "graphite.index_cluster"
index-use-daily = true
index-timeout = "1m"
tagged-table = "graphite.tagged_cluster"

[prometheus]
external-url = "https://grafana.example.com/prometheus"
page-title = "Prometheus Time Series Collection and Processing Server"

[[data-table]]
table = "graphite.points_cluster"
reverse = true
rollup-conf = "/etc/graphite-clickhouse/graphite_rollup.xml"

[[logging]]
logger = ""
file = "stdout"
level = "info"
encoding = "mixed"
encoding-time = "iso8601"
encoding-duration = "seconds"

graphite_rollup:
       <pattern>
            <regexp>^.*scrape_interval=10s.*$</regexp>
            <function>avg</function>
            <retention>
                <age>0</age>
                <precision>10</precision>
            </retention>
            <retention>
                <age>259200</age>
                <precision>60</precision>
            </retention>
            <retention>
                <age>2592000</age>
                <precision>600</precision>
            </retention>
        </pattern>

Collect 10s metric with telegraf and send to carbon-clickhouse.
If request metric for period above 7d - get error:
Object
xhrStatus:"complete"
request:Object
method:"GET"
url:"api/datasources/proxy/18/api/v1/query_range?query=mem_used_percent%7Bhost%3D%22metric%22%7D&start=1568832000&end=1569523200&step=600&timeout=10s"
response:Object
status:"error"
errorType:"execution"
error:"bufio.Scanner: token too long"
message:"bufio.Scanner: token too long"

in log graphite-clickhouse:
[2019-09-26T21:42:56.285+0300] INFO [query] query {"query": "SELECT splitByChar('=', Tag1)[2] as value FROM graphite.tagged_cluster WHERE (Tag1 LIKE 'host=%') AND (Date >= '2019-09-19') GROUP BY value ORDER BY value", "request_id": "81fe3ec423d58c03e75dccd575f9c19a", "time": 0.00851583}
[2019-09-26T21:42:56.285+0300] INFO access {"request_id": "81fe3ec423d58c03e75dccd575f9c19a", "grafana": "Org:1; Dashboard:; Panel:", "time": 0.008859073, "method": "GET", "url": "/api/v1/label/host/values", "peer": "[::1]:6660", "status": 200}
[2019-09-26T21:42:56.351+0300] INFO [query] query {"query": "SELECT Path FROM graphite.tagged_cluster  WHERE ((Tag1='__name__=mem_used_percent') AND (arrayExists((x) -> x='host=metric', Tags))) AND (Date >='2019-09-18' AND Date <= '2019-09-26') GROUP BY Path", "request_id": "5d67a79bb41a4e85e2d6c5eea1038326", "time": 0.011381311}
[2019-09-26T21:42:56.394+0300] INFO access {"request_id": "5d67a79bb41a4e85e2d6c5eea1038326", "grafana": "Org:1; Dashboard:400; Panel:3", "time": 0.054455356, "method": "GET", "url": "/api/v1/query_range?query=mem_used_percent%7Bhost%3D%22metric%22%7D&start=1568832000&end=1569523200&step=600&timeout=10s", "peer": "[::1]:6660", "status": 422}

Request only one metric, if request data, for example, 1 day -10 days ago, the data is displayed

fixed with #69

Hi,
I have seen this behavior with the new values of bufio.Scanner also. Sometimes a bigger time range is needed . Is it possible to generate a log entry if this size is to small and make the value configurable ?


Installation issues of JDK on low version Burp

When using the version of Burp 2022, it cannot be installed in BAPP storez. Will we consider providing lower version plugins in the future?

In terms of the BApp Store, you will need to ask PortSwigger. As far as I know, they only support the latest version of each BApp, but if you contact them, they can assist you.
With respect to running JWT Editor on old versions of Burp, in general, it will work as long as you avoid method calls that have been implemented in more recent versions. However 2022 versions are probably still using the old IBurpExtender API so your best bet is to check out and build the original BlackBerry version. If you need help building it then let me know.

Hello, the reason for using the old version of Burp is that the new version of Burp is not as convenient in terms of UI and usage as the old version. Perhaps there are still many people using old versions of Burp for various reasons such as nostalgia. If you could compile the JWT plugin for the old version of Burp, I would greatly appreciate it

It's been a while since I worked with the BlackBerry version, but these steps should work for you:

Ensure that Java JDK 17 or newer is installed
Install Apache Maven
Clone the BlackBerry repository
From the root of project, run the command mvn package

This should put the file jwt-editor-1.1.0-jar-with-dependencies.jar into the target diretory which you can then load into Burp.


[bug] Login doesnt work in storefront: Message: Cannot return null for non-nullable field Account.primaryEmailAddress.

Type: breaking
Describe the bug
A clear and concise description of what the bug is.
I get the following error in the example-storefront after register/login.
web_1  | [GraphQL error]: Message: Cannot return null for non-nullable field Account.primaryEmailAddress., Location: [{"line":31,"column":5}], Path: ["viewer","primaryEmailAddress"]
It seems because of something about defaultEmail, I always keep seing the siggnin/register even if I'm already logged in?
I also cannot checkout properly etc
To Reproduce
Steps to reproduce the behavior:

Go to https://storefront.cruceritis.com
Click on register/login
Open devTools
See error

Expected behavior
I would expected to be redirected to a storefront with the user logged in and no signin/register buttons
Screenshots

Additional context
I'm deploying to DO with proxy-traefik.

Yep, can close I guess


Defining offsets for the file given to identify the zstd file

I have a use case where I will be putting a zstd SQLite file in a Zip (with other files) where the zstd is in "Store" mode so it is not double compressed. My goal is to read the zstd directly from the Zip so it does not need to extract it.
It would be nice if there was an OpenWithinZip(ZipPath, ZstdFileWithinZip, flags sqlite3vfs.OpenFlag) function which would take a file-path to the actual SQLite file, check if it is in the zip as a "Store" compression and then store the offsets for the start and end of the file in the zip for use in the operations. If it is not in "Store" mode for that file (even if the other files are not in store compression) then it will error.
It doesn't seem like it will be too hard to implement, do you have any concerns or suggestions with this approach? I don't have time to do this anytime soon as I have other prior commitments. I am just interested in the feasibility, it seems straight forward enough.

Hey! Thanks for the request.
I took a look. The simplest solution would be to extract the file from the zip file and save it to the local file system.
With the zstd seekable format, a io.ReadSeeker is required to read the file. That is provided be os.Open. I don't see a way to do that with a zip file. It only provides an io.Reader.
Even with a fs.Fs, the File returned does not have io.ReadSeeker. So making the zip file look like FS interface wouldn't help there either.
I'm not sure there is a "straight forward" way of doing this.
I'm going to close the issue for now. If you happen to do research and find a way of doing it, please open a new issue, so we can keep track of individual discussions.


The example is not working now.

Hi,
The callback is not called even for the examples. It worked yesterday. I guess Google changes it's API.
Please check.
Thanks

The problem is cause by Google. When getting JSON from Google. the page is holding the connection without respond any data. I hope it's caused by server down.

I can confirm this.

Filed a bug to Google
https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3939

+1 hopefully this can be fixed

fixed.
On Wed, Jul 29, 2015, 5:12 PM Jay Zehngebot<EMAIL_ADDRESS>wrote:

via the google bug report filed by Mohuzi
"Thanks everyone for raising the issue. We have found the source of the
problem and hope to roll out a fix quickly.
Summary: All GData Spreadsheets API requests failing with 500 response
(was: gdata spreadsheets API is hanging)
Status: Triaged
Owner<EMAIL_ADDRESS>Labels: API-Spreadsheets log-22824458 "
—
Reply to this email directly or view it on GitHub
https://github.com/jsoma/tabletop/issues/99#issuecomment-126096918.


Incoherent releases

The latest installer downloadable from the website shows the following version:
Version 6.2.5-20240101050825+3bdf76f84a (6.2.5-20240101050825+3bdf76f84a)

However, the releases on Github are at 6.2.4 which is really confusing.
Also, why are no signed checksums of the installers provided? That would improve confidence given the amount of private information that a user might manage via Keybase.

+1 for this - Its really hard to tell:
"what is the current release version of Keybase" on a website, I would to see the released version #  here:
https://keybase.io/download
or even the "current release version" listed on GitHub in the right sidebar
For the record, I dont mind seeing different release version #'s depending on the platform, thats no problem
For the keybase client, on WINDOWS, I have to open the finder and find the binary or use the CMD line to see what version of keybase client is current installed
What about putting in "About Keybase" or under "Help" ?
Instead you have to open a command line window and type:
 keybase version              # print the version number

or right click on the app here:
C:\Users\mbw\AppData\Local\Keybase\Gui
These kinds of things are important and add to the usability/trustability of an app - I hope your team can
incorporate these as you go through growing pains of this app.
Developers: Thank you for your work on Keybase - its really a great app & great technology - we appreciate you !


Created two copies of the code and renamed one copy as legacy.

Verified that @myothiha09 has signed the CLA. Thanks for the pull request!


Update CI infrastructure

Welcome to Codecov :tada:
Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


[unit-test] add disk interal test

What this PR does / why we need it:
add disk interal test
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (a1ef97d) 36.58% compared to head (75a5dfc) 35.97%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1295      +/-   ##
==========================================
- Coverage   36.58%   35.97%   -0.62%
==========================================
  Files          28       29       +1
  Lines        2222     2307      +85
==========================================
+ Hits          813      830      +17
- Misses       1306     1372      +66
- Partials      103      105       +2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Observation resource "applies" attribute missing

DSTU2 Version 1.1 of Observation resource had a "applies" attribute.  This attribute is not available in version 1.2-SNAPSHOT, but is listed in the FHIR spec. Can you please add it?

Hi Travis,
Observation.applies[x] was renamed to Observation.effective[x] in May in
the FHIR sources themselves. See the relevant tracker here:
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=7636&start=0
and the definition here: http://hl7-fhir.github.io/observation.html
In the 1.2 cycle we will be updating the resource definitions to match the
latest DSTU2 definitions from HL7, which are basically finalized at this
point (last call for changes has already gone out, QA is starting soon).
That said, we haven't applied this change to the SNAPSHOT that's deployed
to Maven yet. Are you building from source or something? (I confirmed by
downloading the latest 1.2 snapshot from here
https://oss.sonatype.org/content/repositories/snapshots/ca/uhn/hapi/fhir/hapi-fhir-structures-dstu2/1.2-SNAPSHOT/
and it still had "applies".
FYI to anyone that wants to get a head start on the changes, there is a
branch in Git called "dstu2_final" which has the latest definitions as well
as some other enhancements that have been added to FHIR DSTU2 since the
April ballot. This branch will be merged into master at some point in the
next ~4 weeks, at which point most of the public reference servers will
also be updated.
Cheers,
James
On Fri, Jul 31, 2015 at 10:43 AM, travistcummings<EMAIL_ADDRESS>wrote:

DSTU2 Version 1.1 of Observation resource had a "applies" attribute. This
attribute is not available in version 1.2-SNAPSHOT, but is listed in the
FHIR spec. Can you please add it?
—
Reply to this email directly or view it on GitHub
https://github.com/jamesagnew/hapi-fhir/issues/202.

Thank you James, I must of had some stale version of the JAR file locally.  I've refreshed and see the attribute as you say.
Travis


Upgrade to ESLint 7

Currently, React hooks and a couple of other plugins have a peer dependency on ESLint 6. Everything works except vsce errors out building the extension package.
We don't even need these plugins -- they're just used for testing.

The real problem is<EMAIL_ADDRESS>as it has a peer dependency on ESLint 5 or 6. It is a great plugin for tests and we don't want to ditch it. We'll wait until it is updated.

Fixed in 1.3.0


Release a gem version with PR #84 included.

I happened to have the same issue that #99 had with Knock, where the first request worked, but not subsequent requests, until code was reloaded.
This PR fixed the issue, but there is no release yet including this fix.
Temporarily using the ~>1.4.2 pessimistic version constraint works for me, but I'd much rather prefer using ~>1.5.1 or something like that that would include the fix (assuming the fix does work).

@samueldr Installing from master: gem 'knock', github: 'nsarno/knock' fixed the reload issue for me - if you don't want to fall back to 1.4.2

@samueldr I was hoping to do this sooner but haven't taken the time to get to it yet. Thank you guys for being patient :)


Update Jaeger UI and service port according to docs for jaeger example

Default ports for jaeger and envoy service are incorrect in docker-compose file. In docs jager UI is set at 16686 and service's port is set to 8000
This code change updates ports according to docs.
Jaeger UI showing traces,

@adilhafeez you will need to update the listener port in envoy.yaml also

@adilhafeez you will need to update the listener port in envoy.yaml also

@phlax just pushed another change. This change updates envoy with 10000 port and also updates rst file with console output.

nice, thanks @adilhafeez
you will need to fix DCO now tho

@phlax do you think it's a bad idea to link the screenshot in rst file?

screenshot is fine but it will need to be added as an artefact - see the opentelemetry example for how to do that


Cannot start a runtime from within a runtime.

Describe the bug
i got this error when running the pingora app
thread 'main' panicked at /Users/ibk/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pingora-core-0.1.0/src/server/mod.rs:302:57:
Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Pingora info
Please include the following information about your environment:
Pingora version: 0.1.0
Rust version: 1.77
Operating system version: Mac OS Sonoma 14.4
Steps to reproduce
In my main, i need to initialize a (non pingora) client which need await.
So, the main fn need to become async and become like this
#[tokio::main]
async fn main() {

Looks like it is the one that create the problem.
Expected results
can run normally
Observed results
got above error
Additional context
My program need to talk to some backend service, hence the need to initialize the client.

What are you trying to accomplish? We have a BackgroundService you can use to run background services and expose them to pingora.
https://bitbucket.cfdata.org/projects/PINGORA/repos/pingora/browse/pingora/examples/server.rs#34,150,158

tokio::main is just syntax sugar for
fn main() {
    let mut rt = tokio::runtime::Runtime::new().unwrap();
    rt.block_on(async {
        // your code
    })
}

So you can do that instead if you need to run async code before starting the pingora server.

What are you trying to accomplish?

@andrewhavck i need to initialize a redis client during startup, so it can be used on each request

So you can do that instead if you need to run async code before starting the pingora server.

Thanks @eaufavor , it answers my questions 👍

i need to initialize a redis client during startup, so it can be used on each request

FYI as mentioned here if you start pingora with the daemonize flag it will fork() on run_forever() and Tokio runtimes created before then will likely not work.

FYI as mentioned here if you start pingora with the daemonize flag it will fork() on run_forever() and Tokio runtimes created before then will https://github.com/tokio-rs/tokio/issues/4301.

I see, honestly i haven't tried the solution yet when i closed this issue, because i move to something else right now.
So, the solution is using Background Service @andrewhavck ?

You can try to use like this:
#[tokio::main]
async fn run1() {
    // build our application with a route
    let app = Router::new()
        // `GET /` goes to `root`
        .route("/", get(root));
    let listener = tokio::net::TcpListener::bind("<IP_ADDRESS>:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

fn run() -> Result<(), Box<dyn Error>> {
    // init my server of pingora

    std::thread::spawn(|| {
        run1();
    });
    my_server.run_forever();
    Ok(())
}

fn main() {
    if let Err(err) = run() {
        error!("{}", err.to_string());
    }
}

I also find a way to run all service of pingora and I made a pull request, https://github.com/cloudflare/pingora/pull/175

@andrewhavck I dont know if it is still valid for you, but I could get it to work using Tokios implementation of OnceCell and its get_or_init method in the upstream_peer method. I am using the redis-rs redis::aio::ConnectionManager.
static REDIS_CLIENT: OnceCell<ConnectionManager> = OnceCell::const_new();

I think this is still a pertinent question that the GitHub actions bot was a bit too eager to close.
I think the problem is generally this:

We have a pingora runtime
we define an async process / service that uses an async tokio runtime
we want pingora to run that process for us
It is not clear how to have pingora run that service if it is not possible to create a runtime from inside of a runtime.

This last point is the most pressing one. You can implement Service or BackgroundService but that requires implementing the start() method. In order to do this you need to create a tokio runtime. But, as I understand it, that cannot be done because pingora is a tokio runtime so that leads to a runtime being ran from a runtime.


chore: release 1.0.0

:robot: I have created a release *beep* *boop*
1.0.0 (2019-05-20)
⚠ BREAKING CHANGES

upgrade engines field to >=8.10.0 (#195)

Bug Fixes

deps: update dependency google-gax to ^0.26.0 (#193) (16f112a)
DEADLINE_EXCEEDED is no longer retried (9d38130)
DEADLINE_EXCEEDED retry code is idempotent (#204) (e048b26)
include 'x-goog-request-params' header in requests (#186) (f13ebcd)
deps: update dependency google-gax to v1 (#203) (b005f75)
docs: fix a broken link (#177) (d7b2fce)

Build System

upgrade engines field to >=8.10.0 (#195) (00f0f63)

Release is at https://github.com/googleapis/nodejs-dataproc/releases/tag/v1.0.0

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


Client::completed_orders freezes since v0.5.0

Repro: spawn an ibgateway on port 4001 and add to client.rs:
mod tests {
    use super::*;

  #[test]
  fn try_completed_orders() {
    let client = Client::connect("<IP_ADDRESS>:4001", 0).unwrap();
    println!("connected");
    let sub = client.completed_orders(false).unwrap();
    println!("Got sub");
    for or in sub.into_iter() {
      println!("or: {:?}", or);
    }
  }
}

Run: cargo test client::tests::try_completed_orders -- --nocapture
It prints Got sub then freezes. Subscription::next is never called. decode_completed_order is never called.
I tested on release v0.5.0, where it works, and v1.0.0, where it doesn't.
After some bisection:
d3266a5 @ simplify retry (#131) -> freeze
3921d68 @ Implements request positions multi (#121) -> panic
d48c259 @ Refactor response iterators (#120) -> panic
1ec6d61 @ Adds request PNL APIs (#119) -> pass

So it passed, until #119, then panic in transport.rs is introduced in #120 and at some point before #131 it turns into a freeze.
With IBAPI_RECORDING_DIR on, the preambles are slightly different but the req is the same, but they get different responses.
Request: 99|0|  aka ReqCompletedOrders(api_only=0)
v0.5.0:  102|| aka CompledOrdersEnd
v1.0.5: Response: 9|1|938|| aka NextValidOrder

This is actually working as designed. Review the behavior of subscriptions here.
Previously iterators automatically timed out after 10 seconds while waiting for a response. This works ok when placing and checking the status of order with immediate fills such as markets orders. If placing and checking the status of a limit order that took a while to fill the application had no way to specify how long it wanted to wait. The subscription interface addresses this issue.
By default the subscription will create an iterator that blocks forever. To replicate the previous behavior, your code would look like this.
mod tests {
    use super::*;

  #[test]
  fn try_completed_orders() {
    let client = Client::connect("<IP_ADDRESS>:4001", 0).unwrap();
    println!("connected");
    let sub = client.completed_orders(false).unwrap();
    println!("Got sub");
    for or in sub.timeout_iter(Duration::from_secs(10)) {
      println!("or: {:?}", or);
    }
  }
}

Also in the previous scenario you can also break out of the loop after processing the messages you were expecting.

Thanks for reporting this. Initially misunderstood the issue.
Have a PR to fix this https://github.com/wboayue/rust-ibapi/pull/195/files. Will create a new release after more testing.

Thank you for the tips and quick resolution!


Cilium and Istio/ambient?

Migrate from Calico to Cilium and use Istio/ambient when that's released

Looks like Istio Ambient has released GA 06-18-2023:
https://tetrate.io/istio-1-18-released-now-with-ambient-mode-available/

Just curious if this is an active effort. We're trying to integrate Istio Ambient with Cilium and it isn't smooth so far.


Missing Translation

Coverage remained the same at 100.0% when pulling 0fec4805da07ca4722f18ac4251d8f74b971addd on 582_MissingTranslation into 37853b15f41b3ee165b90a547c755dcfab104a90 on dev.


There is no '...' next to the action 'Download All' for ADLS Gen2/regular blob containers on the languages Italian/Polish

Storage Explorer Version: 1.27.0-dev
Build Number: 20221027.6
Branch: main
Platform/OS: Windows 10/Linux Ubuntu 22.04/MacOS Monterey 12.6 (Apple M1 Pro)
Reproduce Languages: Italian/Polish
Architecture: ia32/x64
How Found: From running test cases
Regression From: Not a regression
Steps to Reproduce

Launch Storage Explorer -> Open 'Settings' -> 'Application -> Regional Settings'.
Select 'Italiano' -> Restart Storage Explorer.
Expand one storage account -> Blob Containers.
Open one blob container which contains items.
Click the download arrow.
Check whether there is a '...' next to the action 'Download All'.

Expected Experience
There is a '...' next to the action 'Download All'.
Actual Experience
There is no '...' next to the action 'Download All'.

Additional Context
This issue also reproduces for the actions on the context menu.

Opened a loc ticket for translation team to investigate.

As suggested by the loc team, added comments to provide guidance on translation.

@JasonYeMSFT This is still not resolved. Can you please provide a link to loc ticket or create a new one to get them on this?

I created a new work item: https://ceapex.visualstudio.com/CEINTL/_workitems/edit/969146


Short solution needed: "How to limit query string " (nginx)

Please help us write most modern and shortest code solution for this issue:
**How to limit query string ** (technology: nginx)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments to make solution explained.
Link to this issue in comments of pull request.

How to limit allowed query string size


✨ render children of an epub content item

Some epub content items have more content items inside! This PR exposes them to the reader.
First time working with Rust 😅 - criticism welcome!
Before

After

I'll be able to take a look tomorrow after work to review, but based on your screenshot I actually think this would resolve https://github.com/stumpapp/stump/issues/334! Excited to give it a proper look! Thank you!


Remove version: Jackett.Jackett version 0.20.3583

404 - release deleted
Microsoft Reviewers: Open in CodeFlow

URL: https://github.com/Jackett/Jackett/releases/download/v0.20.3583/Jackett.Installer.Windows.exe
Response Error: The remote server returned an error: (404) Not Found.
(Automated message - build 918)


Add Contributing.md or notes in the readme about contributing

As I've written a couple PRs and issues now I've been wondering what the main contributors' preferences are with regard to contributions, since there's no specified place to ask.
Some questions:

Should I submit PRs first?
Should I open an issue for discussions related to certain things (like API or architecture changes), before spending time on a PR?
Do the main contributors have a certain set of features/upcoming changes in mind? Like a detailed roadmap, but it could be short-term
What usage scenarios should be supported?
What reference documentation is the crate based on, if any?

We could mention something about the Github workflow (ie run cargo fmt and cargo test before submitting a PR) even if it seems like common sense. Users of Firebird are likely to be users of other programming languages (Java, C#, Pascal variants, Python, C++) so it could be good to give a little bit of guidance for people who are still getting familiar with Rust ecosystem specifics.
I also notice many contributors are from Brasil. I assume their native language is Portuguese. If it's preferred not to discuss anything about that, I understand. But if some contributors want to say 'find me on #rust-br!' or if there's specific kinds of contributions related to language that they would find helpful, I think that's also useful to say.

As I've written a couple PRs and issues now I've been wondering what the main contributors' preferences are with regard to contributions, since there's no specified place to ask.

Fell free to ask in here, in the github issues. We also have a [telegran group], now there are only Brazilian members, so we use Portugese, but we can change to English without problems.

Should I submit PRs first?

If you have fixed some bugs, or made small improvements, I think you can open a PR directly.

Should I open an issue for discussions related to certain things (like API or architecture changes), before spending time on a PR?

Yes. API changes or large changes, need to be discussed first, because we need understand what is the propose with some examples and more.

Do the main contributors have a certain set of features/upcoming changes in mind? Like a detailed roadmap, but it could be short-term

No. We don't have a roadmap yet, because the users are only using in tests cases or exploring the Rust + Firebird. If you have a feature list, feel free to share here.
We are working for keep the crate more simple as possible. So, advanced API's are welcome, but with a separated crates.

What usage scenarios should be supported?

Users migrating old applications. I don't see anyone write a new e-commerce site using Rust + Firebird, but fixing some performance issues in their ERP yes.
Feel free to discord.

What reference documentation is the crate based on, if any?

I think not, I started the project think in the rusqlite crate and his doc, but today we are with our own style of API and doc.

We could mention something about the Github workflow (ie run cargo fmt and cargo test before submitting a PR) even if it seems like common sense. Users of Firebird are likely to be users of other programming languages (Java, C#, Pascal variants, Python, C++) so it could be good to give a little bit of guidance for people who are still getting familiar with Rust ecosystem specifics.

I agree with you.

I also notice many contributors are from Brasil. I assume their native language is Portuguese. If it's preferred not to discuss anything about that, I understand. But if some contributors want to say 'find me on #rust-br!' or if there's specific kinds of contributions related to language that they would find helpful, I think that's also useful to say.

Yes, today all 'official' contributors are from Brasil. I want translate all basic instruction for our language, but Rust don't have a good traction here yet.
Our 'sub-official' telegran group is the only Portuguese(language) place related to the lib today.

So, you have interest in make a contributing.md file? You can handle that?

Yes I can do that.

I want translate all basic instruction for our language, but Rust don't have a good traction here yet.
Could you elaborate on what issues you face? Are you referring mainly to localization in rustdoc (and maybe testing utils)?
Do you want to open a TODO issue? Maybe it's well known in the rust-br community already. But perhaps someone will come along, see the issue and say "hey I actually wrote a tool for this exact problem".

When I said 'reference documentation' I mean things like
Protocol Messages
Implementation in python
Firebird source code explorer
Firebird wire protocol documentation
(all from #22)
@jairinhohw maybe you have some other comments about articles/source code you found most helpful? I think it's impressive that you  implemented the wire protocol in rust so quickly. I imagine by now you have a very good understanding of the BLR and wire protocol. Is this something you'd be willing to try to explain or answer questions about a little bit to help potential contributors?
If you know about where best to look about fbclient implementation details that could also be helpful.
I will make a separate issue for documentation relating to specific aspects of internals

When I said 'reference documentation' I mean things like
Protocol Messages
Implementation in python
Firebird source code explorer
Firebird wire protocol documentation
(all from #22)
@jairinhohw maybe you have some other comments about articles/source code you found most helpful? I think it's impressive that you implemented the wire protocol in rust so quickly. I imagine by now you have a very good understanding of the BLR and wire protocol. Is this something you'd be willing to try to explain or answer questions about a little bit to help potential contributors?
If you know about where best to look about fbclient implementation details that could also be helpful.
I will make a separate issue for documentation relating to specific aspects of internals

The resources I've linked in the #22 are about all i could find (did not link the jaybird source as i found the implementation in python easier to read), so quite a bit of what i implemented is things I'm not really sure of how it works because of the lack of documentation, but I've commented the code to document my understanding of the things.
I would be glad to answer any questions i can about the implementation and protocol.
I plan to rewrite it to make it easier to read and document a bit more in time, as it seems to be working better than i expected.

Yes I can do that.

I want translate all basic instruction for our language, but Rust don't have a good traction here yet.

@fernandobatels Could you elaborate on what issues you are facing?

I'm not currently working on any issues. I'm busy with personal issues.  Maybe next week I'll be able to work on the project again.

Are you referring mainly to localization in rustdoc (and maybe testing utils)?

Yes, the official docs and the README.md.

Do you want to open a TODO issue? Maybe it's well known in the rust-br community already. But perhaps someone will come along, see the issue and say "hey I actually wrote a tool for this exact problem".

When I start the localization work I will open a new issue.
I already share the lib in the Brazilian rust group a while ago, and in some Firebird groups. The people are coming in his own time.

Fell free to ask in here, in the github issues. We also have a [telegran group], now there are only Brazilian members, so we use Portugese, but we can change to English without problems.

The link to our group: https://web.telegram.org/#/im?p=@rsfbclient


improvement: clear-stale-neigh-entries-for-overlay

Pull Request Description
Describe what this PR does / why we need it
Consume there is a node A (it's the same thing for pod on this node) has accessed pod B, there will be a REACHABLE neigh entry for pod B on node A. If the pod B is deleted, and after a period of time, neigh entry for pod B on node A will become STALE, even pod B has been recreate on another different node, this neigh entry will not be updated, because there is no gratuitous arp/ndp for overlay network.
This is because kernel will never clear a STALE neigh entry if the number of all neigh entries on this node is under the limit of gc_thresh parameter, which will cause a problem of seconds packet loss while this node want to rebuild a connection to the new pod B.
Does this pull request fix one issue?

NONE
Describe how you did it
Clear STALE neigh entries for vxlan interface once the rama-daemon pod is running, and clear specific STALE neigh if the ip is not found by neigh proxy.
Describe how to verify it

recreate rama-daemon pod to clear STALE neigh entries.
delete an exist pod and check if the STALE neigh cache will be cleaned for all nodes.

Special notes for reviews

Codecov Report

Merging #40 (5a10a6d) into main (61d7913) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #40   +/-   ##
=======================================
  Coverage   18.64%   18.64%
=======================================
  Files          28       28
  Lines        2242     2242
=======================================
  Hits          418      418
  Misses       1767     1767
  Partials       57       57

Flag
Coverage Δ

unittests
18.64% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 61d7913...5a10a6d. Read the comment docs.


enable artifacts on travis

Enable to have build artifact from travis pushed somewhere. Amazon S3 looks like the standard place for that according to travis documentation

Current build error:
Uploading Artifacts (BETA)
artifacts.setup
artifacts version v0.7.8-26-gd62580b revision=d62580ba6bfffc7245d8ac6a1a384ef60b9302e7
$ export ARTIFACTS_PATHS="$(git ls-files -o | tr \"\\n\" \":\")"
$ artifacts upload
/home/travis/build.sh: line 59: /home/travis/bin/artifacts: Argument list too long
Done uploading artifacts

not relevant anymore.