Re: init.d-script in 2.4.33pre?

"Also sprach Bas van Schaik:"
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> I think
> > ...
> >     SERVER_CONFIG=${NBD_CONFIG}
> > ...
> 
> Should be replaced by
> > ...
> >     SERVER_CONFIG=${ENBD_CONFIG}

Correct. My bad. Thanks for noticing! In fact, I think it should be
OLD_CONFIG, since there is a line above ...

   OLD_CONFIG="${ENBD_CONFIG-/etc/enbd.conf}"


> I assume those "variables" should be replaced with real values during
> the build process, but I cannot find a makefile which processes this

They are real variables, if we are talking about init.d/enbd. We
decided that autoconf/configure wouldn't build the "right stuff" on its
own, and instead the parameters set by configure would be overwritten
on the gcc compile line during the build. You are _correct_ in saying
that the init.d/enbd script needs similar modification and that I
haven't done that yet.  I would suggest that the modification be done in
/etc/default/enbd, and that init.d/enbd be set to read that script
first, if it exists.

  # /etc/default/enbd

  # where is the config file (default /etc/enbd.conf)
  # ENBD_CONFIG=/etc/enbd.conf

  # can have separate config files for server and client, which will be
  # read instead if these values are defined.
  # (defaults /etc/enbd_{server,client}.conf)
  # ENBD_SERVER_CONFIG=/etc/enbd_server.conf
  # ENBD_CLIENT_CONFIG=/etc/enbd_client.conf



> "template" file.
> 
> Also, in nbd/enbd_conf.h:
> > #ifndef CONFDIR
> > # define CONFDIR "/etc"
> > #endif /* CONFDIR */
> > 
> > /* old combined file  - fallback to this if others not there */
> > #ifndef ENBD_CONFIG_FILE
> > # define ENBD_CONFIG_FILE        CONFDIR "/enbd.conf"
> > #endif /* ENBD_CONFIG_FILE */
> > 
> > #ifndef ENBD_SERVER_CONFIG_FILE
> > # define ENBD_SERVER_CONFIG_FILE CONFDIR "enbd-server.conf"
> > #endif /* ENBD_SERVER_CONFIG_FILE */
> > 
> > #ifndef ENBD_CLIENT_CONFIG_FILE
> > # define ENBD_CLIENT_CONFIG_FILE CONFDIR "enbd-client.conf"
> > #endif /* ENBD_CLIENT_CONFIG_FILE */
> 
> I think
> > define ENBD_CLIENT_CONFIG_FILE CONFDIR "enbd-client.conf"
> and
> > define ENBD_SERVER_CONFIG_FILE CONFDIR "enbd-server.conf"
> 
> Should be replaced by
> > define ENBD_CLIENT_CONFIG_FILE CONFDIR "/enbd-client.conf"
> and
> > define ENBD_SERVER_CONFIG_FILE CONFDIR "/enbd-server.conf"

You are right .. and the hyphens should be underlines! Corrected!

> In general: is there something like a bug tracking system for enbd? I

I presume that sourceforge has one.  I've never used it. Indeed, debian
has one! (ditto). The major bugs are things I know about and would be
embarassed to discuss, such as that remote ioctls weren't working on 64
bit platforms last time I looked (probably a 32 bit field somewhere
cramping their style), and there is a slight tendency to produce 
an oops if the module is removed on a 2.6 platform while requests are
still in flight, or possibly when breathing too hard. And umm, what
was that report here from a couple of weeks ago that I was trying to get
time to look at ....

> can't find one on the website, and I think it can be very useful,
> because more and more people are using enbd. If necessary I can arrange
> a bugzilla/flyspray/whatever installation on a stable location, so just
> let me know.

If you'd like to do that, great! But the problem is using one, not
there being one. I get nagged enough on the list to make me do things.
The point, I think, is that minor bugs are so easy to fix that I'd do
it at once, while major bugs are so difficult to fix that I'd need
paying. Can you think of a way to engage with that human problem?

Peter