Re: [users@httpd] disabling RC4 in apache 2.2.x

[FHDATA]

On Thu, 11 Jan 2018, Daniel wrote:


check the output of your cipher-spec changes easily with:

openssl ciphers -v 'X:!RC4+RSA:XX'




bob=$(egrep "^SSLCipherSuite "  /etc/httpd/conf.d/ssl.conf)

openssl ciphers -v $bob



openssl ciphers -v $bob| egrep -iv rc4



i assume that's all good then ...


thank you
F-








2018-01-11 0:27 GMT+01:00 FHDATA :



hello


 :RC4+RSA:  appears in SSLCipherSuite of apache 2.2.15's ssl.conf


to disable  RC4, will this be enough:


   :!RC4+RSA:


or a different syntax is needed?



thank you,
F-



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org





--
Daniel Ferradal
IT Specialist

email dferradal at gmail.com
linkedin es.linkedin.com/in/danielferradal

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] disabling RC4 in apache 2.2.x

[Daniel]

check the output of your cipher-spec changes easily with:

openssl ciphers -v 'X:!RC4+RSA:XX'

2018-01-11 0:27 GMT+01:00 FHDATA :
>
>
> hello
>
>
>  :RC4+RSA:  appears in SSLCipherSuite of apache 2.2.15's ssl.conf
>
>
> to disable  RC4, will this be enough:
>
>
>:!RC4+RSA:
>
>
> or a different syntax is needed?
>
>
>
> thank you,
> F-
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>



-- 
Daniel Ferradal
IT Specialist

email dferradal at gmail.com
linkedin es.linkedin.com/in/danielferradal

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] dumb apr_pool question

[Yann Ylavic]

On Thu, Jan 11, 2018 at 3:05 PM, Eric Covener  wrote:
> On Thu, Jan 11, 2018 at 3:55 AM, Simon Walter  wrote:
>>
>> I suppose that the pool is keeping track of all it's allocations and if
>> something is still referenced, it will not free it.
>
> No the only tracking is done by whoever manages the lifecycle of the
> pool itself -- no magic.
>
> apr_pool_destroy will call free() or munmap or any underlying
> allocation on the way out, returning it to the OS.

Actually the memory is returned to the (apr_)allocator, which itself
may cache for further reuse.
One can use apr_allocator_max_free_set() to limit the number of pages
cached (no limit by default), e.g. something like the following code
based on Simon's (not even compile tested...):

int main(int ArgCount, char * Arg[])
{
char * String;
apr_pool_t * Pool = NULL;
apr_allocator_t * Alloc = NULL;
apr_initialize();

/* New allocator (not the default/unlimited one) */
apr_allocator_create();
/* Cache one page only (may be 4K pages, not system's),
 * zero is unlimited, so the cache is always 1 page min... */
apr_allocator_max_free_set(Alloc, 1/*page*/);
/* Use this allocator for the pool */
apr_pool_create_ex(, NULL, NULL, Alloc);
/* Destroy Alloc when destroying Pool */
apr_allocator_owner_set(Alloc, Pool);


/* Won't crash (possibly), don't do that for real... */
String = apr_pstrdup(Pool, "small alloc");
apr_pool_clear(Pool);
printf("String: %s\n", String);

/* Should crash */
(void)apr_palloc(Pool, 4100);
(void)apr_palloc(Pool, 4100);
(void)apr_palloc(Pool, 4100);
String = apr_pstrdup(Pool, "small alloc");
apr_pool_clear(Pool);
printf("String: %s\n", String);

/* Should also crash */
String = apr_pstrdup(Pool, "small alloc");
apr_pool_destroy(Pool); /* + Alloc */
printf("String: %s\n", String);

apr_terminate();
return 0;
}

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] httpd processes are too many created from Apache 2.2.31 on Linux Server.

[Eric Covener]

On Wed, Jan 10, 2018 at 11:14 PM, 갈준영  wrote:
> Hello.
>
> I'm using Apache 2.2.31 on Linux Server.
>
> I've faced an issue that Memory Utilization is over 80% on Linux Server.
>
> When I checked /var/log/messages on Linux Server, I found out that httpd
> processes were too many created on Linux server.

How many were created? What makes you say it was too many vs. an
expected number that just used too much memory?

You're using prefork, which is going to create lots of processes and
use the most memory.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] dumb apr_pool question

[Eric Covener]

On Thu, Jan 11, 2018 at 3:55 AM, Simon Walter  wrote:
> Hi everyone,
>
> Am I correct to assume that a pool cannot be forcibly (prematurely)
> freed? I was trying to understand apr_hash and wanted to free the memory
> allocated for the keys and then try a apr_hash_get. You know, put it
> through it's paces ;)

apr_pool_destroy should do this.


>
> I read about apr_pool_clear:
> "This does not actually free the memory, it just allows the pool to
> re-use this memory for the next allocation."
> but about apr_pool_destroy:
> "This will actually free the memory"
>
> However, when I run this simple program through valgrind, there are no
> memory errors.
>
> I suppose that the pool is keeping track of all it's allocations and if
> something is still referenced, it will not free it.

No the only tracking is done by whoever manages the lifecycle of the
pool itself -- no magic.

apr_pool_destroy will call free() or munmap or any underlying
allocation on the way out, returning it to the OS.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] remoteip support in 2.4 branch

[Marcin Giedz]

Hi there, hopefully this is right place to ask - in trunk version remoteip has 
been extended with some PROXY protocol support. Are there any chances these 
changes will be backported to 2.4 branch ? 

Thx 
Marcin 

Re: [users@httpd] slower https transfer speeds compared with rsync/smb/sftp

[Adam Teale]

I have tried setting SendBufferSize to all many different amounts but it
doesn't affect the transfer speed.

mod_info:

Current Configuration:
In file: /Library/Server/Web/Config/apache2/httpd_server_app.conf
 460: StartServers 4
 461: MinSpareServers 3
 462: MaxSpareServers 10
 463: ServerLimit 256
 464: MaxClients 256
 466: SendBufferSize 1042560

2018-01-11 10:42 GMT-03:00 Adam Teale :

> Hi Yann! Thanks for your help.
>
> The value for sendspace is "1042560"
> ​What does that value mean? Is that how many bytes per packet​ can be sent
> at a time?
>
> ​At that current setting the downloads sit at around 34MB/second.
>
> I appreciate your help, cheers!
>
> Adam​
>
>
> 2018-01-11 10:22 GMT-03:00 Yann Ylavic :
>
>> On Thu, Jan 11, 2018 at 1:46 PM, Adam Teale  wrote:
>> > Hey Eric thanks for letting me know about SendBufferSize, looking into
>> it
>> > now.
>> > Any idea how to see what it currently defaults to via a command?
>>
>> It defaults to the value of the system, so possibly on Mac OS the
>> value of "sysctl net.inet.tcp.sendspace"?
>>
>> Regards,
>> Yann.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>> For additional commands, e-mail: users-h...@httpd.apache.org
>>
>>
>

Re: [users@httpd] slower https transfer speeds compared with rsync/smb/sftp

[Adam Teale]

Hi Yann! Thanks for your help.

The value for sendspace is "1042560"
​What does that value mean? Is that how many bytes per packet​ can be sent
at a time?

​At that current setting the downloads sit at around 34MB/second.

I appreciate your help, cheers!

Adam​


2018-01-11 10:22 GMT-03:00 Yann Ylavic :

> On Thu, Jan 11, 2018 at 1:46 PM, Adam Teale  wrote:
> > Hey Eric thanks for letting me know about SendBufferSize, looking into it
> > now.
> > Any idea how to see what it currently defaults to via a command?
>
> It defaults to the value of the system, so possibly on Mac OS the
> value of "sysctl net.inet.tcp.sendspace"?
>
> Regards,
> Yann.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

Re: [users@httpd] slower https transfer speeds compared with rsync/smb/sftp

[Yann Ylavic]

On Thu, Jan 11, 2018 at 1:46 PM, Adam Teale  wrote:
> Hey Eric thanks for letting me know about SendBufferSize, looking into it
> now.
> Any idea how to see what it currently defaults to via a command?

It defaults to the value of the system, so possibly on Mac OS the
value of "sysctl net.inet.tcp.sendspace"?

Regards,
Yann.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] slower https transfer speeds compared with rsync/smb/sftp

[Adam Teale]

Hey Eric thanks for ​letting me know about SendBufferSize, looking into it
now.
Any idea how to see what it currently defaults to via a command?

2018-01-08 16:49 GMT-03:00 Eric Covener :

> On Mon, Jan 8, 2018 at 1:46 PM, Adam Teale  wrote:
> > Hi everyone,
> >
> > Firstly I hope this is an appropriate question for this list.
> >
> > I am looking into what could be causing decreased speeds when
> > uploading/downloading files to our apache server via https.
> >
> > Can anyone suggest why upload/download transfers speeds in a web browser
> > (Firefox, Chrome, Safari) via https sustain between 30-35MB/sec where as
> > file transfers via rsync/smb/sftp sit between 90-110MB/sec (from the same
> > server)?
> >
> > I have just tested http upload/download in the opposite direction
> (running
> > apache server on the client machine via httpd-userdir) and the transfer
> > rates are 110MB/sec
> >
> > Are there settings that can be adjusted in Apache or perhaps some system
> > files?
> >
> > We are running Mac OS 10.12 and Mac OS Server 5.2 (Apache 2.4).
> >
> > Any feedback would be greatly appreciated. Thanks!
> >
>
> Tried tweaking SendBufferSize?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

[users@httpd] dumb apr_pool question

[Simon Walter]

Hi everyone,

Am I correct to assume that a pool cannot be forcibly (prematurely)
freed? I was trying to understand apr_hash and wanted to free the memory
allocated for the keys and then try a apr_hash_get. You know, put it
through it's paces ;)

I read about apr_pool_clear:
"This does not actually free the memory, it just allows the pool to
re-use this memory for the next allocation."
but about apr_pool_destroy:
"This will actually free the memory"

However, when I run this simple program through valgrind, there are no
memory errors.

I suppose that the pool is keeping track of all it's allocations and if
something is still referenced, it will not free it.

I also suppose that "This will actually free the memory" is ambiguous:
https://apr.apache.org/docs/apr/1.6/group__apr__pools.html#ga54759954d2cba7cb649ab5680a33f9e3

https://apr.apache.org/docs/apr/trunk/group__apr__pools.html#ga54759954d2cba7cb649ab5680a33f9e3

Kind regards,

Simon




#include 
#include 
#include 

char * test_destroy(void);

char * test_destroy(void)
{
apr_pool_t * Crash = NULL;
apr_pool_create(, NULL);
char * String = apr_pcalloc(Crash, 4);
strcpy(String, "txt");
apr_pool_destroy(Crash);
return String;
}

int main(int ArgCount, char * Arg[])
{
apr_initialize();
char * String = test_destroy();
printf("String: %s\n", String);
apr_terminate();
return 0;
}

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org