/usr/sbin/apache2ctl sources /usr/sbin/envvars if that exists, so that's the right place IMO. Anotherone would be /etc/sysconfif/apache2, but I'm not sure if SuSEconfig or Yast is overwriting it.

Thanks for answer. But I don't know, if this two files are replaced after a system update. And as you said, envvars is only used by apache2ctl. But the start script /etc/init.d/apache2 uses the apache binary directly. I'm looking for a more general way to set this variables. Is there nowhere a way, to set global environment variables during boot? Thanks Meike -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On March 4, 2013 at 3:11 PM "Carlos E. R." wrote: El 2013-03-04 a las 10:50 +0100, Meike Stone escribió:

...

I'm looking for a more general way to set this variables. Is there nowhere a way, to set global environment variables during boot?

When such things exists, they are named something.local.

Example: /etc/bash.bashrc.local

The question is *what* environment variables ... E.g. I have an apache2 system here which needs an additional LD_LIBRARY_PATH entry, so I wouldn't put that into a global rc-file. If the httpd-process does not already need that variable, but instead a certain web application, then there are other ways: http://httpd.apache.org/docs/2.2/env.html Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

2013/3/4 Cristian Rodríguez :

The fact you don't find where do it should give you a solid idea of what's going on..

I try to write a application with different services like apache, freeradius, mysql, ldap, snmpd. I know, it is maybe possible, to set env variables in /etc/sysconfig/apache2 and mysql ... But it has to be done for every config and service again and it is error-prune. The goal is, to set this variables only one time on one place. All applications and services can rely on this without extra interaction. Second is, that want modify the system and files are delivered with the system or packages as less as possible (eg. use own vhosts, use /etc/profile.d, use /etc/cron.d, and so on ..). So it is easier to backup the config and rely to the default files (if possible), easier to set up the system and automate the setup and it is easier to describe and understanding the installation.

** what you are trying to do is an horrible bad idea ;P ***

What is horrible on it?

Care to share *exactly* what are you trying to accomplish here, there is probably a sane way to do it.

One example for this, I told exactly in my first post (apache2). But this is an example only. The Question in general is, how to set environment variables global, so that they are available in init scripts (example for this is HOSTNAME) The file /etc/boot.local is also NOT the solution, set env variables ar not available in other init scripts. The ONLY solution I found is to modify /etc/sysconfig/boot and source there my configfile from /etc/profile.d/ But I'm not sure, if this is the bet, to modify this file. Thanks Meike :-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El lun 04 mar 2013 14:12:33 CLST, Cristian Rodríguez escribió:

El lun 04 mar 2013 14:00:42 CLST, Meike Stone escribió:

...

...

** what you are trying to do is an horrible bad idea ;P *** What is horrible on it?

The environment of a process is not the proper place to do this, daemons must sanitize the environment before starting, not doing that is a security hole.

What a daemon must do at startup is documented here http://www.linuxcertif.com/man/7/daemon/ section "SysV Daemons" Your need of passing arbitrary environment variables to a daemon conflicts with step 4. Note that those 15 steps in the document describe the ideal behavior. I have not found any that either implements all the required steps or do them correctly, but a mythological daemon might :-) Nowdays we aspire to provide functionality as "New-Style Daemons" if possible. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Meike Stone said the following on 03/05/2013 03:40 AM:

Last question. Should I only avoid to set global variables, or is it in general not recommended to use env variables with apache.

And in that wording you have it. It seems to me that you are confusing 'variables' - that which gets altered - with 'settings' - which don't. If I'm understanding correctly, all this is in the context of Apache and web services and not in the general context of J Random Program running on the machine or cluster. HOSTNAME is not a "global variable", it is a host level setting. That doesn't make it 'global' in my mind. You might be running Apache on a cluster of machines each with their own HOSTNAME. It is the settings internal to the Apache services and how the Apache server responds to an outside request that can be viewed as an 'identity' of the server. I mention this because I have in the past set up a 'load balanced' arrangement using round-robin DNS Apache service with initially 2, later 3 and then just to show the point 5 host machines. Each machine had its own HOSTNAME. As far as the client was concerned it was all one service. That, within a shell, you can alter the environment variable HOSTNAME has nothing to do with the system setting of the file /etc/HOSTNAME. Look at 'man 1 hostname' for example. <quote> Note, that only the super-user can change the names. </quote> As others have pointed out, many services clear their environment variables. Clearing HOSTNAME won't affect what's returned by 'gethostname(2)' or gethostname(3)'. Similarly the information returned by 'uname(2)'.

