Beta for online database storage ready (RFC)

[Jeff Waller]

See "Online target database?" thread for info.  Following up from that thread, I've
made the following changes, and require some feedback (see below).

==========================================================
1) Updated ietadm and the ietd<--->ietadm protocol to allow a --sync option.  If present,
this will cause ietd to first perform the changes specified by the other operator
present on the command line for ietadm, and then after those changes are complete
will write our a new configuration file named basename.x where:

basename is the name of the configuration file ietd was invoked with (e.g. /etc/ietd.conf).
x is a number extending the filename.

So if ietd was started with /etc/ietd.conf, the new configuration file would be named
/etc/ietd.conf.1.

Added support in the daemon to fetch all the parameters necessary for reconstructing
the configuration file:
        targets
        target parameters
        users
        luns
        isns server information

2)  Modified ietd to prefer using a configuration file with the highest value extension
number (see above) for obtaining its startup information when it first starts.  So
for example if there are files /etc/ietd.conf /etc/ietd/conf.1 /etc/ietd/conf.2,  ietd
will use /etc/ietd.conf.2.  The idea being that if a new file is written out due to the
scheme in 1) -- in this case /etc/ietd.conf.3 -- those changes will be used
when ietd is restarted.
==========================================================
Testing:

Unit testing was pretty straightforward.  Visually inspected and verified all parameters
were transferred to the new config file, used ietd afterwards -- couple hundered megabytes,
seems stable.  Kind of meager still though.
==========================================================
Notes:

1)  defining OfMarkInt in the configuration file will cause ietd instability, therefore,
this parameter is written but commented.

2)  this scheme could to lead to a large number of files in /etc/.  Suggest that we
should instead use a directory /etc/ietd/ietd.conf as the default.

3)  Need some help with merging in the changes if they are adopted -- first time-er here.

4)  Mods were made against .4.16 + Arne Redlich's chap patch, not trunk (see #3),
so some additional changes need to be done, I'm sure.

5) Currenty the following previously hidden (statically defined in plain.c) information
is now exposed.

struct user
struct qelem *account_list_get(u32 tid, int dir);

Further, I'm lobbying right now for following target.c's example, and pull it all of out plain.c
and create a new file user.c.  I BTW did this with LUNs and made lun.c  Currently, it's
all still in plain.c
==========================================================


Well that's pretty good for an intro... comments?

-Jeff

[rswwalker]

Jeff,

We welcome all submissions, but please send these to the list as inlined patches ('svn diff' the easiest).

The subject should have some identifying tag like [PATCH 0/3] ietd persistent db, that shows it's a patch, how many parts it will be in, and what it's overall purpose is.

The body should simple state what the patchset and each individual patch in return does. After that the apropriate diff should be inlined.

Each part should be kept as short as possible for readability and if possible should allow IET to compile and run successfully if only that part were committed without it's others.

Please, plain text ASCII only, make sure your MUA/MTA doesn't wrap it.

-Ross


----- Original Message -----
From: iscsitarget-devel-bounces@... <iscsitarget-devel-bounces@...>
To: iscsitarget-devel@... <iscsitarget-devel@...>
Sent: Fri Jul 04 14:51:36 2008
Subject: [Iscsitarget-devel]  Beta for online database storage ready (RFC)


See "Online target database?" thread for info.  Following up from that
thread, I've
made the following changes, and require some feedback (see below).

==========================================================
1) Updated ietadm and the ietd<--->ietadm protocol to allow a --sync option.
If present,
this will cause ietd to first perform the changes specified by the other
operator
present on the command line for ietadm, and then after those changes are
complete
will write our a new configuration file named basename.x where:

basename is the name of the configuration file ietd was invoked with (e.g.
/etc/ietd.conf).
x is a number extending the filename.

So if ietd was started with /etc/ietd.conf, the new configuration file would
be named
/etc/ietd.conf.1.

Added support in the daemon to fetch all the parameters necessary for
reconstructing
the configuration file:
        targets
        target parameters
        users
        luns
        isns server information

2)  Modified ietd to prefer using a configuration file with the highest
value extension
number (see above) for obtaining its startup information when it first
starts.  So
for example if there are files /etc/ietd.conf /etc/ietd/conf.1
/etc/ietd/conf.2,  ietd
will use /etc/ietd.conf.2.  The idea being that if a new file is written out
due to the
scheme in 1) -- in this case /etc/ietd.conf.3 -- those changes will be used
when ietd is restarted.
==========================================================
Testing:

Unit testing was pretty straightforward.  Visually inspected and verified
all parameters
were transferred to the new config file, used ietd afterwards -- couple
hundered megabytes,
seems stable.  Kind of meager still though.
==========================================================
Notes:

1)  defining OfMarkInt in the configuration file will cause ietd
instability, therefore,
this parameter is written but commented.

2)  this scheme could to lead to a large number of files in /etc/.  Suggest
that we
should instead use a directory /etc/ietd/ietd.conf as the default.

3)  Need some help with merging in the changes if they are adopted -- first
time-er here.

4)  Mods were made against .4.16 + Arne Redlich's chap patch, not trunk (see
#3),
so some additional changes need to be done, I'm sure.

5) Currenty the following previously hidden (statically defined in plain.c)
information
is now exposed.

struct user
struct qelem *account_list_get(u32 tid, int dir);

Further, I'm lobbying right now for following target.c's example, and pull
it all of out plain.c
and create a new file user.c.  I BTW did this with LUNs and made lun.c
Currently, it's
all still in plain.c
==========================================================


Well that's pretty good for an intro... comments?

-Jeff

--
View this message in context: http://www.nabble.com/Beta-for-online-database-storage-ready-%28RFC%29-tp18284477p18284477.html
Sent from the iscsitarget-devel mailing list archive at Nabble.com.


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

---

This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Jeff Waller]

Good info, thanks Ross,

On Jul 5, 2008, at 10:33 AM, Ross S. W. Walker wrote:

Jeff,

We welcome all submissions, but please send these to the list as inlined patches ('svn diff' the easiest).

Yep, took me a while, but I have that now.

The subject should have some identifying tag like [PATCH 0/3] ietd persistent db, that shows it's a patch, how many parts it will be in, and what it's overall purpose is.

Yep will do.

The body should simple state what the patchset and each individual patch in return does. After that the apropriate diff should be inlined.

Each part should be kept as short as possible for readability and if possible should allow IET to compile and run successfully if only that part were committed without it's others.

Hmm, well I need some clarification.  Are you looking for 1 part per file  or 1 part could

potentially contain multiple changes to multiple files (all the patches concatenated).  I hope

it's the latter.  In this case there are going to be 10 interrelated files.  With 1 trivial exception

they really all need to come together.

Please, plain text ASCII only, make sure your MUA/MTA doesn't wrap it.

Also a potential problem as my primary email client is the default OS X one, but

I'll test first before I try to send.

-Jeff

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[dlambert_bmt]

You wrote:

> 1) Updated ietadm and the ietd<--->ietadm protocol to allow a --sync
option.  If present, this will cause ietd to first perform the changes
specified by the other operator present on the command line for ietadm,
and then after those changes are complete will write our a new
configuration file named basename.x where:

> basename is the name of the configuration file ietd was invoked with
(e.g.
/etc/ietd.conf).
> x is a number extending the filename. [...]

> 2)  Modified ietd to prefer using a configuration file with the
highest
value extension number (see above) [...]

This sounds confusingly similar to, but not quite the same as, the way
Emacs and other GNU utilities perform "numbered" backups.  I'd suggest
instead naming the old file "ietd.conf.~admX" or "ietd.conf.~autoX",
where X is the next available number, and writing the new file as
"ietd.conf". That way someone (or another utility) looking for the
current file won't have to do a scan of all possible names, but only
someone trying to track down a problem.

--

David Lee Lambert
Software Developer, Precision Motor Transport Group, LLC
517-349-3011 x223 (work) ... 586-873-8813 (cell)

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Jeff Waller]

On Jul 7, 2008, at 8:51 AM, David L. Lambert wrote:

> You wrote:
>
>> 1) Updated ietadm and the ietd<--->ietadm protocol to allow a --sync
> option.  If present, this will cause ietd to first perform the changes
> specified by the other operator present on the command line for  
> ietadm,
> and then after those changes are complete will write our a new
> configuration file named basename.x where:
>
>> basename is the name of the configuration file ietd was invoked with
> (e.g.
> /etc/ietd.conf).
>> x is a number extending the filename. [...]
>
>> 2)  Modified ietd to prefer using a configuration file with the
> highest
> value extension number (see above) [...]
>
> This sounds confusingly similar to, but not quite the same as, the way
> Emacs and other GNU utilities perform "numbered" backups.  I'd suggest
> instead naming the old file "ietd.conf.~admX" or "ietd.conf.~autoX",
> where X is the next available number, and writing the new file as
> "ietd.conf". That way someone (or another utility) looking for the
> current file won't have to do a scan of all possible names, but only
> someone trying to track down a problem.

