at the moment haproxy is configured to read the config-file /etc/haproxy/haproxy.conf but the man pages states, it can read directories: -f <configuration file|dir> Specify configuration file or directory path. If the argument is a directory the files (and only files) it contains are added in lexical order (using LC_COLLATE=C) ; only non hidden files with ".cfg" extension are added. I would suggest to change /etc/haproxy to /etc/haproxy.d and add 0_default.conf for the default settings.
name it 0_default.cfg ...
I suggest in splitting default settings and demo-config into 2 files.
Assignee: bugsquad => mageia
Will you use it ? You may already use this feature by changing /etc/sysconfig/haproxy: # Set configuration file CONFIG="/etc/haproxy/haproxy.conf" To: # Set configuration file CONFIG="/etc/haproxy/conf.d" It may be nice to have 00_global.cfg 01_defaults.cfg 02_frontend.cfg 03_backend.cfg Or even 02_tcp_default_frontend.cfg The only valid reason I have to avoid it is: How do we handle configuration upgrade ?
I already changed my install to it. $ l /etc/haproxy.d/ 0_default.cfg 0_sticky.cfg 1_demo 1_https443.cfg 2_http80.cfg 3_https400.cfg stats.cfg 0_default.cfg is your default settings and 1_demo are your (disabled) front/backends. My suggestion would be to have good default settings in 0_default.cfg or 0_global.cfg and declare them as "config" in the package. So on update you get an .rpmnew if sth changes. For the real front/backend I would not ship an active config (sth. without .cfg) so the user can see what can be done, but must not use the shipped file. I choose to put the front and backends for one service into one file, and separate the services by port.
I have spent some time thinking about it, I am inclined to think it's not a good idea at all to change this default and that we too close to a personnal preference vs global interest. You may well change /etc/sysconfig/haproxy to: # Set configuration directory CONFIG="/etc/haproxy" Default /etc/haproxy/haproxy.conf will not be sourced, and only your /etc/haproxy/*.cfg will be sourced. This way people using single file /etc/haproxy/haproxy.conf will keep their changes, have no upgrade trouble and you will not be concerned by any configuration change as well. Maybe README.urpmi could benefit to be more detailed about this possibility and logrotate stuff. Feel free to start a discussion on dev ml, point to online recommandations, I will follow the consensus if any emerge and it makes sense ;)
Status: NEW => NEEDINFOAssignee: mageia => mageiaCC: (none) => mageia
You are the maintainer - in the end it is your decission. I guess not many people use this package, and maybe no other guy on dev list. I already changed /etc/sysconfig/haproxy to CONFIG="/etc/haproxy.d" We made these transissions (to dirs instead of a big file) with many packages: php, cron, sudoers, my.cnf ... just to name a few. And I did it myself with mysql a few versions ago. Almost every one needs to change the config file, so on update you get a new .rpmnew file. And now you need to check the differences if an config option has changed. This is way easier, if the file is small. If you stay with a single config file, you should probably add a comment to /etc/haproxy.cfg AND /etc/sysconfig/haproxy that CONFIG can also point to a directory with .cfg files inside.
I have think about switching to directory layout by default, I don't think it adds any value as haproxy do not permit configuration inclusion or heritage. I think it may be nice to add ready to use configuration samples in directory: /usr/share/doc/haproxy/examples The idea is to conver basic needs: - simple http - simple https - fcgi - directory config Do you have other ideas ? Maybe post here your anonymized configuration. This way we may add to the README.urpmi a note pointing to samples ?
CC: (none) => mageia
I just use Level 4 functions. I use it as a tcp loadbalancer and did never install the ssl certificate on this node. In fact it is encrypted traffic (https) I am balancing, but I don't use it to encrypt the traffic before. As a loadbalancer it is quite flexible. So my guess is, it is used in tcp mode most of the time, where it can be used for web traffic or balancing database access. In my case, I open ports 80/443 and balance them to 4 backend servers. If you want, I can share my config files.
Ok se may add to sample list: - tcp load balancer You may add an annonymized (domain in example.com, local ips, no password, etc) config file with two servers, people can extrapolate how to add more from there I think.