I use this variables to set path variables for eg. logfiles, certificates. If you have eg. 100 vhots, it is really easier to manage them.

This sounds like the way one of the ISPs I use for web services, Dreamhost, has it set up. I gather its a pretty normal way to set up such a service.

My colleges, who are responsible for this vhosts, only get the variables. Configuration for pathes (eg. other mountpoint ..) changes, so I only have to change the environment variables. What makes it so dangerous to us this mechanism, provided by apache, to use for set logfile path?

I don't think its dangerous. I think your understand of Apache and vhosts is getting confused with that of a generic server. The whole point of the vhost is that it shares an IP address but not the 'hostname'. Not the lower case. The Apache docco gives an example of using DNS to map various hostnames - not the lower case - all running on the same machine (and hence sharing a HOSTNAME). All these are SETTINGS not variables. For any single vhost the location of the document root, the location of the log files is SET and cannot be altered by the processes running under that invocation of the server. In my case with Dreamhost I have a an account (~anton) and when I want to set up a web service of any kind the cPanel interface first asks me which of my registered domains to use. I may have to create a new subdomain of - for example - 'antonaylward.com'; blog, webmail, gallery, wiki ... whatever. The cPanel interface then suggests locations under ~anton for the document root etc. I can't put it under, say, ~meikestone. The code behind the cPanel then creates the necessary vhost and if necessary the domain. All this has to match up. Once done I can't alter the entry in /etc/http.d/conf/vhosts.d What's in there is SETTINGS, not variables. Maybe I'm stating a pile of stuff here that's obvious to you, but I'm not sure. You do seem confused about something. I say 'confused' because I think you are misunderstanding something very basic about how Apache and vhosts work. Look: there is a web service at 'mail.antonaylward.com. If you run 'dig mail.antonaylward.com' you will see there is a legitimate DNS entry: ;; ANSWER SECTION: mail.antonaylward.com. 14400 IN A 208.113.200.129 Now if you ping 'mail.antonaylward.com' you get PING mail.antonaylward.com (208.113.200.129) 56(84) bytes of data. 64 bytes from sub5.mail.dreamhost.com (208.113.200.129): ... That's 'cos 'ping' does a reverse DNS lookup of what it finds when it does a forward DNS lookup on 'mail.antonaylward.com' The HOSTNAME is sub5.mail.dreamhost.com. The hostname is mail.antonaylward.com - that's what in the vhost settings.[1] Of course being a shared server there are going to be many domain entries that to the same IP address :-) That's the whole point of shared services like vhosts. So I'm in the same situation as the colleagues you mention. I only get the end result of what the 'automated sysadmin' that is the scripts behind cPanel sets. I don't have the authority to alter the vhosts.d/*.antonaylward.com entries for the various domains and services I've set up using cPanel. Automation is a good thing; it means consistency and once you've debugged it, reliable service. The constraints I have as a customer of an ISP aren't a restriction as far as I'm concerned. If I was that concerned I'd ask to have a 'real' virtual host and do all the admin myself and probably buqqer something up. If I want to play, experiment and learn from buqqering up things I have scratch machines for that sole purpose.

PS: HOSTNAME was only a example for a global variable ;-)

A bad example since its not a really variable. See above for reference to the MAN pages. Please also read the entry in the bash man page for HOSTFILE. I suspect you getting confused with the way environment variables are set and managed under DEC's VMS. [1] Actually this example is for the mail or webmail server rather than the generic web server, but the principle still applies. -- The truth of a proposition has nothing to do with its credibility. And vice versa. Excerpt from the notebooks of Lazarus Long, from Robert Heinlein's "Time Enough for Love" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

PLEASE DO NOT REPLY TO *BOTH* THE LIST AND THE POSTER DIRECTLY! Meike Stone said the following on 03/05/2013 09:45 AM:

2013/3/5 Anton Aylward :

...

If I'm understanding correctly, all this is in the context of Apache and web services and not in the general context of J Random Program running on the machine or cluster.

Yes and no. I like to set environment variables only for pathes, where logging files can be placed (APACHE_LOG). Accessed from vhost like: CustomLog ${APACHE_LOG}/host1-access.log combined But the same logging files are analyzed from other tools. So this tools use the same Path (and so environment variable

There's the matter of getting things running and then apply 'finesse'

How Apache works together with hostnames and virtual host, that is clear for me, also how name resolving works and how apache knows, which vhost is responsible for a http(s) request. It is also important to know that, because we use SSL and care for rfc4366 and SNI ;-)

I suspect you have a deeper problem. SSL uses x.509 certificates and x.509 is remarkable Brian Dead[1], as is much of the whole ISO approach to networking - Mike Padlipsky has a lot to say on that subject, all very cutting and most of which has never been refuted. In this instance the problem, with X.509 is that it does not support aliases. The Apache Vhosts mechanism is an IP sharing mechanism. It uses the input from DNS and the client to decide which of the hosts sharing the IP address is the instance to be used. There a line in the HTTP request header that does this. See the docco. (but you know this, don't you?) So what we have is a DNS mechanism that supports aliases. Think 'CNAME'. While X.509 is Brian Dead; it won't support aliases. It thinks in terms of "one ip address, one fqdn". What this amount to is that with SSL you need a separate IP address for each ... whatever we're calling it. Yes, the Apache vhosts definition will allow this, but ... Yes, you could do this by implementing virtual hosts, each with their own IP address and each with their own fqdn and hece each each with their own HOSTAME and /etc/HOSTNAME file. [1] Go google. See 'Hacker's Dictionary' in particular. -- Politically Correct Virus: Doesn't refer to itself as a virus - instead, refers to itself as an "electronic microorganism." — Mark Kaye -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 05/03/13 05:40, Meike Stone escribió:

Yes, I know systemd ... I'm not enjoyed about that on servers ... it is in my opinion against the KISS principle. I does not care for the time of boot process. I'm looking forward, what SuSE is going to do with systemd in SLES12 ,,, In case of Desktops, it makes really sense.

Looks like you need to read.. http://0pointer.de/blog/projects/the-biggest-myths.html :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez said the following on 03/05/2013 09:29 AM:

El 05/03/13 05:40, Meike Stone escribió:

...

Yes, I know systemd ... I'm not enjoyed about that on servers ... it is in my opinion against the KISS principle. I does not care for the time of boot process. I'm looking forward, what SuSE is going to do with systemd in SLES12 ,,, In case of Desktops, it makes really sense.

Looks like you need to read.. http://0pointer.de/blog/projects/the-biggest-myths.html :)

+1 on all counts! I'm really enjoying working with systemd, its properly worked out unlike the ad-hoc-ism or systemvscripts! It really does embody the KISS principle - modularization within a well specified framework, clear command and communication methods, small and clear modules, elimination of many of the coupling problems (not least of all environment settings!) of systemvscripts. There are a few basic principles of good software SYSTEM design. Yes, Yourdon et al may seem old hat these days, but those principles of hierarchy and cohesion that he and his 'school' preached are often overlooked to our cost. The systemvscripts approach lacked any general management management; error reporting and handling was up to each script and it was more by coincidence that they used syslog! The 'do this then do this then do this..." approach could not lend itself to error MANAGEMENT or dependency management (aka hierarchy) without some more ad-hoc gyrations. There was little functional cohesion except for putting more and more - overloading - in a single script. Each script being separate there was no communication cohesion - a point that systemd quite specifically addresses in its design. Temporal and procedural cohesion was forced and unmanageable in the very nature of systemvscripts, there being no clear, easy or manageable mechanism supporting parallelism Much of the start up consists of activities that have little relation relationship to each other once some basic things are in place such as network having been started or the shared memory file system - /var/run, /var/lock - having been started. if we'd been using systemd for years and someone suggested replacing it with systemvscripts there would be an outcry at the sheer stupidity and incoherent ad-hoc nature of the way systemvscripts works. -- Definitions are temporary verbalizations of concepts, and concepts -- particularly difficult concepts -- are usually revised repeatedly as our knowledge and understanding grows. -- Ernst Mayr -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org