|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
|
|
Online target database?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?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 > 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 |
|
|
Re: Online target database?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?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. 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?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?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?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?| 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?| 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?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?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? |