Re: [users@httpd] To Gzip or not?
On 12 Dec 2020, at 06:59, @lbutlr wrote: > TLS 1.4 1.3 -- "Are you pondering what I'm pondering?" "Well, I think so, Brain, but snort no, no, it's too stupid!" - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] APR util slotmem errors.
Thanks Yann, I really appreciate the information! This really helps!
On Sat, Dec 12, 2020, 7:01 AM Yann Ylavic wrote:
> Hi,
>
> These are more questions for the dev@apr.a.o (or dev@httpd) mailing
> list, though there are APR developers on this list too ;)
>
> >
> > Quick question how does the apr use the shm segments and why does it
> have a slotmem error if we use mod_proxy with several balancer name calls
> and multiple hosts apache servers on a single dev box? I am really trying
> to understand how this code segment below works?
>
> So you don't have balancer://url duplicates (anymore) and still slotmem
> errors?
>
> >
> > shm.c file call?
> >
> > #if APR_USE_SHMEM_SHMGET
> >71 static key_t our_ftok(const char *filename)
> >72 {
> >73 /* to help avoid collisions while still using
> >74 * an easily recreated proj_id */
> >75 apr_ssize_t slen = strlen(filename);
> >76 return ftok(filename,
> >77 (int)apr_hashfunc_default(filename, &slen));
> >78 }
> >79 #endif
>
> This is a wrapper around the system's ftok() function, a thingy needed
> by the IPC SysV API to create a unique ID from a file path, to be
> passed to shmget() & co system calls.
>
> From the Linux man page:
>
> SYNOPSIS
>key_t ftok(const char *pathname, int proj_id);
>
> DESCRIPTION
>The ftok() function uses the identity of the file named by the
> given pathname (which must refer to an existing, accessible file) and
> the least significant 8 bits of proj_id (which must be non‐zero) to
> generate a key_t type System V IPC key, suitable for use with
> msgget(2), semget(2), or shmget(2).
>The resulting value is the same for all pathnames that name the
> same file, when the same value of proj_id is used.
>The value returned should be different when the (simultaneously
> existing) files or the project IDs differ.
>
> NOTES
>On some ancient systems, the prototype was:
>key_t ftok(char *pathname, char proj_id);
>Today, proj_id is an int, but still only 8 bits are used.
>Typical usage has an ASCII character proj_id, that is why the
> behavior is said to be undefined when proj_id is zero.
>Of course, no guarantee can be given that the resulting key_t is
> unique.
>Typically, a best-effort attempt combines the given proj_id
> byte, the lower 16 bits of the inode number, and the lower 8 bits of
> the device number into a 32-bit result.
>Collisions may easily happen, for example between files on
> /dev/hda1 and files on /dev/sda1.
>
> Neat.. the IPC SysV API is horrid (IMHO) :/
>
> Fortunately the APR lib does not expose this proj_id since it has no
> meaning for the other possible SHM mechanisms (e.g. POSIX).
> To help with the collision issue, the proj_id is not fixed to a
> non-zero constant either, but rather hashed from the filename to
> improve mixing.
>
> The apr_hashfunc_default() function used here (djbhash) is not the
> more collision resistant one.
> For the POSIX mechanism the APR lib also mixes in an rshash of the
> filename, for IPC SysV this would be:
>
> static key_t our_ftok(const char *filename)
> {
> /* to help avoid collisions while still using
> * an easily recreated proj_id */
> apr_ssize_t flen;
> unsigned int h;
>
> flen = strlen(filename);
> h = apr_hashfunc_default(filename, &flen);
> h ^= rshash(filename);
> if (h == 0) {
> h = 0xc; /* arbitrary, non-zero */
> }
> return ftok(filename, h);
> }
>
> But there have been no issue raised so far for the current IPC SysV
> implementation.
> Do you observe collisions for different file names here, by e.g.
> adding a printf of the filename and hash in the current our_ftok()
> function?
>
> >
> > APR_PERMS_SET_IMPLEMENT(shm)
> > 696 {
> > 697 #if APR_USE_SHMEM_SHMGET || APR_USE_SHMEM_SHMGET_ANON
> > 698 struct shmid_ds shmbuf;
> > 699 int shmid;
> > 700 apr_shm_t *m = (apr_shm_t *)theshm;
> > 701
> > 702 if ((shmid = shmget(m->shmkey, 0, SHM_R | SHM_W)) == -1) {
> > 703 return errno;
> > 704 }
>
> Here m->shmkey is then the result of our_ftok(filename).
>
>
> Regards;
> Yann.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
Re: [users@httpd] To Gzip or not?
On 10 Dec 2020, at 07:38, Tom Browder wrote: > When I last serious upgrades to my servers last July one problem with using > TLS 1.3 was that the Firefox browser couldn't use it as because of > post-handshake problems. So I'm currently running TLSv1.2. Firefox in general? Or some specific (or old) version? It has no issues connecting to TLS 1.4 for me. All you have to do for TLS 1.2 to be secure agains BREACH/CRIME is to disable the header compression, if you are unlucky enough to have an implementation that enabeld it by default. If you have recent-ish versions of openSSL I don't think you can enable compression without patching and rebuilding. (I don't run Firefox myself, but I launch it every few months to make sure my stuff at least loads on it) -- Say, give it up, give it up, television's taking its toll That's enough, that's enough, gimme the remote control I've been nice, I've been good, please don't do this to me Turn it off, turn it off, I don't want to have to see - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] APR util slotmem errors.
Hi,
These are more questions for the dev@apr.a.o (or dev@httpd) mailing
list, though there are APR developers on this list too ;)
>
> Quick question how does the apr use the shm segments and why does it have a
> slotmem error if we use mod_proxy with several balancer name calls and
> multiple hosts apache servers on a single dev box? I am really trying to
> understand how this code segment below works?
So you don't have balancer://url duplicates (anymore) and still slotmem errors?
>
> shm.c file call?
>
> #if APR_USE_SHMEM_SHMGET
>71 static key_t our_ftok(const char *filename)
>72 {
>73 /* to help avoid collisions while still using
>74 * an easily recreated proj_id */
>75 apr_ssize_t slen = strlen(filename);
>76 return ftok(filename,
>77 (int)apr_hashfunc_default(filename, &slen));
>78 }
>79 #endif
This is a wrapper around the system's ftok() function, a thingy needed
by the IPC SysV API to create a unique ID from a file path, to be
passed to shmget() & co system calls.
>From the Linux man page:
SYNOPSIS
key_t ftok(const char *pathname, int proj_id);
DESCRIPTION
The ftok() function uses the identity of the file named by the
given pathname (which must refer to an existing, accessible file) and
the least significant 8 bits of proj_id (which must be non‐zero) to
generate a key_t type System V IPC key, suitable for use with
msgget(2), semget(2), or shmget(2).
The resulting value is the same for all pathnames that name the
same file, when the same value of proj_id is used.
The value returned should be different when the (simultaneously
existing) files or the project IDs differ.
NOTES
On some ancient systems, the prototype was:
key_t ftok(char *pathname, char proj_id);
Today, proj_id is an int, but still only 8 bits are used.
Typical usage has an ASCII character proj_id, that is why the
behavior is said to be undefined when proj_id is zero.
Of course, no guarantee can be given that the resulting key_t is unique.
Typically, a best-effort attempt combines the given proj_id
byte, the lower 16 bits of the inode number, and the lower 8 bits of
the device number into a 32-bit result.
Collisions may easily happen, for example between files on
/dev/hda1 and files on /dev/sda1.
Neat.. the IPC SysV API is horrid (IMHO) :/
Fortunately the APR lib does not expose this proj_id since it has no
meaning for the other possible SHM mechanisms (e.g. POSIX).
To help with the collision issue, the proj_id is not fixed to a
non-zero constant either, but rather hashed from the filename to
improve mixing.
The apr_hashfunc_default() function used here (djbhash) is not the
more collision resistant one.
For the POSIX mechanism the APR lib also mixes in an rshash of the
filename, for IPC SysV this would be:
static key_t our_ftok(const char *filename)
{
/* to help avoid collisions while still using
* an easily recreated proj_id */
apr_ssize_t flen;
unsigned int h;
flen = strlen(filename);
h = apr_hashfunc_default(filename, &flen);
h ^= rshash(filename);
if (h == 0) {
h = 0xc; /* arbitrary, non-zero */
}
return ftok(filename, h);
}
But there have been no issue raised so far for the current IPC SysV
implementation.
Do you observe collisions for different file names here, by e.g.
adding a printf of the filename and hash in the current our_ftok()
function?
>
> APR_PERMS_SET_IMPLEMENT(shm)
> 696 {
> 697 #if APR_USE_SHMEM_SHMGET || APR_USE_SHMEM_SHMGET_ANON
> 698 struct shmid_ds shmbuf;
> 699 int shmid;
> 700 apr_shm_t *m = (apr_shm_t *)theshm;
> 701
> 702 if ((shmid = shmget(m->shmkey, 0, SHM_R | SHM_W)) == -1) {
> 703 return errno;
> 704 }
Here m->shmkey is then the result of our_ftok(filename).
Regards;
Yann.
-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
