We know what’s going on with your Google rankings lautaportti.wordpress.com

[savannah]

Hello lautaportti.wordpress.com

My name is Savannah Hill, and I was just browsing your
lautaportti.wordpress.com
and I came up with a great design and a plan to develop your
lautaportti.wordpress.com using the latest technologies to generate an
additional revenue and beat your competitors. By the way, We've a pretty
good experience in developing apps too.

Let me know if you are *interested* and I will send you our company details
or create a proposal so you can see exactly where you rank compared to your
competitors.



*Want to check out my portfolio, send a reply to talk more.*

Best Regards,

*Savannah Hill   |   Digital Marketing Specialist *
---
NOTE - *We could lower that cost and not compromise on quality! *

Re: [PATCH] supress cirrus-ci OS version check

[Илья Шипицин]

it's pretty much like to gcc.
I've no idea why does FreeBSD decided to check its version (and nobody
knows).

I'll update commit message

ср, 26 февр. 2020 г. в 05:37, Tim Düsterhus :

> Ilya,
>
> Am 25.02.20 um 21:13 schrieb Илья Шипицин:
> > it turned out that FreeBSD image is slightly different from packages.
> > since we cannot change image, let us just suppress that warning.
>
> I'd like to point out this paragraph from the CONTRIBUTING document:
>
> >As a rule of thumb, your patch MUST NEVER be made only of a subject
> line,
> >it *must* contain a description. Even one or two lines, or indicating
> >whether a backport is desired or not. It turns out that single-line
> commits
> >are so rare in the Git world that they require special manual (hence
> >painful) handling when they are backported, and at least for this
> reason
> >it's important to keep this in mind.
>
> When reading your patch it was unclear to me which kind of version check
> needs to be ignored (and why). At the very least I would have expected a
> copy the actual error message from CI (that will be fixed after applying
> the patch) in the commit message. I'll copy it here for posterity.
>
> > Updating FreeBSD repository catalogue...
> > Fetching meta.conf: . done
> > Fetching packagesite.txz: .. done
> > Processing entries:
> > Newer FreeBSD version for package p5-Bio-GFF3:
> > To ignore this error set IGNORE_OSVERSION=yes
> > - package: 1300081
> > - running kernel: 1300078
> > Ignore the mismatch and continue? [Y/n]: pkg: repository FreeBSD
> contains packages for wrong OS version: FreeBSD:13:amd64
> > Processing entries... done
> > Unable to update repository FreeBSD
> > Error updating repositories!
>
> I'm not a FreeBSD guy, but my understanding after a short session with
> the search engine of my choice indicated that apparently the Cirrus CI
> VM is running an outdated kernel or possibly an outdated FreeBSD jail.
> I'm not sure whether that is correct or not. In any case an explanation
> why suddenly this error message popped up and why it's safe to ignore
> that specific error is safe would have been helpful in the commit
> message as well.
>
> Best regards
> Tim Düsterhus
>

Re: stable-bot: Bugfixes waiting for a release 2.1 (7), 2.0 (5)

[Willy Tarreau]

On Tue, Feb 25, 2020 at 11:41:38PM -0500, Daniel Corbett wrote:
> Good news is the bot is much more dynamic now.  I no longer need to manually
> add new versions and older versions should have their release dates
> automatically adjusted to account for age.  Also, we will see non-LTS
> versions (1.9) disappear from the emails after 1 year of release.  Versions
> older than 3 years will not be in the report either.

Sound good!

Willy

Re: stable-bot: Bugfixes waiting for a release 2.1 (7), 2.0 (5)

[Daniel Corbett]

Hey Tim & Willy,

On 2/25/20 10:45 PM, Willy Tarreau wrote:

On Wed, Feb 26, 2020 at 01:23:24AM +0100, Tim Düsterhus wrote:

Daniel,

I already told you in IRC, but as I now have an email to reply to: This
new email format is much better than the old one.