Hmm how about a symbolic link?  After the update write is successful,
link /etc/ietd-backups/ietd.conf.x /etc/ietd.conf,  Program always
starts against /etc/ietd.conf (as before).

-Jeff


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Arne Redlich-2]

Am Freitag, den 04.07.2008, 11:51 -0700 schrieb Jeff Waller:

> See "Online target database?" thread for info.  Following up from that
> thread, I've
> made the following changes, and require some feedback (see below).
>
> ==========================================================
> 1) Updated ietadm and the ietd<--->ietadm protocol to allow a --sync option.
> If present,
> this will cause ietd to first perform the changes specified by the other
> operator
> present on the command line for ietadm, and then after those changes are
> complete
> will write our a new configuration file named basename.x where:
>
> basename is the name of the configuration file ietd was invoked with (e.g.
> /etc/ietd.conf).
> x is a number extending the filename.
>
> So if ietd was started with /etc/ietd.conf, the new configuration file would
> be named
> /etc/ietd.conf.1.

Why? And the next update will generate ietd.conf.2?
Why not simply add a --outfile option?

Arne


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Jeff Waller]

On Jul 7, 2008, at 12:49 PM, Arne Redlich wrote:

> Am Freitag, den 04.07.2008, 11:51 -0700 schrieb Jeff Waller:
>> See "Online target database?" thread for info.  Following up from  
>> that
>> thread, I've
>> made the following changes, and require some feedback (see below).
>>
>> ==========================================================
>> 1) Updated ietadm and the ietd<--->ietadm protocol to allow a --
>> sync option.
>> If present,
>> this will cause ietd to first perform the changes specified by the  
>> other
>> operator
>> present on the command line for ietadm, and then after those  
>> changes are
>> complete
>> will write our a new configuration file named basename.x where:
>>
>> basename is the name of the configuration file ietd was invoked  
>> with (e.g.
>> /etc/ietd.conf).
>> x is a number extending the filename.
>>
>> So if ietd was started with /etc/ietd.conf, the new configuration  
>> file would
>> be named
>> /etc/ietd.conf.1.
>
> Why? And the next update will generate ietd.conf.2?

Yes.  Each synchronized update generates a new file with the next higher
extension number.

> Why not simply add a --outfile option?

I'm guessing at this question, I think the question is why not augment
ietadm and the protocol to allow for a means of what the output file
should be named.  I'm  opposed to exporting administrative control of
filenames to ietadm.  In other words, IMHO, all ietd should tell ietadm
is "it's stored" and by design avoid revealing any details of how it  
did so.

-Jeff


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Arne Redlich-2]

Am Montag, den 07.07.2008, 15:10 -0400 schrieb Jeff Waller:
> On Jul 7, 2008, at 12:49 PM, Arne Redlich wrote:

> >
> > Why? And the next update will generate ietd.conf.2?
>
> Yes.  Each synchronized update generates a new file with the next higher
> extension number.
>
> > Why not simply add a --outfile option?
>
> I'm guessing at this question, I think the question is why not augment
> ietadm and the protocol to allow for a means of what the output file
> should be named.  I'm  opposed to exporting administrative control of
> filenames to ietadm.  In other words, IMHO, all ietd should tell ietadm
> is "it's stored" and by design avoid revealing any details of how it  
> did so.

And /etc is spammed with files that are unlikely to be ever looked at
again? Sorry, but no thanks.

I think going with the *nix philosophy of offering building blocks than
can be used flexibly is vastly preferable in this case. You could then
use these building blocks (yes, specifying the outfile with ietadm or
letting it write it in ietd.conf format to stdout) e.g. for your above
scheme if that makes you happy.

Arne


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[rswwalker]

Arne Redlich wrote:

> Am Montag, den 07.07.2008, 15:10 -0400 schrieb Jeff Waller:
> > On Jul 7, 2008, at 12:49 PM, Arne Redlich wrote:
>
> > >
> > > Why? And the next update will generate ietd.conf.2?
> >
> > Yes.  Each synchronized update generates a new file with the next higher
> > extension number.
> >
> > > Why not simply add a --outfile option?
> >
> > I'm guessing at this question, I think the question is why not augment
> > ietadm and the protocol to allow for a means of what the output file
> > should be named.  I'm  opposed to exporting administrative control of
> > filenames to ietadm.  In other words, IMHO, all ietd should tell ietadm
> > is "it's stored" and by design avoid revealing any details of how it  
> > did so.
>
> And /etc is spammed with files that are unlikely to be ever looked at
> again? Sorry, but no thanks.
>
> I think going with the *nix philosophy of offering building blocks than
> can be used flexibly is vastly preferable in this case. You could then
> use these building blocks (yes, specifying the outfile with ietadm or
> letting it write it in ietd.conf format to stdout) e.g. for your above
> scheme if that makes you happy.

I have to agree with Arne here, not only is this friendlier to /etc's
contents, but it is friendlier to OEM/VAR implementations like
OpenFiler which want to control where all of this is written.

Have an --outfile --output --dump whatever option in ietadm that just
dumps the running config in ietd.conf format to stdout. Easy, not
complex and allows for extension through stacking.

If you go this route it might also pay to add the ability to ietd to
read it's config through stdin as well. Either by command line options,
by detecting the presence of stdin through shell redirection '<' or
the passing of '-' parameter to the '-c' option (or all of the above!).

Put a 3 patch patchset together,

1) Fully implement ietd/ietadm protocol interface for all running
parameters.

2) Implement ability of ietadm to output running config in ietd.conf
format to stdout

3) Implement ability of ietd to read it's configuration through
stdin.

After this patchset you can look at developing a second patchset
to have ietd process signals for re-reading ietd.conf, a soft
signal to handle non-destructive changes and a hard signal to
process destructive changes that would require a full reset and
possibly a friendlier way to signal to initiators that the
targets/luns are temporarily unavailable (though preventing
the port-unreachable icmp packet will make sure initiators
that don't support these SCSI messages still hang on).

-Ross

______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Jeff Waller]

On Jul 7, 2008, at 3:23 PM, Arne Redlich wrote:

> Am Montag, den 07.07.2008, 15:10 -0400 schrieb Jeff Waller:
>> On Jul 7, 2008, at 12:49 PM, Arne Redlich wrote:
>
>>>
>>> Why? And the next update will generate ietd.conf.2?
>>
>> Yes.  Each synchronized update generates a new file with the next  
>> higher
>> extension number.
>>
>>> Why not simply add a --outfile option?
>>
>> I'm guessing at this question, I think the question is why not  
>> augment
>> ietadm and the protocol to allow for a means of what the output file
>> should be named.  I'm  opposed to exporting administrative control of
>> filenames to ietadm.  In other words, IMHO, all ietd should tell  
>> ietadm
>> is "it's stored" and by design avoid revealing any details of how it
>> did so.
>
> And /etc is spammed with files that are unlikely to be ever looked at
> again? Sorry, but no thanks.

Yes this is the outcome with the current naming scheme.  A bad side
effect and the reason for my comment that we would use a directory
instead.

> I think going with the *nix philosophy of offering building blocks  
> than
> can be used flexibly is vastly preferable in this case. You could then
> use these building blocks (yes, specifying the outfile with ietadm or
> letting it write it in ietd.conf format to stdout) e.g. for your above
> scheme if that makes you happy.

Is this turning into the merits of vi versus emacs argument?

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Arne Redlich-2]

Am Montag, den 07.07.2008, 15:53 -0400 schrieb Jeff Waller:
> On Jul 7, 2008, at 3:23 PM, Arne Redlich wrote:

> > I think going with the *nix philosophy of offering building blocks  
> > than
> > can be used flexibly is vastly preferable in this case. You could then
> > use these building blocks (yes, specifying the outfile with ietadm or
> > letting it write it in ietd.conf format to stdout) e.g. for your above
> > scheme if that makes you happy.
>
> Is this turning into the merits of vi versus emacs argument?

No. Once more, it's just about flexibility. As I pointed out, your usage
scheme is just a subset that can be easily implemented if desired, but,
as Ross pointed out, other users might have (completely!) different
requirements, so it's best not to enforce a single policy.

And everyone should know by now that emacs is the one true editor.

Cheers,
Arne


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[rswwalker]

Arne Redlich wrote:

> Am Montag, den 07.07.2008, 15:53 -0400 schrieb Jeff Waller:
> > On Jul 7, 2008, at 3:23 PM, Arne Redlich wrote:
>
> > > I think going with the *nix philosophy of offering building blocks  
> > > than can be used flexibly is vastly preferable in this case.
> > > You could then use these building blocks (yes, specifying the
> > > outfile with ietadm or letting it write it in ietd.conf format to
> > > stdout) e.g. for your above scheme if that makes you happy.
> >
> > Is this turning into the merits of vi versus emacs argument?
>
> No. Once more, it's just about flexibility. As I pointed out,
> your usage scheme is just a subset that can be easily implemented
> if desired, but, as Ross pointed out, other users might have
> (completely!) different requirements, so it's best not to enforce
> a single policy.
>
> And everyone should know by now that emacs is the one true editor.

Sometimes all you need is an editor, and that's what :1,$s/emacs/vi/
is for!

-Ross

______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Arne Redlich-2]

Am Montag, den 07.07.2008, 15:51 -0400 schrieb Ross S. W. Walker:
> Arne Redlich wrote:
>
> > Am Montag, den 07.07.2008, 15:10 -0400 schrieb Jeff Waller:
> > > On Jul 7, 2008, at 12:49 PM, Arne Redlich wrote:

> If you go this route it might also pay to add the ability to ietd to
> read it's config through stdin as well. Either by command line options,
> by detecting the presence of stdin through shell redirection '<' or
> the passing of '-' parameter to the '-c' option (or all of the above!).

This does not work with a daemonized process that disconnects from its
terminal and closes std{in,out,err} usually quite early during the
startup, and in particular before parsing the config file.

It could certainly be done when running in foreground mode though, but
this is usually only done for debugging.

HTH,
Arne


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Arne Redlich-2]

Am Montag, den 07.07.2008, 16:08 -0400 schrieb Ross S. W. Walker:

> Arne Redlich wrote:
>
> > Am Montag, den 07.07.2008, 15:53 -0400 schrieb Jeff Waller:
> > > On Jul 7, 2008, at 3:23 PM, Arne Redlich wrote:
> >
> > > > I think going with the *nix philosophy of offering building blocks  
> > > > than can be used flexibly is vastly preferable in this case.
> > > > You could then use these building blocks (yes, specifying the
> > > > outfile with ietadm or letting it write it in ietd.conf format to
> > > > stdout) e.g. for your above scheme if that makes you happy.
> > >
> > > Is this turning into the merits of vi versus emacs argument?
> >
> > No. Once more, it's just about flexibility. As I pointed out,
> > your usage scheme is just a subset that can be easily implemented
> > if desired, but, as Ross pointed out, other users might have
> > (completely!) different requirements, so it's best not to enforce
> > a single policy.
> >
> > And everyone should know by now that emacs is the one true editor.
>
> Sometimes all you need is an editor, and that's what :1,$s/emacs/vi/
> is for!

Why would I want to start a vi from the terminal running inside my
emacs? :D

Cheers,
Arne


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[rswwalker]

Arne Redlich wrote:

> Am Montag, den 07.07.2008, 15:51 -0400 schrieb Ross S. W. Walker:
> > Arne Redlich wrote:
> >
> > > Am Montag, den 07.07.2008, 15:10 -0400 schrieb Jeff Waller:
> > > > On Jul 7, 2008, at 12:49 PM, Arne Redlich wrote:
>
> > If you go this route it might also pay to add the ability to ietd to
> > read it's config through stdin as well. Either by command line options,
> > by detecting the presence of stdin through shell redirection '<' or
> > the passing of '-' parameter to the '-c' option (or all of the above!).
>
> This does not work with a daemonized process that disconnects from its
> terminal and closes std{in,out,err} usually quite early during the
> startup, and in particular before parsing the config file.
>
> It could certainly be done when running in foreground mode though, but
> this is usually only done for debugging.

I forgot about that, it could conceivably do so as it's last act on
stdin before it closes it though, but I suppose the usefulness is
limited given that it's a one-shot pony in reality.

Conceivably one could opt to run ietd in foreground on a virtual
terminal if it were implemented as an appliance where even syslog
might not be available. In that case it may be a useful feature
especially if the configuration isn't stored in ietd.conf at all
but some proprietary web management app or in a proprietary
database format, or imported from ldap on each start which may
be a preferred method if one had a large farm of iSCSI target
servers to manage.

-Ross

______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel