Online target database?

View: New views
12 Messages — Rating Filter:   Alert me  

Online target database?

by Jeff Waller :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Reading the man page of ietadm, I find that ietadm will change the state of the iet daemon, but
that information will not be persistent.  It's one of the known issues.

Searching the archive, there's been a couple of suggestions along these lines, but has there been
anything concretely done?  Has there been any discussion about making the daemon use a more
online database (e.g. dbm) and it being the conduit for ietadm modifying that?  

-Jeff

Re: Online target database?

by Marcel Ritter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Jeff Waller schrieb:

> Reading the man page of ietadm, I find that ietadm will change the state of
> the iet daemon, but
> that information will not be persistent.  It's one of the known issues.
>
> Searching the archive, there's been a couple of suggestions along these
> lines, but has there been
> anything concretely done?  Has there been any discussion about making the
> daemon use a more
> online database (e.g. dbm) and it being the conduit for ietadm modifying
> that?  
>
> -Jeff
>  
Hi Jeff,

I've started to implement this, but it's not finished yet. However I
don't like
the idea of databases to store this information. open-iscsi for example uses
the god old unix fashion "everything is a file" -  and stores all
information
in nice little plain text files (everyone can edit with his favourite
vi/emacs/whatever).
So that's the way I'm doing it.

As most users on linux will use open-iscsi as initiator (and iscsitarget
as target),
I think it's nice to have a similar way to configure iscsi on both sides.

For now you'll have to create 3 extra directories in order to make this
version work:

/etc/ietd.d/
/etc/ietd.d/targets
/etc/ietd.d/tids

What I've done so far:
- Added code to save changed settings
   * users
   * targets
   * luns
   * global settings: only partially

Still to do:
- clean up global option parsing/handling
- read config files to restore iscsi settings on restart
- cleanups ...
- lots more (I guess)

I've attached the patch - but please consider this work in progress.

Bye,
    Marcel

--
----
Dipl.-Inf. Marcel Ritter
Linux/Novell
Regionales Rechenzentrum Erlangen
Tel: 09131 / 85-27808
E-Mail: Marcel.Ritter@...
----
Unix _IS_ user friendly... It's just selective about who its friends are.



diff -Nur iscsitarget-0.4.16.orig/usr/iscsid.h iscsitarget-0.4.16/usr/iscsid.h
--- iscsitarget-0.4.16.orig/usr/iscsid.h 2008-03-18 07:41:02.000000000 +0100
+++ iscsitarget-0.4.16/usr/iscsid.h 2008-06-17 13:04:16.000000000 +0200
@@ -125,6 +125,7 @@
  struct qelem tlist;
 
  struct qelem sessions_list;
+ struct qelem lun_list;
 
  u32 tid;
  char name[ISCSI_NAME_LEN];
diff -Nur iscsitarget-0.4.16.orig/usr/lun.c iscsitarget-0.4.16/usr/lun.c
--- iscsitarget-0.4.16.orig/usr/lun.c 1970-01-01 01:00:00.000000000 +0100
+++ iscsitarget-0.4.16/usr/lun.c 2008-06-17 13:04:16.000000000 +0200
@@ -0,0 +1,172 @@
+/*
+ * Released under the terms of the GNU GPL v2.0.
+ */
+
+#include <ctype.h>
+#include <dirent.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+#include <sys/stat.h>
+#include <errno.h>
+
+#include "iscsid.h"
+#include "lun.h"
+
+
+struct match_table_t iomode[] = {
+ {Mode_fileio, "fileio"},
+ {Mode_blockio, "blockio"},
+ {Mode_nullio, "nullio"},
+ {Mode_unknownio,  NULL},
+};
+
+struct match_table_t tokens[] = {
+        {Opt_scsiid, "ScsiId="},
+        {Opt_scsisn, "ScsiSN="},
+        {Opt_path, "Path="},
+        {Opt_type, "Type="},
+        {Opt_iomode, "IOMode="},
+        {Opt_err, NULL},
+};
+
+struct qelem luns = LIST_HEAD_INIT(luns);
+
+
+int is_token(char *tokenstr)
+{
+ int i;
+
+ for (i=0; i<Opt_err; i++)
+ if (strncmp(tokenstr, tokens[i].tokenstr,strlen(tokens[i].tokenstr)) == 0)
+ return i;
+ return -1;
+}
+
+char* get_token_value(char *tokenstr)
+{
+ char *sep;
+
+ sep = index(tokenstr, '=');
+ if (sep)
+ sep += 1;
+ return(sep);
+}
+
+struct lun* parse_lun_args(char *args, struct lun *newlun)
+{
+ char *argcopy, *end, *val;
+ int start=0, tok;
+ int arglen = strlen(args);
+ int i, len;
+
+ argcopy = malloc(arglen+1);
+ strncpy(argcopy, args, arglen+1);
+
+ log_debug(1, "parse_lun_args: %s", args);
+ while (start < arglen) {
+ if ((end = index(argcopy+start, ','))==NULL)
+ end = argcopy+arglen;
+ else
+ *end = '\0';
+ if (start < arglen) {
+ log_debug(1, " arg: %s", argcopy+start);
+ if ((tok = is_token(argcopy+start)) >= 0) {
+ log_debug(1, "Detected: %s", tokens[tok].tokenstr);
+ val = get_token_value(argcopy+start);
+ log_debug(1, "%s", val);
+ switch(tok) {
+ case(Opt_scsiid):
+ len = (SCSI_ID_LEN > strlen(val)) ? strlen(val) : SCSI_ID_LEN;
+ strncpy(newlun->scsiid, val, len+1);
+ break;
+ case(Opt_scsisn):
+ len = (SCSI_SN_LEN > strlen(val)) ? strlen(val) : SCSI_SN_LEN;
+ strncpy(newlun->scsisn, val, len+1);
+ break;
+ case(Opt_path):
+ len = (sizeof(newlun->path) > strlen(val)) ? strlen(val)+1 : sizeof(newlun->path);
+ strncpy(newlun->path, val, len);
+ break;
+ case(Opt_type):
+ i = 0;
+ while (iomode[i].tokenstr) {
+ if (strncmp(val, iomode[i].tokenstr, strlen(iomode[i].tokenstr) ==0)) {
+ newlun->type = i;
+ }
+ i++;
+ }
+ break;
+ case(Opt_iomode):
+ newlun->iomode = 0;
+ break;
+ case(Opt_err):
+ break;
+ }
+ }
+ start=end-argcopy+1;
+ }
+ }
+
+ free(argcopy);
+ return(newlun);
+}
+
+struct lun *lun_create(u32 tid, u32 lunno, char *args)
+{
+ struct lun *lun;
+ struct target *target = target_find_by_id(tid);
+
+ if (!target)
+ return NULL;
+ if (!(lun = malloc(sizeof(*lun))))
+ return NULL;
+ memset(lun, 0, sizeof(*lun));
+
+ INIT_LIST_HEAD(&lun->lunlist);
+ lun = parse_lun_args(args, lun);
+ lun->no = lunno;
+ insque(&lun->lunlist, &target->lun_list);
+
+ return lun;
+}
+
+void lun_destroy(u32 tid, u32 lun)
+{
+ struct lun *dellun = NULL;
+ struct target *target = target_find_by_id(tid);
+
+ list_for_each_entry(dellun, &target->lun_list, lunlist) {
+ if (lun == dellun->no)
+ break;
+ }
+ if (!dellun)
+ return;
+
+ remque(&dellun->lunlist);
+ free(dellun);
+}
+
+void write_lun(struct lun *l, FILE *fp)
+{
+ fprintf(fp, "\tLun %d %s%s,", l->no, tokens[Opt_path].tokenstr, l->path);
+ fprintf(fp, "%s=%s,", tokens[Opt_type].tokenstr, iomode[l->type].tokenstr);
+ fprintf(fp, "%s%s,", tokens[Opt_scsiid].tokenstr, l->scsiid);
+ fprintf(fp, "%s%s\n", tokens[Opt_scsisn].tokenstr, l->scsisn);
+}
+
+int write_lun_list(u32 tid, FILE *fp)
+{
+ struct lun *llun = NULL;
+ struct target *target = target_find_by_id(tid);
+
+ if (!target)
+ return -1;
+
+ list_for_each_entry(llun, &target->lun_list, lunlist) {
+ write_lun(llun, fp);
+ }
+ return 0;
+}
diff -Nur iscsitarget-0.4.16.orig/usr/lun.h iscsitarget-0.4.16/usr/lun.h
--- iscsitarget-0.4.16.orig/usr/lun.h 1970-01-01 01:00:00.000000000 +0100
+++ iscsitarget-0.4.16/usr/lun.h 2008-06-17 13:04:16.000000000 +0200
@@ -0,0 +1,44 @@
+#ifndef LUN_H
+#define LUN_H
+
+/*
+ * LUN configuration code
+ */
+
+struct match_table_t {
+ int tokenno;
+ char *tokenstr;
+};
+
+enum {
+ Mode_fileio, Mode_blockio, Mode_nullio, Mode_unknownio,
+};
+
+
+enum {
+        Opt_scsiid, Opt_scsisn, Opt_path, Opt_type, Opt_iomode, Opt_err,
+};
+
+struct lun {
+ u32 no;
+ struct qelem lunlist;
+
+ char scsisn[SCSI_SN_LEN+1];
+ char scsiid[SCSI_ID_LEN+1];
+ char path[2048];
+ u32 type;
+ u32 iomode;
+};
+
+extern struct match_table_t iomode[];
+extern struct match_table_t tokens[];
+extern struct qelem luns;
+
+extern struct lun *lun_alloc(u32 tid);
+extern struct lun *lun_create(u32 tid, u32 lunno, char *args);
+extern void lun_destroy(u32 tid, u32 lun);
+extern void write_lun(struct lun *l, FILE *fp);
+extern int write_lun_list(u32 tid, FILE *fp);
+
+
+#endif
diff -Nur iscsitarget-0.4.16.orig/usr/Makefile iscsitarget-0.4.16/usr/Makefile
--- iscsitarget-0.4.16.orig/usr/Makefile 2008-03-18 07:41:02.000000000 +0100
+++ iscsitarget-0.4.16/usr/Makefile 2008-06-17 13:04:16.000000000 +0200
@@ -4,7 +4,7 @@
 
 all: $(PROGRAMS)
 
-ietd: ietd.o iscsid.o conn.o session.o target.o message.o ctldev.o log.o chap.o event.o param.o plain.o isns.o
+ietd: ietd.o iscsid.o conn.o session.o target.o message.o ctldev.o log.o chap.o event.o param.o plain.o isns.o lun.o
 
  $(CC) $^ -o $@ $(LIBS)
 
diff -Nur iscsitarget-0.4.16.orig/usr/plain.c iscsitarget-0.4.16/usr/plain.c
--- iscsitarget-0.4.16.orig/usr/plain.c 2008-03-18 07:41:02.000000000 +0100
+++ iscsitarget-0.4.16/usr/plain.c 2008-06-19 08:29:04.000000000 +0200
@@ -12,6 +12,7 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
+#include <unistd.h>
 #include <sys/stat.h>
 #include <sys/socket.h>
 
@@ -21,11 +22,24 @@
 #include <arpa/inet.h>
 
 #include "iscsid.h"
+#include "ietadm.h"
+#include "lun.h"
 
 #define BUFSIZE 4096
 #define CONFIG_FILE "/etc/ietd.conf"
+#define CONFIG_DIR "/etc/ietd.d"
+#define CONFIGTID_DIR "/etc/ietd.d/tids/"
+#define CONFIGTGT_DIR "/etc/ietd.d/targets/"
+#define GLOBAL_FILE "/etc/ietd.d/globals.conf"
+
 #define ACCT_CONFIG_FILE CONFIG_FILE
 
+
+static char *target_configfile(char *);
+static char *tid_link(u32);
+static int write_user_list(u32, FILE *);
+static int write_target_file(u32);
+
 /*
  * Account configuration code
  */
@@ -71,6 +85,7 @@
 static struct qelem trgt_acct_in[1 << HASH_ORDER];
 static struct qelem trgt_acct_out[1 << HASH_ORDER];
 
+
 static struct qelem *account_list_get(u32 tid, int dir)
 {
  struct qelem *list = NULL;
@@ -113,7 +128,7 @@
  pass = target_sep_string(&q);
 
  if (cops->account_add(tid, idx, name, pass) < 0)
- fprintf(stderr, "%s %s\n", name, pass);
+ log_debug(1, "%s %s", name, pass);
  }
  }
 
@@ -129,7 +144,7 @@
  struct user *user = NULL;
 
  list_for_each_entry(user, list, ulist) {
- fprintf(stderr, "%u %s %s\n", user->tid, user->password, user->name);
+ log_debug(1, "%u %s %s", user->tid, user->password, user->name);
  if (user->tid != tid)
  continue;
  if (!strlen(name))
@@ -176,6 +191,9 @@
  account_destroy(user);
 
  /* update the file here. */
+ log_debug(1, "plain_account_del");
+ write_target_file(tid);
+
  return 0;
 }
 
@@ -227,6 +245,9 @@
  insque(user, list);
 
  /* update the file here. */
+ log_debug(1, "plain_account_add");
+ write_target_file(tid);
+
  return 0;
 out:
  account_destroy(user);
@@ -428,8 +449,11 @@
  if ((err = target_add(tid, name)) < 0)
  return err;
 
- if (update)
- ; /* Update the config file here. */
+ if (update) {
+ log_debug(1, "__plain_target_create: update=true");
+ write_target_file(*tid);
+ } else
+ log_debug(1, "__plain_target_create: update=false");
 
  return err;
 }
@@ -442,11 +466,32 @@
 static int plain_target_destroy(u32 tid)
 {
  int err;
-
- if ((err = target_del(tid)) < 0)
+        struct target *target;
+ char *cfname = NULL;
+ char *tlink;
+
+        list_for_each_entry(target, &targets_list, tlist)
+                if (target->tid == tid)
+ cfname = target_configfile(target->name);
+
+ if ((err = target_del(tid)) < 0) {
+ if (cfname)
+ free(cfname);
  return err;
+ }
 
  /* Update the config file here. */
+ if (cfname) {
+ if (unlink(cfname) == -1)
+ log_warning("unlink(): %s: %s", strerror(errno), cfname);
+ free(cfname);
+ /* remove link */
+ tlink = tid_link(tid);
+ if (unlink(tlink) == -1)
+ log_warning("unlink(): %s: %s", strerror(errno), tlink);
+ free(tlink);
+ }
+
  return err;
 }
 
@@ -457,8 +502,16 @@
  if ((err = ki->lunit_create(tid, lun, args)) < 0)
  return err;
 
- if (update)
- ;
+ if (update) {
+ log_debug(1, "__plain_lunit_create: update=true");
+ lun_create(tid, lun, args);
+ write_lun_list(tid, stderr);
+ write_target_file(tid);
+ } else {
+ log_debug(1, "__plain_lunit_create: update=false");
+ lun_create(tid, lun, args);
+ write_target_file(tid);
+ }
 
  return err;
 }
@@ -470,7 +523,15 @@
 
 static int plain_lunit_destroy(u32 tid, u32 lun)
 {
- return ki->lunit_destroy(tid, lun);
+ int err;
+
+ if ((err = ki->lunit_destroy(tid, lun)) < 0)
+ return err;
+
+ lun_destroy(tid, lun);
+ write_target_file(tid);
+
+ return err;
 }
 
 static int __plain_param_set(u32 tid, u64 sid, int type,
@@ -482,7 +543,10 @@
  return err;
 
  if (update)
- ;
+ log_debug(1, "__plain_param_set: update=true");
+ else
+ log_debug(1, "__plain_param_set: update=false");
+
 
  return err;
 }
@@ -516,7 +580,11 @@
  char *p, *q;
  int idx;
  u32 tid, val;
+ FILE *fp;
 
+ /*
+ FIXME: loop over all config files (starting with global.conf)
+ */
  if (!(config = fopen(filename, "r")))
  return -errno;
 
@@ -555,6 +623,15 @@
  }
 
  fclose(config);
+
+ if (!(fp = fopen(GLOBAL_FILE, "w"))) {
+ log_error("fopen(): %s - %s", strerror(errno), GLOBAL_FILE);
+ return -EIO;
+ }
+
+ write_user_list(0, fp);
+ fclose(fp);
+
  return 0;
 }
 
@@ -606,6 +683,137 @@
  return 0;
 }
 
+static int write_user_list(u32 tid, FILE *fp)
+{
+ struct user *user = NULL;
+ struct qelem *list = NULL;
+
+ fprintf(fp, "\t# User settings\n");
+ list = account_list_get(tid, AUTH_DIR_INCOMING);
+ list_for_each_entry(user, list, ulist)
+ fprintf(fp, "\t%s %s %s\n", user_keys[AUTH_DIR_INCOMING].name, user->name, user->password);
+ list = account_list_get(tid, AUTH_DIR_OUTGOING);
+ list_for_each_entry(user, list, ulist)
+ fprintf(fp, "\t%s %s %s\n", user_keys[AUTH_DIR_OUTGOING].name, user->name, user->password);
+ return 0;
+}
+
+
+static char *tid_link(u32 tid)
+{
+ char *tidlink;
+ int len = strlen(CONFIGTID_DIR)+strlen("4294967296")+2;
+
+ tidlink = malloc(len);
+ snprintf(tidlink, len, "%s/%d", CONFIGTID_DIR, tid);
+
+ return(tidlink);
+}
+
+static char *target_configfile(char *targetname)
+{
+ char *targetcf;
+ int len = strlen(CONFIGTGT_DIR)+strlen(targetname)+2;
+
+ targetcf = malloc(len);
+ snprintf(targetcf, len, "%s/%s", CONFIGTGT_DIR, targetname);
+
+ return(targetcf);
+}
+
+static int write_target_file(u32 tid)
+{
+        struct target *target;
+ struct iscsi_param target_param[target_key_last];
+ struct iscsi_param session_param[session_key_last];
+ char *targetcf, *tlink;
+ FILE *fp;
+        char buf[1024], *p;
+ int i;
+
+ if (!tid) {
+ /* open target config file */
+ if (!(fp = fopen(GLOBAL_FILE, "w"))) {
+ return -EIO;
+ }
+
+ /*
+ if (*isns)
+ fprintf(fp, "iSNSServer %s\n", isns);
+ if (*isns_ac)
+ fprintf(fp, "iSNSAccessControl Yes\n");
+ else
+ fprintf(fp, "iSNSAccessControl No\n");
+ */
+ write_user_list(tid, fp);
+ fclose(fp);
+ } else {
+         list_for_each_entry(target, &targets_list, tlist) {
+                if (target->tid == tid) {
+ /* construct file name */
+ targetcf = target_configfile(target->name);
+
+ /* open target config file */
+ if (!(fp = fopen(targetcf, "w"))) {
+ log_error("fopen(): %s - %s", strerror(errno), targetcf);
+ free(targetcf);
+ return -EIO;
+ }
+ /* create link */
+ tlink = tid_link(tid);
+ /* FIXME: relative link ? */
+ if (symlink (targetcf, tlink) == -1)
+ log_warning("symlink(): %s - %s", strerror(errno), tlink);
+ free(tlink);
+
+ /* target name */
+ fprintf(fp, "Target %s\n", target->name);
+
+ /* user list */
+ write_user_list(tid, fp);
+
+ /* target list */
+                 fprintf(fp, "\t# Target settings\n");
+ memset(&target_param, 0, sizeof(target_param));
+                 ki->param_get(tid, 0, key_target,
+ target_param);
+ for (i = 0; i < target_key_last; i++) {
+                 memset(buf, 0, sizeof(buf));
+                 strcpy(buf, target_keys[i].name);
+                 p = buf + strlen(buf);
+                 *p++ = ' ';
+                 param_val_to_str(target_keys, i, target_param[i].val, p);
+                 fprintf(fp, "\t%s\n", buf);
+        }
+
+ /* target: lun list */
+                 fprintf(fp, "\t# LUN settings\n");
+ write_lun_list(tid, fp);
+
+ /* target: session */
+                 fprintf(fp, "\t# Session settings\n");
+ memset(&session_param, 0, sizeof(session_param));
+                 ki->param_get(tid, 0, key_session,
+ session_param);
+ for (i = 0; i < session_key_last; i++) {
+                 memset(buf, 0, sizeof(buf));
+                 strcpy(buf, session_keys[i].name);
+                 p = buf + strlen(buf);
+                 *p++ = ' ';
+                 param_val_to_str(session_keys, i, session_param[i].val, p);
+                 fprintf(fp, "\t%s\n", buf);
+        }
+
+ fclose(fp);
+ free(targetcf);
+ return 0;
+ }
+         }
+ }
+
+ return 0;
+}
+
 struct config_operations plain_ops = {
  .init = plain_init,
  .default_load = plain_default_load,
diff -Nur iscsitarget-0.4.16.orig/usr/target.c iscsitarget-0.4.16/usr/target.c
--- iscsitarget-0.4.16.orig/usr/target.c 2008-03-18 07:41:02.000000000 +0100
+++ iscsitarget-0.4.16/usr/target.c 2008-06-17 13:04:16.000000000 +0200
@@ -120,6 +120,7 @@
 
  INIT_LIST_HEAD(&target->tlist);
  INIT_LIST_HEAD(&target->sessions_list);
+ INIT_LIST_HEAD(&target->lun_list);
  INIT_LIST_HEAD(&target->isns_head);
  target->tid = *tid;
  insque(&target->tlist, &targets_list);


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

testiscsi.sh (1K) Download Attachment

Re: Online target database?

by Jeff Waller :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello Marcel,

Thanks for the reply, I see you've begun a project here, good deal.  
Take it simply
as feedback (see below), but I disagree with the approach.  I think  
you'd be better
off pulling the file parser (but not the online command parser) smarts  
out of ietd except for
stuff that doesn't change as the daemon is running and maintain its  
online
configuration information using some Berkley dbm flavor.  Startup  
would pull in
the configuration information, and online updates would write out  
attributes.  Augment
ietadm by putting the parser into it instead and allow it to write out  
the entire DB
contents in human readable format if necessary.  Am ready and willing  
to help here.

On Jun 27, 2008, at 2:21 AM, Marcel Ritter wrote:

> Jeff Waller schrieb:
>> Reading the man page of ietadm, I find that ietadm will change the  
>> state of
>> the iet daemon, but
>> that information will not be persistent.  It's one of the known  
>> issues.
>>
>> Searching the archive, there's been a couple of suggestions along  
>> these
>> lines, but has there been
>> anything concretely done?  Has there been any discussion about  
>> making the
>> daemon use a more
>> online database (e.g. dbm) and it being the conduit for ietadm  
>> modifying
>> that?
>> -Jeff
>>
> Hi Jeff,
>
> I've started to implement this, but it's not finished yet. However I  
> don't like
> the idea of databases to store this information. open-iscsi for  
> example uses

database in the computer theoretic sense; agreed a relational database  
like mysql or
postgres is overkill here especially since one would imagine the  
reverse requirement;
ietd would offer  resources (filesystems) so that these heavy weight  
databases
can operate on filesystems exported from LVM allowing snapshots and  
such.

However that being said, I can imagine a future in which the usernames/
passwords
could be provided from a real heavy weight external process (LDAP,  
Radius).

But look, you're saying you don't want to use databases, but in fact  
you are,
your inventing a schema and a persistant store  in which elements are  
written
directly to files in a directory structure and to do that you're  
having to tack on a
parser and a file manager to boot.  You're complicating the design in  
order to
keep things simple.

>
> the god old unix fashion "everything is a file" -  and stores all  
> information
> in nice little plain text files (everyone can edit with his  
> favourite vi/emacs/whatever).
> So that's the way I'm doing it.

True everything is a file, but I don't think text files are what you  
want here.  They
offer human readability but are not appropriate for online kind of  
attribute changes.
Certainly they have their place in this project, but not as a means of  
maintaining the
state of ietd.

>
>
> As most users on linux will use open-iscsi as initiator (and  
> iscsitarget as target),
> I think it's nice to have a similar way to configure iscsi on both  
> sides.

I'm pretty sure open-iscsi uses dbm

>
>
> For now you'll have to create 3 extra directories in order to make  
> this version work:
>
> /etc/ietd.d/
> /etc/ietd.d/targets
> /etc/ietd.d/tids
>
> What I've done so far:
> - Added code to save changed settings
>  * users
>  * targets
>  * luns
>  * global settings: only partially
>
> Still to do:
> - clean up global option parsing/handling
> - read config files to restore iscsi settings on restart
> - cleanups ...
> - lots more (I guess)
>
> I've attached the patch - but please consider this work in progress.
>
> Bye,
>   Marcel
>
> --
> ----
> Dipl.-Inf. Marcel Ritter
> Linux/Novell
> Regionales Rechenzentrum Erlangen
> Tel: 09131 / 85-27808
> E-Mail: Marcel.Ritter@...
> ----

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

Re: Online target database?

by Marcel Ritter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Jeff Waller schrieb:
> Hello Marcel,
Hi Jeff,

>
> Thanks for the reply, I see you've begun a project here, good deal.  
> Take it simply
> as feedback (see below), but I disagree with the approach.  I think
> you'd be better
> off pulling the file parser (but not the online command parser) smarts
> out of ietd except for
> stuff that doesn't change as the daemon is running and maintain its
> online
> configuration information using some Berkley dbm flavor.
I'm not sure if I got it right: You'd like to take most of the file
parser stuff out of ietd
an put it into ietadm, right?
So ietadm converts plain config files into Berkley dbms read by ietd.
All online changes
are then written do db by whom: ietd or ietadm?

Which advantages do you get by using db instead of plain files?
- performance is not much of a topic
- config file parsing is needed anyway
- and: I like human-readable files ;-)

Just to explain my (simplistic) approach:
- Just keep the old code (as far as possible): if online changes were
accepted by kernel
   and ietd, write data to disk
> Startup would pull in the configuration information, and online
> updates would write out attributes.  Augment
> ietadm by putting the parser into it instead and allow it to write out
> the entire DB
> contents in human readable format if necessary.  Am ready and willing
> to help here.
That'd be great ;-)

Bye,
   Marcel

> On Jun 27, 2008, at 2:21 AM, Marcel Ritter wrote:
>
>> Jeff Waller schrieb:
>>> Reading the man page of ietadm, I find that ietadm will change the
>>> state of
>>> the iet daemon, but
>>> that information will not be persistent.  It's one of the known issues.
>>>
>>> Searching the archive, there's been a couple of suggestions along these
>>> lines, but has there been
>>> anything concretely done?  Has there been any discussion about
>>> making the
>>> daemon use a more
>>> online database (e.g. dbm) and it being the conduit for ietadm
>>> modifying
>>> that?
>>> -Jeff
>>>
>> Hi Jeff,
>>
>> I've started to implement this, but it's not finished yet. However I
>> don't like
>> the idea of databases to store this information. open-iscsi for
>> example uses
>
> database in the computer theoretic sense; agreed a relational database
> like mysql or
> postgres is overkill here especially since one would imagine the
> reverse requirement;
> ietd would offer  resources (filesystems) so that these heavy weight
> databases
> can operate on filesystems exported from LVM allowing snapshots and such.
>
> However that being said, I can imagine a future in which the
> usernames/passwords
> could be provided from a real heavy weight external process (LDAP,
> Radius).
>
> But look, you're saying you don't want to use databases, but in fact
> you are,
> your inventing a schema and a persistant store  in which elements are
> written
> directly to files in a directory structure and to do that you're
> having to tack on a
> parser and a file manager to boot.  You're complicating the design in
> order to
> keep things simple.
>
>>
>> the god old unix fashion "everything is a file" -  and stores all
>> information
>> in nice little plain text files (everyone can edit with his favourite
>> vi/emacs/whatever).
>> So that's the way I'm doing it.
>
> True everything is a file, but I don't think text files are what you
> want here.  They
> offer human readability but are not appropriate for online kind of
> attribute changes.
> Certainly they have their place in this project, but not as a means of
> maintaining the
> state of ietd.
>
>>
>>
>> As most users on linux will use open-iscsi as initiator (and
>> iscsitarget as target),
>> I think it's nice to have a similar way to configure iscsi on both
>> sides.
>
> I'm pretty sure open-iscsi uses dbm
>
>>
>>
>> For now you'll have to create 3 extra directories in order to make
>> this version work:
>>
>> /etc/ietd.d/
>> /etc/ietd.d/targets
>> /etc/ietd.d/tids
>>
>> What I've done so far:
>> - Added code to save changed settings
>>  * users
>>  * targets
>>  * luns
>>  * global settings: only partially
>>
>> Still to do:
>> - clean up global option parsing/handling
>> - read config files to restore iscsi settings on restart
>> - cleanups ...
>> - lots more (I guess)
>>
>> I've attached the patch - but please consider this work in progress.
>>
>> Bye,
>>   Marcel
>>
>> --
>> ----
>> Dipl.-Inf. Marcel Ritter
>> Linux/Novell
>> Regionales Rechenzentrum Erlangen
>> Tel: 09131 / 85-27808
>> E-Mail: Marcel.Ritter@...
>> ----


--
----
Dipl.-Inf. Marcel Ritter
Linux/Novell
Regionales Rechenzentrum Erlangen
Tel: 09131 / 85-27808
E-Mail: Marcel.Ritter@...
----
Unix _IS_ user friendly... It's just selective about who its friends are.



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

Re: Online target database?

by Jeff Waller :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Jun 27, 2008, at 6:14 AM, Marcel Ritter wrote:

> Jeff Waller schrieb:
>> Hello Marcel,
> Hi Jeff,
>>
>> Thanks for the reply, I see you've begun a project here, good  
>> deal.  Take it simply
>> as feedback (see below), but I disagree with the approach.  I think  
>> you'd be better
>> off pulling the file parser (but not the online command parser)  
>> smarts out of ietd except for
>> stuff that doesn't change as the daemon is running and maintain its  
>> online
>> configuration information using some Berkley dbm flavor.
> I'm not sure if I got it right: You'd like to take most of the file  
> parser stuff out of ietd
> an put it into ietadm, right?

  Yes.

>
> So ietadm converts plain config files into Berkley dbms read by  
> ietd. All online changes
> are then written do db by whom: ietd or ietadm?

ietd

>
>
> Which advantages do you get by using db instead of plain files?
> - performance is not much of a topic

That's true, I can't envision a scenario on which this database is
being updated quickly but only occasionally;  Typically as another
system adds storage wants them exposed via ietd, and changes in
user password/login stuff.

>
> - config file parsing is needed anyway
> - and: I like human-readable files ;-)

I think there's a place for having human readable files.  It's
a comfortable way to get started for new iscsitarget users.

>
>
> Just to explain my (simplistic) approach:
> - Just keep the old code (as far as possible): if online changes  
> were accepted by kernel
>  and ietd, write data to disk

I think we're close here.  I am of the same opinion.  I have to admit,  
I'm attracted
to the simplicity of something like (note necessary error checking  
removed for
ease of reading).

save_to_backing_store(key,value)
{   if(backing_store_type == DBM)
     {  dbm_write(store_id,key,value);
     }
}

looks like we're taking about essentially 5 tables

         the global attribute table
        the target table
        the target attribute table
        the user table
        the user attribute table

Is there more?  For one thing I'm not sure I follow the schema w.r.t.  
the target
user relationship, do you want to have the user named "User1" have  
global
effect or is it restricted to per target?  In the first case if you  
change the
user password, the effect is across all targets referring to that user  
name,
and in the 2nd case of course if you change the users password, it's  
only
for that target, though I wonder if  in that case, you should be  
instead using
another user name.

>
>> Startup would pull in the configuration information, and online  
>> updates would write out attributes.  Augment
>> ietadm by putting the parser into it instead and allow it to write  
>> out the entire DB
>> contents in human readable format if necessary.  Am ready and  
>> willing to help here.
> That'd be great ;-)
>
> Bye,
>  Marcel
>> On Jun 27, 2008, at 2:21 AM, Marcel Ritter wrote:
>>
>>> Jeff Waller schrieb:
>>>> Reading the man page of ietadm, I find that ietadm will change  
>>>> the state of
>>>> the iet daemon, but
>>>> that information will not be persistent.  It's one of the known  
>>>> issues.
>>>>
>>>> Searching the archive, there's been a couple of suggestions along  
>>>> these
>>>> lines, but has there been
>>>> anything concretely done?  Has there been any discussion about  
>>>> making the
>>>> daemon use a more
>>>> online database (e.g. dbm) and it being the conduit for ietadm  
>>>> modifying
>>>> that?
>>>> -Jeff
>>>>
>>> Hi Jeff,
>>>
>>> I've started to implement this, but it's not finished yet. However  
>>> I don't like
>>> the idea of databases to store this information. open-iscsi for  
>>> example uses
>>
>> database in the computer theoretic sense; agreed a relational  
>> database like mysql or
>> postgres is overkill here especially since one would imagine the  
>> reverse requirement;
>> ietd would offer  resources (filesystems) so that these heavy  
>> weight databases
>> can operate on filesystems exported from LVM allowing snapshots and  
>> such.
>>
>> However that being said, I can imagine a future in which the  
>> usernames/passwords
>> could be provided from a real heavy weight external process (LDAP,  
>> Radius).
>>
>> But look, you're saying you don't want to use databases, but in  
>> fact you are,
>> your inventing a schema and a persistant store  in which elements  
>> are written
>> directly to files in a directory structure and to do that you're  
>> having to tack on a
>> parser and a file manager to boot.  You're complicating the design  
>> in order to
>> keep things simple.
>>
>>>
>>> the god old unix fashion "everything is a file" -  and stores all  
>>> information
>>> in nice little plain text files (everyone can edit with his  
>>> favourite vi/emacs/whatever).
>>> So that's the way I'm doing it.
>>
>> True everything is a file, but I don't think text files are what  
>> you want here.  They
>> offer human readability but are not appropriate for online kind of  
>> attribute changes.
>> Certainly they have their place in this project, but not as a means  
>> of maintaining the
>> state of ietd.
>>
>>>
>>>
>>> As most users on linux will use open-iscsi as initiator (and  
>>> iscsitarget as target),
>>> I think it's nice to have a similar way to configure iscsi on both  
>>> sides.
>>
>> I'm pretty sure open-iscsi uses dbm
>>
>>>
>>>
>>> For now you'll have to create 3 extra directories in order to make  
>>> this version work:
>>>
>>> /etc/ietd.d/
>>> /etc/ietd.d/targets
>>> /etc/ietd.d/tids
>>>
>>> What I've done so far:
>>> - Added code to save changed settings
>>> * users
>>> * targets
>>> * luns
>>> * global settings: only partially
>>>
>>> Still to do:
>>> - clean up global option parsing/handling
>>> - read config files to restore iscsi settings on restart
>>> - cleanups ...
>>> - lots more (I guess)
>>>
>>> I've attached the patch - but please consider this work in progress.
>>>
>>> Bye,
>>>  Marcel
>>>
>>> --
>>> ----
>>> Dipl.-Inf. Marcel Ritter
>>> Linux/Novell
>>> Regionales Rechenzentrum Erlangen
>>> Tel: 09131 / 85-27808
>>> E-Mail: Marcel.Ritter@...
>>> ----
>
>
> --
> ----
> Dipl.-Inf. Marcel Ritter
> Linux/Novell
> Regionales Rechenzentrum Erlangen
> Tel: 09131 / 85-27808
> E-Mail: Marcel.Ritter@...
> ----
> Unix _IS_ user friendly... It's just selective about who its friends  
> are.
>
>


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

Re: Online target database?

by rswwalker :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Jeff Waller wrote:

> On Jun 27, 2008, at 6:14 AM, Marcel Ritter wrote:
>
> > Jeff Waller schrieb:
> >> Hello Marcel,
> > Hi Jeff,
> >>
> >> Thanks for the reply, I see you've begun a project here, good  
> >> deal.  Take it simply as feedback (see below), but I disagree
> >> with the approach. I think you'd be better off pulling the file
> >> parser (but not the online command parser) smarts out of ietd
> >> except for stuff that doesn't change as the daemon is running
> >> and maintain its online configuration information using some
> >> Berkley dbm flavor.
> >
> > I'm not sure if I got it right: You'd like to take most of the
> > file parser stuff out of ietd an put it into ietadm, right?
>
>   Yes.
>
> >
> > So ietadm converts plain config files into Berkley dbms read by  
> > ietd. All online changes are then written do db by whom: ietd or
> > ietadm?
>
> ietd
>
> >
> > Which advantages do you get by using db instead of plain files?
> > - performance is not much of a topic
>
> That's true, I can't envision a scenario on which this database is
> being updated quickly but only occasionally;  Typically as another
> system adds storage wants them exposed via ietd, and changes in
> user password/login stuff.
>
> >
> > - config file parsing is needed anyway
> > - and: I like human-readable files ;-)
>
> I think there's a place for having human readable files.  It's
> a comfortable way to get started for new iscsitarget users.
>
> >
> >
> > Just to explain my (simplistic) approach:
> > - Just keep the old code (as far as possible): if online changes  
> > were accepted by kernel and ietd, write data to disk
>
> I think we're close here.  I am of the same opinion.  I have to
> admit, I'm attracted to the simplicity of something like (note
> necessary error checking removed for ease of reading).
>
.
.
.

Instead of making the software more complex why not figure out
a simple change that can be made to the existing system that
would provide the functionality you desire?

For example,

a) modify ietadm to read ietd.conf and modify running targets
to match.

b) modify ietadm to dump running target configuration in
ietd.conf format.

-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.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

Re: Online target database?

by Jeff Waller :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Ross,


On Jun 27, 2008, at 12:34 PM, Ross S. W. Walker wrote:

> Jeff Waller wrote:
>
>> On Jun 27, 2008, at 6:14 AM, Marcel Ritter wrote:
>>
>>> Jeff Waller schrieb:
>>>> Hello Marcel,
>>> Hi Jeff,
>>>>
>>>> Thanks for the reply, I see you've begun a project here, good
>>>> deal.  Take it simply as feedback (see below), but I disagree
>>>> with the approach. I think you'd be better off pulling the file
>>>> parser (but not the online command parser) smarts out of ietd
>>>> except for stuff that doesn't change as the daemon is running
>>>> and maintain its online configuration information using some
>>>> Berkley dbm flavor.
>>>
>>> I'm not sure if I got it right: You'd like to take most of the
>>> file parser stuff out of ietd an put it into ietadm, right?
>>
>> Yes.
>>
>>>
>>> So ietadm converts plain config files into Berkley dbms read by
>>> ietd. All online changes are then written do db by whom: ietd or
>>> ietadm?
>>
>> ietd
>>
>>>
>>> Which advantages do you get by using db instead of plain files?
>>> - performance is not much of a topic
>>
>> That's true, I can't envision a scenario on which this database is
>> being updated quickly but only occasionally;  Typically as another
>> system adds storage wants them exposed via ietd, and changes in
>> user password/login stuff.
>>
>>>
>>> - config file parsing is needed anyway
>>> - and: I like human-readable files ;-)
>>
>> I think there's a place for having human readable files.  It's
>> a comfortable way to get started for new iscsitarget users.
>>
>>>
>>>
>>> Just to explain my (simplistic) approach:
>>> - Just keep the old code (as far as possible): if online changes
>>> were accepted by kernel and ietd, write data to disk
>>
>> I think we're close here.  I am of the same opinion.  I have to
>> admit, I'm attracted to the simplicity of something like (note
>> necessary error checking removed for ease of reading).
>>
> .
> .
> .
>
> Instead of making the software more complex why not figure out
> a simple change that can be made to the existing system that
> would provide the functionality you desire?

Requirements eh? Yep, one again I got the cart before the horse.
Here's what I would like to see from a  user's perspective in the  
future.

1) An API which would allow me to update ietd not having to
use ietadm, or having root privs necessarily -- probably from the
initiator.  Although I have to say that one of the the very first
things I'd use it for is to couple LVM admin which would require
root privs and not on the initiator.  Maybe a means of displaying
status information (blocks in/out maybe) certainly exported luns
in a nice user desktop kind of way (some 3rd party deal using
the API).

2) Some online way to cause ietd to recognize LVM device
changes (resizes).  Maybe it does already?  My first test didn't
go so well though I hardly spent time on it.

All of these possible future changes seem to have the feel of
being more about online updates rather than config  files
which is kind of how I got here.

>
>
> For example,
>
> a) modify ietadm to read ietd.conf and modify running targets
> to match.
>
>
> b) modify ietadm to dump running target configuration in
> ietd.conf format.

This sounds about as complex.  All there scenarios share the
same object of committing the current state of the daemon to disk.
They simply use different formats.

>
>
> -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.
>


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

Re: Online target database?

by Chris Siebenmann :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

| I think you'd be better off pulling the file parser (but not the
| online command parser) smarts out of ietd except for stuff that
| doesn't change as the daemon is running and maintain its online
| configuration information using some Berkley dbm flavor.

 Speaking as a system administrator, the last thing I want is for a
crucial daemon to maintain the master copy of its configuration in a
binary database, especially an opaque one. As a minimum, it insures that
I have to keep my own master copy of said configuration in a text file
that I can easily back up, inspect, and verify.

 This especially so when the binary database is explicitly not
transactional and otherwise protected from accidents like full disks or
untimely crashes. (In other words, if you are going to do this please
use SQLite, not DBM. You don't need the possible performance advantages
of DBM, and you do need the hardening that SQLite will give you.)

        - cks

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

Re: Online target database?

by Chris Siebenmann :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

| 1) An API which would allow me to update ietd not having to use
| ietadm, or having root privs necessarily -- probably from the
| initiator.

 Since unrestricted ietd configuration changes can easily give
you root access on the target system[*], I absolutely want ietd
updates to require (target) root permissions.

 If you want a less restricted environment, it's not complicated to
build a daemon that will accept commands from various sources and run
ietadm et al with the appropriate arguments. You can then wrap talking
to the daemon in a suitable API, and you're done.

(Authenticating the connections to the daemon is no more difficult than
authenticating things in the API.)

        - cks
[*: export the target's root disk, go to town from your initiator
    with the filesystem manipulation tools of your choice.]

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

Re: Online target database?

by rswwalker :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Jeff Waller wrote:

> On Jun 27, 2008, at 12:34 PM, Ross S. W. Walker wrote:
>
> >
> > Instead of making the software more complex why not figure out
> > a simple change that can be made to the existing system that
> > would provide the functionality you desire?
>
> Requirements eh? Yep, one again I got the cart before the horse.
> Here's what I would like to see from a  user's perspective in the  
> future.
>
> 1) An API which would allow me to update ietd not having to
> use ietadm, or having root privs necessarily -- probably from the
> initiator.  Although I have to say that one of the the very first
> things I'd use it for is to couple LVM admin which would require
> root privs and not on the initiator.  Maybe a means of displaying
> status information (blocks in/out maybe) certainly exported luns
> in a nice user desktop kind of way (some 3rd party deal using
> the API).
>
> 2) Some online way to cause ietd to recognize LVM device
> changes (resizes).  Maybe it does already?  My first test didn't
> go so well though I hardly spent time on it.
>
> All of these possible future changes seem to have the feel of
> being more about online updates rather than config  files
> which is kind of how I got here.

Ah, ok, well I think the idea is great, there is already 1
published API for managing SANs remotely called VDS from
Microsoft.

In fact a VDS daemon to interact with ietd, lvm, etc. would
be great for Linux as a whole. Setup it up to work with MS
RPC and have these RPC calls manage the services. You could
even make it open-ended so it doesn't rely on IET, but can
use different iSCSI target software by designing it to
make calls to ietadm and lvm to perform the actions. Then
one can substitute ietadm for whatever, or substitute lvm
for evms, etc.

Such a service could be used to have lvm take a volume
snapshot, then have IET export it as a read-only target. Or
to have a Windows operator create a logical volume and
export it without having access to the Linux box.

As for #2 you could modify ietd to respond to signals sent
to it. 1 signal to re-read ietd.conf and update the
running configuration non-destructively, and another
signal to re-read ietd.conf and do a full reset which
would cause it to drop the luns, re-add them reading
their new size, or to drop targets altogether if they
are no longer in ietd.conf.

-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.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

Re: Online target database?

by Jeff Waller :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Jun 27, 2008, at 2:40 PM, Chris Siebenmann wrote:

> | I think you'd be better off pulling the file parser (but not the
> | online command parser) smarts out of ietd except for stuff that
> | doesn't change as the daemon is running and maintain its online
> | configuration information using some Berkley dbm flavor.
>
> Speaking as a system administrator, the last thing I want is for a
> crucial daemon to maintain the master copy of its configuration in a
> binary database, especially an opaque one. As a minimum, it insures  
> that
> I have to keep my own master copy of said configuration in a text file
> that I can easily back up, inspect, and verify.
>
> This especially so when the binary database is explicitly not
> transactional and otherwise protected from accidents like full disks  
> or
> untimely crashes. (In other words, if you are going to do this please
> use SQLite, not DBM. You don't need the possible performance  
> advantages
> of DBM, and you do need the hardening that SQLite will give you.)

Ok, agreed. if this ends up being done this way as opposed to  
synchronized
configuration files (Ross) or otherwise human readable format  
(Marcel).  SQLite
is the engine.
 

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

Re: Online target database?