FWIW I agree, it's more synthetic and still seems to contain all the
relevant information.

Thanks for these changes!
Willy


Thanks for the feedback!  Tim, I've immediately implemented your 
suggestion around the dashes.  I'll look into the alignment recommendations.


Glad I could help improve the output (required quite a bit of refactoring!)

Good news is the bot is much more dynamic now.  I no longer need to 
manually add new versions and older versions should have their release 
dates automatically adjusted to account for age.  Also, we will see 
non-LTS versions (1.9) disappear from the emails after 1 year of 
release.  Versions older than 3 years will not be in the report either.


Thanks again for all of the feedback and suggestions.

Thanks,
-- Daniel

Re: stable-bot: Bugfixes waiting for a release 2.1 (7), 2.0 (5)

[Willy Tarreau]

On Wed, Feb 26, 2020 at 01:23:24AM +0100, Tim Düsterhus wrote:
> Daniel,
> 
> I already told you in IRC, but as I now have an email to reply to: This
> new email format is much better than the old one.

FWIW I agree, it's more synthetic and still seems to contain all the
relevant information.

Thanks for these changes!
Willy

Re: [PATCH] supress cirrus-ci OS version check

[Tim Düsterhus]

Ilya,

Am 25.02.20 um 21:13 schrieb Илья Шипицин:
> it turned out that FreeBSD image is slightly different from packages.
> since we cannot change image, let us just suppress that warning.

I'd like to point out this paragraph from the CONTRIBUTING document:

>As a rule of thumb, your patch MUST NEVER be made only of a subject line,
>it *must* contain a description. Even one or two lines, or indicating
>whether a backport is desired or not. It turns out that single-line commits
>are so rare in the Git world that they require special manual (hence
>painful) handling when they are backported, and at least for this reason
>it's important to keep this in mind.

When reading your patch it was unclear to me which kind of version check
needs to be ignored (and why). At the very least I would have expected a
copy the actual error message from CI (that will be fixed after applying
the patch) in the commit message. I'll copy it here for posterity.

> Updating FreeBSD repository catalogue...
> Fetching meta.conf: . done
> Fetching packagesite.txz: .. done
> Processing entries: 
> Newer FreeBSD version for package p5-Bio-GFF3:
> To ignore this error set IGNORE_OSVERSION=yes
> - package: 1300081
> - running kernel: 1300078
> Ignore the mismatch and continue? [Y/n]: pkg: repository FreeBSD contains 
> packages for wrong OS version: FreeBSD:13:amd64
> Processing entries... done
> Unable to update repository FreeBSD
> Error updating repositories!

I'm not a FreeBSD guy, but my understanding after a short session with
the search engine of my choice indicated that apparently the Cirrus CI
VM is running an outdated kernel or possibly an outdated FreeBSD jail.
I'm not sure whether that is correct or not. In any case an explanation
why suddenly this error message popped up and why it's safe to ignore
that specific error is safe would have been helpful in the commit
message as well.

Best regards
Tim Düsterhus

Re: stable-bot: Bugfixes waiting for a release 2.1 (7), 2.0 (5)

[Tim Düsterhus]

Daniel,

I already told you in IRC, but as I now have an email to reply to: This
new email format is much better than the old one.

I have a few more small suggestions inline below:

Am 26.02.20 um 01:00 schrieb stable-...@haproxy.com:
> Hi,
> 
> This is a friendly bot that watches fixes pending for the next haproxy-stable 
> release!  One such e-mail is sent periodically once patches are waiting in 
> the last maintenance branch, and an ideal release date is computed based on 
> the severity of these fixes and their merge date.  Responses to this mail 
> must be sent to the mailing list.
> 
> 
> Last release 2.1.3 was issued on 2020-02-12.  There are currently 7 patches 
> in the queue cut down this way:
> - 1 MAJOR, first one merged on 2020-02-21
> - 1 MEDIUM, first one merged on 2020-02-21
> - 5 MINOR, first one merged on 2020-02-21

Consider aligning the "first one ..." part to avoid that jagged
formatting, due to MEDIUM (and CRITICAL, though I assume we'll never see
that) being longer the the other severities. Make sure to test two-digit
patch numbers.

> Thus the computed ideal release date for 2.1.4 would be 2020-03-06, which is 
> in two weeks or less.
> 
> Last release 2.0.13 was issued on 2020-02-13.  There are currently 5 patches 
> in the queue cut down this way:
> - 1 MAJOR, first one merged on 2020-02-21
> - 1 MEDIUM, first one merged on 2020-02-21
> - 3 MINOR, first one merged on 2020-02-21
> 
> Thus the computed ideal release date for 2.0.14 would be 2020-03-06, which is 
> in two weeks or less.
> 
> The current list of patches in the queue is:
>  - 2.0, 2.1  - MAJOR   : http-ana: Always abort the request 
> when a tarpit is triggered
>  - 2.0, 2.1  - MEDIUM  : muxes: Use the right argument when 
> calling the destroy method.
>  - 2.0, 2.1  - MINOR   : filters: Count HTTP headers as 
> filtered data but don't forward them
>  - 2.0, 2.1  - MINOR   : namespace: avoid closing fd when 
> socket failed in my_socketat
>  - 2.0, 2.1  - MINOR   : http-ana: Matching on monitor-uri 
> should be case-sensitive
>  - 2.1   - MINOR   : http-htx: Don't return error if 
> authority is updated without changes
>  - 2.1   - MINOR   : mux-fcgi: Forbid special characters 
> when matching PATH_INFO param
> 
> ---

Consider replacing "---" with "-- " (including the space after the
hyphens). It will then be treated as an email signature (RFC 3676#4.3).
My email client automatically tones down the color of signatures and
strips them when replying. And de facto this last paragraph is a signature.

> The haproxy stable-bot is freely provided by HAProxy Technologies to help 
> improve the quality of each HAProxy release.  If you have any issue with 
> these emails or if you want to suggest some improvements, please post them on 
> the list so that the solutions suiting the most users can be found.
> 

Best regards
Tim Düsterhus

stable-bot: Bugfixes waiting for a release 2.1 (7), 2.0 (5)

[stable-bot]

Hi,

This is a friendly bot that watches fixes pending for the next haproxy-stable 
release!  One such e-mail is sent periodically once patches are waiting in the 
last maintenance branch, and an ideal release date is computed based on the 
severity of these fixes and their merge date.  Responses to this mail must be 
sent to the mailing list.


Last release 2.1.3 was issued on 2020-02-12.  There are currently 7 patches in 
the queue cut down this way:
- 1 MAJOR, first one merged on 2020-02-21
- 1 MEDIUM, first one merged on 2020-02-21
- 5 MINOR, first one merged on 2020-02-21

Thus the computed ideal release date for 2.1.4 would be 2020-03-06, which is in 
two weeks or less.

Last release 2.0.13 was issued on 2020-02-13.  There are currently 5 patches in 
the queue cut down this way:
- 1 MAJOR, first one merged on 2020-02-21
- 1 MEDIUM, first one merged on 2020-02-21
- 3 MINOR, first one merged on 2020-02-21

Thus the computed ideal release date for 2.0.14 would be 2020-03-06, which is 
in two weeks or less.

The current list of patches in the queue is:
 - 2.0, 2.1  - MAJOR   : http-ana: Always abort the request 
when a tarpit is triggered
 - 2.0, 2.1  - MEDIUM  : muxes: Use the right argument when 
calling the destroy method.
 - 2.0, 2.1  - MINOR   : filters: Count HTTP headers as 
filtered data but don't forward them
 - 2.0, 2.1  - MINOR   : namespace: avoid closing fd when 
socket failed in my_socketat
 - 2.0, 2.1  - MINOR   : http-ana: Matching on monitor-uri 
should be case-sensitive
 - 2.1   - MINOR   : http-htx: Don't return error if 
authority is updated without changes
 - 2.1   - MINOR   : mux-fcgi: Forbid special characters 
when matching PATH_INFO param

---
The haproxy stable-bot is freely provided by HAProxy Technologies to help 
improve the quality of each HAProxy release.  If you have any issue with these 
emails or if you want to suggest some improvements, please post them on the 
list so that the solutions suiting the most users can be found.

We'd Like to Offer You a Free Infographic!

[Paul Je]

Hi there!



We came across your article

referring to a different one

regarding the topic of RFID.



We actually have an entire web page

speaking more about radio-frequency identification, and how it works using
the hexadecimal system.



It speaks to how it can be used to differentiate between other tags, to
access buildings and makes it easily understood using an Infographic

at the very bottom of the page to summarize the topic.



We'd like to offer this Infographic for free to provide value to your
readers to better understand your article on RFID, as we've found many of
our readers and customers have a hard time understanding how it can almost
magically react to a building security reader to open a secured door.



We'd love for you to use it! Please check it out to see if you feel it's a
fit to link to it on your website:



https://fobtoronto.ca/how-do-fobs-work/




Best,



Paul

FobToronto

[PATCH] supress cirrus-ci OS version check

[Илья Шипицин]

Hello,

it turned out that FreeBSD image is slightly different from packages.
since we cannot change image, let us just suppress that warning.


Cheers,
Ilya Shipitcin
From b492635642a9c94e6f59ecb18a147355d408622f Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Wed, 26 Feb 2020 00:57:33 +0500
Subject: [PATCH] BUILD: cirrus-ci: suppress OS version check when installing
 packages

---
 .cirrus.yml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.cirrus.yml b/.cirrus.yml
index 1a07c80c7..86b404782 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -5,6 +5,8 @@ FreeBSD_task:
   image_family: freebsd-12-1-snap
   image_family: freebsd-11-3-snap
   only_if: $CIRRUS_BRANCH =~ 'master|next'
+  env:
+IGNORE_OSVERSION: yes # supress package installation error on FreeBSD-13
   install_script:
 - pkg update -f && pkg upgrade -y && pkg install -y openssl git gmake lua53 socat
   script:
-- 
2.24.1

[ANNOUNCE] haproxy-2.2-dev3

[Willy Tarreau]

Hi,

HAProxy 2.2-dev3 was released on 2020/02/25. It added 103 new commits
after version 2.2-dev2.

This version is mostly a bugfix and cleanup version after dev2, it
addresses roughly 30 bugs that were affecting it. It has very few new
features. Among the visible changes, I'd cite the fact that the
"show ssl cert" CLI command will now list the certificate chain and
issuer, that it now becomes possible to have a separate ".key" file for
the private key associated with a certificate (for this it must not be
present in the cert PEM file), and that the argument parser for the
config file finally supports quotes, braces and square brackets in
arguments, so that it is now possible to write character classes and
groups in the "regsub()" converter. For this these arguments must be
enclosed in quotes inside the argument, which means that you may either
backslash-quote them or have double quotes outside and single quotes
inside (i.e. the quote must appear as a delimiter in the argument after
the config is tokenized), like in this example stolen from Jérôme:

  http-request redirect location '%[url,regsub("(foo|bar)([0-9]+)?","\2\1",i)]'

I wanted to write an extra section about this in the doc but figured it was
stupid to delay a release on doc that advances slower.

If you've met bugs with 2.2-dev2, it may be worth upgrading to dev3 which
should remain almost identical but more reliable.

Please find the usual URLs below :
   Site index   : http://www.haproxy.org/
   Discourse: http://discourse.haproxy.org/
   Slack channel: https://slack.haproxy.org/
   Issue tracker: https://github.com/haproxy/haproxy/issues
   Sources  : http://www.haproxy.org/download/2.2/src/
   Git repository   : http://git.haproxy.org/git/haproxy.git/
   Git Web browsing : http://git.haproxy.org/?p=haproxy.git
   Changelog: http://www.haproxy.org/download/2.2/src/CHANGELOG
   Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/

Willy
---
Complete changelog :
Christian Lachner (1):
  MINOR: build: add aix72-gcc build TARGET and power{8,9} CPUs

Christopher Faulet (13):
  BUG/MINOR: http-act: Set stream error flag before returning an error
  BUG/MINOR: http-act: Fix bugs on error path during parsing of return 
actions
  BUG/MEDIUM: tcp-rules: Fix track-sc* actions for L4/L5 TCP rules
  BUG/MINOR: mux-fcgi: Forbid special characters when matching PATH_INFO 
param
  MINOR: mux-fcgi: Make the capture of the path-info optional in pathinfo 
regex
  MINOR: http-htx: Add a function to retrieve the headers size of an HTX 
message
  MINOR: filters: Forward data only if the last filter forwards something
  BUG/MINOR: filters: Count HTTP headers as filtered data but don't forward 
them
  BUG/MINOR: http-htx: Don't return error if authority is updated without 
changes
  BUG/MINOR: stream: Don't incr frontend cum_req counter when stream is 
closed
  BUG/MINOR: http-ana: Matching on monitor-uri should be case-sensitive
  MINOR: http-ana: Match on the path if the monitor-uri starts by a /
  BUG/MAJOR: http-ana: Always abort the request when a tarpit is triggered

Emmanuel Hocdet (1):
  MINOR: ssl: add "issuers-chain-path" directive.

Ilya Shipitsin (9):
  BUILD: cirrus-ci: switch to "snap" images to unify openssl naming
  BUILD: cirrus-ci: workaround "pkg install" bug
  BUILD: cirrus-ci: add ERR=1 to freebsd builds
  BUILD: travis-ci: no more allowed failures for openssl-1.0.2
  BUILD: travis-ci: harden builds, add ERR=1 (warning ought to be errors)
  BUILD: scripts/build-ssl.sh: use "uname" instead of ${TRAVIS_OS_NAME}
  CLEANUP: ssl: remove unused functions in openssl-compat.h
  BUILD: enable ERR=1 in github cygwin builds
  BUILD: travis-ci: enable s390x builds

Jerome Magnin (4):
  MINOR: sample: regsub now supports backreferences
  MINOR: ist: add an iststop() function
  BUG/MINOR: http: http-request replace-path duplicates the query string
  CLEANUP: sample: use iststop instead of a for loop

Olivier Houchard (1):
  BUG/MEDIUM: muxes: Use the right argument when calling the destroy method.

Tim Duesterhus (4):
  BUG/MINOR: ssl: Stop passing dynamic strings as format arguments
  CLEANUP: conn: Do not pass a pointer to likely
  CLEANUP: net_helper: Do not negate the result of unlikely
  CLEANUP: cfgparse: Fix type of second calloc() parameter

William Dauchy (3):
  BUG/MINOR: tcp: avoid closing fd when socket failed in tcp_bind_listener
  BUG/MINOR: tcp: don't try to set defaultmss when value is negative
  BUG/MINOR: namespace: avoid closing fd when socket failed in my_socketat

William Lallemand (8):
  BUG/MEDIUM: ssl/cli: 'commit ssl cert' wrong SSL_CTX init
  DOC: schematic of the SSL certificates architecture
  MINOR: ssl: load the key from a dedicated file
  BUG/MINOR: ssl: load .key in a directory only after PEM
  MINOR: ssl/cli: 'show ssl cert' 

Re: Unique ID for PROXYv2: Get 'struct stream' from 'struct connection'

[Tim Düsterhus]

Willy,

thank you for the reply.

Am 25.02.20 um 11:57 schrieb Willy Tarreau:
>> I'm currently attempting to extend Proxy Protocol v2 by a new TLV to
>> send a unique ID for TCP connections, similar to the unique-id-header
>> for HTTP.
>>
>> I'm currently struggling to get the `struct stream` within
>> `make_proxy_line_v2`. I could find out that I can get the `struct
>> session` via `remote->owner`, but from there I have no idea how to get a
>> `struct stream`. By printing the allocations it appears that a stream
>> should already exist by the time the proxy line is sent.
> 
> You will not get back to a stream based on a connection because there
> may be many streams per connection. A connection will lead you to a
> mux (H1,H2,FCGI) and from there depending on the mux's protocol and
> internals you'll have 0 to many streams above.

The specific use case I'm exploring is unique IDs for TCP proxying. I
believe for TCP there should be a 1:1 mapping between connections and
streams, no? Anything HTTP can and should just use the header.

> However in many cases you could know the stream that requested the
> outgoing connection. That's what is used when you see that "remote"
> thing. In conn_si_send_proxy(), there's a test to see if the the
> first connection's conn_stream's owner is a stream_interface, and
> if so it uses si_opposite() to find the other side. From this
> stream interface you can get the requesting stream using si_strm().

So I would do:

struct stream *stream = si_strm(si_opposite(si));

similar to that:

struct conn_stream *remote_cs = objt_cs(si_opposite(si)->end);

?

I'll try that, thanks.

>> So questions:
>> 1. Would it generally work to send a unique ID within the proxy line or
>> will that cause issues?
> 
> I'm not seeing any particular issues, however this would require a
> strict definition of how the unique-id is built. I'm assuming you
> want to use the same unique-id as the one built per-stream, but the
> problem is that you'll get many streams over a connection, and that
> at most one of them will have the same ID as the connection (and
> possibly even none of them), and the other ones will remain unrelated.
> In this context one can wonder what's the benefit of building an ID at
> the stream level to use it at the connection level.

As mentioned above: TCP proxying instead of HTTP. Unless my
understanding of 1 connection = 1 stream for TCP is incorrect.

> Maybe you just need a per-connection unique ID. But in this case we
> might need a way similar to the existing one to define the format.
> Or maybe you should just resort to a UUID that is sent only when
> some option is used ?

Yes, that would be my escape hatch if I could not get a stream. In fact
the current version of my code has the unique ID on the connection.
However I liked the idea of not adding another configuration option.

Asking differently: If I wanted to upstream my proposal (with the
explicit focus on unique IDs for TCP), how would you like to see it work?

>> 2. How can I grab the `struct stream` from the `struct connection
>> remote` or more general: How can I get the correct `struct stream` from
>> within `make_proxy_line_v2`?
> 
> From within make_proxy_line_v2() you're too low for this but in
> conn_si_send_proxy() it's OK. Just be careful about what I mentioned
> above regarding unicity vs streams.

Best regards
Tim Düsterhus

Re: [PATCH[ partially enable s390x builds in travis-ci

[Willy Tarreau]

Hi Ilya,

On Wed, Feb 19, 2020 at 11:51:04PM +0500,  ??? wrote:
> Hello,
> 
> 
> I enabled s390x builds except reg-tests/seamless-reload/abns_socket.vtc

Merged, thanks!
Willy

Re: Unique ID for PROXYv2: Get 'struct stream' from 'struct connection'

[Willy Tarreau]

Hi Tim,

On Fri, Feb 21, 2020 at 11:37:42AM +0100, Tim Düsterhus wrote:
> Hi List
> 
> I'm currently attempting to extend Proxy Protocol v2 by a new TLV to
> send a unique ID for TCP connections, similar to the unique-id-header
> for HTTP.
> 
> I'm currently struggling to get the `struct stream` within
> `make_proxy_line_v2`. I could find out that I can get the `struct
> session` via `remote->owner`, but from there I have no idea how to get a
> `struct stream`. By printing the allocations it appears that a stream
> should already exist by the time the proxy line is sent.

You will not get back to a stream based on a connection because there
may be many streams per connection. A connection will lead you to a
mux (H1,H2,FCGI) and from there depending on the mux's protocol and
internals you'll have 0 to many streams above.

However in many cases you could know the stream that requested the
outgoing connection. That's what is used when you see that "remote"
thing. In conn_si_send_proxy(), there's a test to see if the the
first connection's conn_stream's owner is a stream_interface, and
if so it uses si_opposite() to find the other side. From this
stream interface you can get the requesting stream using si_strm().

> So questions:
> 1. Would it generally work to send a unique ID within the proxy line or
> will that cause issues?

I'm not seeing any particular issues, however this would require a
strict definition of how the unique-id is built. I'm assuming you
want to use the same unique-id as the one built per-stream, but the
problem is that you'll get many streams over a connection, and that
at most one of them will have the same ID as the connection (and
possibly even none of them), and the other ones will remain unrelated.
In this context one can wonder what's the benefit of building an ID at
the stream level to use it at the connection level.

Maybe you just need a per-connection unique ID. But in this case we
might need a way similar to the existing one to define the format.
Or maybe you should just resort to a UUID that is sent only when
some option is used ?

> 2. How can I grab the `struct stream` from the `struct connection
> remote` or more general: How can I get the correct `struct stream` from
> within `make_proxy_line_v2`?

>From within make_proxy_line_v2() you're too low for this but in
conn_si_send_proxy() it's OK. Just be careful about what I mentioned
above regarding unicity vs streams.

Cheers,
Willy

Re: [PATCH] OPTIM: startup: fast unique_id allocation for acl

[Willy Tarreau]

Hi Carl,

On Thu, Feb 20, 2020 at 02:00:09PM +, Carl Henrik Holth Lunde wrote:
> > The patch looks good at first glance, however I must have a deeper
> > check because I have no idea what these unique_ids are used for :-)
> > Maybe we could even completely drop them!
> > 
> I do not know if they have any real-world use, but the use case is to
> change ACLs after the configuration is loaded. I assume `-u` is
> supported to allow an administrator to manually number an ACL (i.e. -u
> 100), and then later change that ACL. OpenShift does not do this.
> 
> The patch was written under the assumption that you wanted exactly the
> same behavior.

Yes that's preferable indeed.

> Since you say we maybe can drop them, I have created a
> new patch which should work fine but does not guarantee that automatic
> ids form a gapless sequence from 0. This simplifies the algorithm
> csignificantly. The downside is that an overflow can happen if a very
> high -u number is used in the config file, so I added a check for that.
> The maximum is still very high.

The problem now becomes a matter of backwards compatibility as it will
refuse to start on some configs otherwise valid on older versions. I'd
rather not do this. We could have simply detected the overflow in the
automatic assignment but I'd rather keep the feature even if I don't
use it myself. I've looked at the doc and figured what it's used for.
It's for when you want to replace ACL or map values from the CLI. There
is not always a unique reference file name to work with, but there's a
unique ID that can be used prefixed by a '#'. It's possible that some
infrastructures automatically update usage thresholds from the CLI using
this, for example.

> > I don't know how the current code deals with duplicated IDs nor what
> > impact these might have.
> > 
> 
> Duplicate IDs are handled when the configuration file is read. That
> code is not efficient either but I did not look at improving that
> because I do not know if anyone uses this feature *and* use very large
> configuration files. For small hand written files the code is fine.

Agreed. I've seen the pat_ref_lookupid() which does linear search. I'm
not that much worried by this considering that you managed to significantly
shrink the startup time in your case already.

Well, after having looked at it more closely, I'd still rather keep the
hole-filling algorithm, so if you have a v3 between the two versions it
would be great :-)

Thanks!
Willy