Re: [RFC] C/Python initiator userspace API approach.
Hi Lee, On 06/09/2017 07:02 PM, The Lee-Man wrote: > I am seriously interested in both adding an API like this (if done > right) and in adding more/better locking so that iscsid could support > more parallelism. While I maintain open-iscsi for Debian, I must confess that I haven't looked too closely at the source code. Is iscsid multithreaded at all? Because if not, one could easily just use an event-based model and would have no need for locks, even if one adds a public IPC mechanism, regardless of whether that's DBus or not. > But I know almost nothing about DBus. Why would anyone say no to > dbus? DBus was initially developed to replace CORBA, DCOM, and similar approaches to inter-process communication that were used by GNOME and KDE on the desktop. For this reason DBus tends to have a stigma attached to it that it isn't "for servers". Furthermore, to be fair, I see three points where DBus has some problems: 1. There are some inherent design decisions in the setup / protocol that are maybe not 100% optimal. 2. The performance of the current DBus implementation could be better. 3. DBus leaves security up to the programs themselves. To address all three of these points in the context of iscsid: As for (1): I think this point is a valid argument in a meta discussion about the future of IPC systems on Linux / etc., but when it comes to deciding whether to a) roll one's own IPC or b) use DBus, I don't think this plays a role. If someone were to develop a far better alternative to DBus then this argument will be relevant IHMO, but not now. DBus is here, widely supported by a lot of tooling and languages, and despite some flaws in its design it does do a lot of things right. As for (2): I don't think in the case of iscsi performance of the IPC system is critical. For pure control commands and change notifications DBus is by far fast enough, and that is what we're talking about for iscsid. (If you wanted to transfer the raw iSCSI packets then you obviously wouldn't want to use DBus, for this very reason.) As for (3): This is the reason for the following policy: > I know that at SUSE we require a security analysis before we > allow a new daemon that uses DBus, So basically that means that instead of relying on e.g. the kernel to protect a socket with simple access rights, you have to do access checks yourself. > Can you explain the DBus trade-off to me? So let me give a very, very basic introduction to how DBus works as an IPC system here. This is going to be simplified quite a bit, so if you have additional questions, feel free to ask. DBus is - as the name suggests - a bus. A so-called "client" is a program that connects to the bus. A client can do two things: - access other clients over the bus - provide services for other clients on the bus A client may do both at the same time. (The only reason why they are called clients is that in practice the DBus bus is implemented via a single server process, dbus-daemon.) There are two types of busses in DBus: the system bus and then session/user busses. The latter are used when people log in to the system and are private to that specific user. Those busses are not interesting to iscsid, so I'll ignore them. The system bus is a global bus available on the entire machine (though containers such as LXC have separate system busses if DBus is installed there). Any process on the system may connect to the system bus [1], the socket has mode 0666. Once a process connects to the system bus, it will automatically be assigned a "unique name" by the dbus daemon, which has the form ":1.NNN" [2], where NNN is an increasing counter. DBus guarantees that this name will not be reused during the runtime of dbus-daemon. Once connected, services may send each other messages. There are four basic message types in DBus: - ERROR - METHOD_CALL: the sender wants to invoke a specific remote method of the target - METHOD_RETURN: the sender wants to reply to a METHOD_CALL (note that DBus doen't require METHOD_RETURN, some methods may have no return) - SIGNAL: the sender wants to send a signal (potentially as a broadcast) that indicates an event (such as a state change, for example) To give a specific example for a potential implementation for iscsid: METHOD_CALL would be used to tell iscsid to e.g. login to a target, and METHOD_RETURN would be the result of that operation. SIGNAL could be used to broadcast to all interested parties that a new target has now been logged into, or that a session recovery has just taken place, etc. Only two more missing pieces, which I"ll discuss in the following: First of all: since the unique names are not deterministic, how does any client know which other client is actually the service it wants to talk to? For this DBus has a concept of "well-known names". A well-known name is a name in "reverse domain order", for iscsid this could e.g. be "com.open-iscsi.iscsid". A client may register a well-known name
Re: [RFC] C/Python initiator userspace API approach.
On 04/26/2017 01:03 PM, Gris Ge wrote: > On Wed, Apr 26, 2017 at 09:14:35AM +0200, Christian Seiler wrote: >> On 04/26/2017 01:11 AM, Gris Ge wrote: >>> B) Expand iscsid to listen on a socket for IPC with JSON output. >>> Pro: >>> * Easy to create language bindings via JSON + IPC. >>> Con: >>> * More code work on iscsid like lock, ipc listener, json >>> formatter and etc. >> >> I don't think creating yet another own IPC interface is a good >> idea, there are already way too many IPC protocols in the Linux >> plubming space. I believe that DBus would be the obvious choice >> here. This has several advantages: > Given my bad grudges of dbus, I am afraid I could not able to provide > demo/POC of dbus interface/service of open-iscsi. Well, if it's under serious consideration, I'd be willing to put my money^Wtime where my mouth is and write some code for this. But only if there's a decent chance that this will not be for nothing. If either Lee or Chris say "we'll never merge DBus support" I'm not really that interested in working on that, for obvious reasons. ;-) Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Antw: Re: [RFC] C/Python initiator userspace API approach.
On 04/26/2017 09:29 AM, Ulrich Windl wrote: >>>> Christian Seiler schrieb am 26.04.2017 um >>>> 09:14 in > Nachricht : >> On 04/26/2017 01:11 AM, Gris Ge wrote: >>> B) Expand iscsid to listen on a socket for IPC with JSON output. >>> Pro: >>> * Easy to create language bindings via JSON + IPC. >>> Con: >>> * More code work on iscsid like lock, ipc listener, json >>> formatter and etc. >> >> I don't think creating yet another own IPC interface is a good >> idea, there are already way too many IPC protocols in the Linux >> plubming space. I believe that DBus would be the obvious choice >> here. This has several advantages: > > I'm no JSON fan either, but I think IPC is much lower level than dbus > is (which is good during boot to keep initrd small). So dbus has to > have benefits over a simpler mechanism tu justify it. Well, dbus isn't that complicated, and the normal IPC socket that is currently used by iscsiadm will probably not disappear. And if you really want to do Python in the initramfs, dbus really would not be the problem. ;-) As for the benefits: you didn't comment on the advantages I mentioned below in my email below: >> - introspection support >> - the object-based view it provides lends itself well to the >>problem at hand >> - a _lot_ of tooling >> - lots of language bindings >> - support for notifications (signals): this allows iscsid to >>broadcast changes to anyone who's interested >> - authorization can be managed entirely via PolicyKit, so >>there's no need t invent an own authentication and >>authentication system, one can leverage something that many >>people are already used to The most important benefit in my eyes though is: it's a standard. A ton of plumbing-related software already speaks DBus: NetworkManager, systemd-networkd, Avahi, WPA supplicant, systemd, Upstart (for those on older Ubuntu versions), LVM [1], logind, etc. There's even management software that uses DBus internally (see e.g. Cockpit [2], which uses DBus to manage a lot of things). Look, I don't think DBus is perfect. There's a reason why some people have been working on kdbus as a successor, even though that didn't pan out. I wouldn't be surprised if at some point in the future yet another alternative to that will make its way into the GNU/Linux ecosystem. But until a better alternative emerges I believe it's detrimental for every project to invent its own IPC interface if it is supposed to be stable to the outside world (and not just used internally). And I believe that DBus has a worse reputation than it deserves, if you look into it (and ignore all of the desktop stuff), the underlying concepts are actually pretty decent, especially for mapping typical IPC stuff. Regards, Christian [1] http://man7.org/linux/man-pages/man8/lvmdbusd.8.html [2] http://cockpit-project.org/ Haven't tried that though, have only read about it. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: [RFC] C/Python initiator userspace API approach.
On 04/26/2017 01:11 AM, Gris Ge wrote: > B) Expand iscsid to listen on a socket for IPC with JSON output. > Pro: > * Easy to create language bindings via JSON + IPC. > Con: > * More code work on iscsid like lock, ipc listener, json > formatter and etc. I don't think creating yet another own IPC interface is a good idea, there are already way too many IPC protocols in the Linux plubming space. I believe that DBus would be the obvious choice here. This has several advantages: - introspection support - the object-based view it provides lends itself well to the problem at hand - a _lot_ of tooling - lots of language bindings - support for notifications (signals): this allows iscsid to broadcast changes to anyone who's interested - authorization can be managed entirely via PolicyKit, so there's no need t invent an own authentication and authentication system, one can leverage something that many people are already used to There are some caveats though: - the DBus daemon might not have been started at the point where iscsid is started - the DBus daemon might be stopped before iscsid is suppoed to stop, so the DBus connection could go away at any time However, I think both of these issues are solvable: 1. If the DBus connection can't be established at startup, don't consider that to be a failure, just continue on. 2. Upon receiving SIGUSR1 (or similar), try to reconnect to the system bus. iscsid could be sent SIGUSR1 from a service file / init script after DBus is up and running 3. If the system bus connection goes away, don't fail, just continue on. Maybe try to reconnect immediately once, in case someone just restarted the daemon. Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: iscsistart -N skips offload NICs causing boot to fail on debian
On 12/23/2016 09:17 PM, Andrew Patterson wrote: > On 12/23/2016 11:18 AM, The Lee-Man wrote: >> On Friday, December 23, 2016 at 7:32:27 AM UTC-8, Christian Seiler wrote: >> >> On 12/22/2016 07:07 PM, Andrew Patterson wrote: >> > I found a bnx2x card with iscsi hardware offload support. Running >> > iscsistart -f does bring the interace up and assign an IP to it as >> > long as OFFLOAD_BOOT_SUPPORTED is defined. However, iscsistart -b >> needs iscsiuio >> > running to log into a LUN, which the current debian scripts do not >> > start (or even add to the initramfs). >> >> So the reason why neither Ritesh nor I have added support for >> iscsiuio in the initramfs to the Debian package is that we both >> don't have any hardware with a corresponding network card, so >> we are really unable to test it. >> >> >> >> We'll gladly accept patches for the initramfs logic (or even >> help writing them if you agree to test them) to get this working, >> so please feel free to contact me, either privately or via the >> Debian bugtracker, in this regard. >> > > I can start on this after the end of the year, testing or providing a > patch or both. I will file a debian bug. Many thanks! Note that if you want to see this in Stretch because of the looming freeze deadline, this has to be done until Jan 25th. (I could live with this going into either Stretch or the Debian release following that, so no pressure if you don't get to it until then, just wanted to make you aware of the deadline.) Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: iscsistart -N skips offload NICs causing boot to fail on debian
On 12/22/2016 07:07 PM, Andrew Patterson wrote: > I found a bnx2x card with iscsi hardware offload support. Running > iscsistart -f does bring the interace up and assign an IP to it as > long as OFFLOAD_BOOT_SUPPORTED is defined. However, iscsistart -b needs > iscsiuio > running to log into a LUN, which the current debian scripts do not > start (or even add to the initramfs). So the reason why neither Ritesh nor I have added support for iscsiuio in the initramfs to the Debian package is that we both don't have any hardware with a corresponding network card, so we are really unable to test it. We'll gladly accept patches for the initramfs logic (or even help writing them if you agree to test them) to get this working, so please feel free to contact me, either privately or via the Debian bugtracker, in this regard. Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: [PATCHv4 0/2] Handle iscsid shutdown more cleanly
On 11/29/2016 01:01 AM, Lee Duncan wrote: > No comment on these? Since the previous version drew comments, can I > assume that means everybody is happy with this version? >From a Debian maintainer perspective, I'd be happy with it. Only minor thing is that you might want to mark static int event_loop_stop; (usr/event_poll.c) to be volatile, to be on the safe side when modifying it from within a signal handler. Probably not really required here (the compiler is not allowed to optimize out the access anyway, since you call non-static functions within the loop), but it doesn't hurt either, just in case... Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: [PATCHv2 2/2] iscsid: treat SIGTERM like "iscsiadm -k 0".
On 11/23/2016 10:43 PM, Lee Duncan wrote:
> On Nov 23, 2016, at 4:13 AM, Christian Seiler
> wrote:
>>
>> Hi,
>>
>> On 11/22/2016 11:43 PM, leeman.dun...@gmail.com wrote:
>>> static void catch_signal(int signo)
>>> [...]
>>> switch (signo) {
>>> case SIGTERM:
>>> - iscsid_shutdown();
>>> + iscsid_shutdown_and_cleanup();
>>> exit(0);
>>> break;
>>
>> I think this is not a good idea because most functions called
>> here will not be async signal safe, and you are calling them
>> from a signal handler. Beforehand this was not a problem since
>> iscsid_shutdown() is just a kill of the process group.
>
> The signal is ignored while in the signal handler, and I expect
> not to get a SIGTERM storm. But perhaps you are right.
That's not what I meant when discussing async-signal
safety. My point was not about other signals interrupting
the signal handler itself - during the signal handler's
execution, they will be blocked, as you rightly stated.
My worry is the following scenario: the normal code is
calling a routine, and that routine gets interrupted by a
SIGTERM, then the data structures in memory could be in an
inconsistent state (because a part of the memory was changed,
but other parts haven't yet). In that case, the signal
handler would try to tear down an inconsistent data
structure.
> I see now (looking at the code), that I can just set the “exit
> the event loop” flag when SIGTERM is received. And it has
> the added benefit of being idempotent, so I don’t need to
> guard against receiving multiple signals.
Yes, I think that's the best solution.
Regards,
Christian
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Re: [PATCHv2 2/2] iscsid: treat SIGTERM like "iscsiadm -k 0".
Hi,
On 11/22/2016 11:43 PM, leeman.dun...@gmail.com wrote:
> static void catch_signal(int signo)
> [...]
> switch (signo) {
> case SIGTERM:
> - iscsid_shutdown();
> + iscsid_shutdown_and_cleanup();
> exit(0);
> break;
I think this is not a good idea because most functions called
here will not be async signal safe, and you are calling them
from a signal handler. Beforehand this was not a problem since
iscsid_shutdown() is just a kill of the process group.
This might lead to very ugly race condition and deadlocks, and
the race conditions could cause crashes or even arbitrary
memory to be overwritten in the worst case. (Think code that
is in the middle of updating a data structure, and the signal
comes at a time when the structure is in an inconsistent
state.)
Creating async-signal-safe data structures is not impossible
(as long as atomic operations are available), but very hard to
do properly, and even harder when shutdown of these data
structures in a signal handler is to be supported. Writing
thread-safe code is much, much easier, for example.
The recommended way of performing complicated actions in
response to signals in daemons is to have the signal handler
set a flag (either using atomic operations or with the good
old "volatile") and have the regular event loop always check
to see if the flag was changed, and if so initiate a
shutdown.
Regards,
Christian
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Re: RFC: iscsid shutdown hangs with system when service manually killed
On 11/20/2016 04:45 PM, Lee Duncan wrote: > I use socket activation for SUSE because we want open-iscsi installed > by default but not running. There was an effort to reduce the number > of default-running services, and it takes an act of congress to add > a new default-running service now. The approach now is to give > the end-user more choice in which services are running, rather than > choosing for them. > > But socket activation allows iscsid to only be started the first > time it’s needed, and that was an acceptable alternative to > having the daemon running all the time. But how does that interact with your boot process? - Don't you run iscsiadm -m node --loginall=automatic? Doesn't that start iscsid automatically, regardless of the startup setting, because it will send a request along the socket? And since there is no idle logic in iscsid, will that not keep running by default anyway? - How do you start iscsid if a session is configured in via the initramfs (i.e. rootfs on iSCSI, using iscsistart), but there is no session in the database, if your daemon is only ever socket-activated? > We have a separate service for iscsi sessions, layered on top > of the daemon service, but I can see this sequence happening > for us if the user has the session service enabled but manually > kills iscsid. Out of curiosity: how does your startup logic work precisely? I personally think it'd be interesting to see what other distros do. (That said: I don't think that we can adopt this in Debian anytime soon, definitely not for the next Debian release, as we must support legacy configuration from previous upgrades, and previously people could configure all sorts of stuff that was done at boot time by some script that I personally want to get rid of at some point in the future.) Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: RFC: iscsid shutdown hangs with system when service manually killed
On 11/19/2016 08:46 PM, The Lee-Man wrote: > In this wonderful new world of systemd, I have an issue with stopping the > iscsid service when the daemon has died or been killed. > > My setup: > * I have an iscsid.socket unit file, which is enabled and started > * I have an iscsid.service unit file, which controls the iscsid daemon. > This is disabled and not started > > Normally, if I run a command like "iscsiadm -m discovery -t st -p > SOME-TARGET", systemd notices that iscsiadm is trying to talk to iscsid > through the socket, and it starts up iscsid. This is the cool part (IMHO) > of systemd socket activation. > > When I want to stop iscsid, I can just tell systemctl to do it via > "systemctl stop iscsid", and it runs the "ExecStop=" command in the service > unit file, which is "iscsiadm -k 0 2" before terminating the daemon > process(es). > > [NOTE: the "2" here in this command actually does nothing and is ignored, > but I copied this from someplace else long ago, and the "2" was present > there.] > > It is of importance, in this case, that the ExecStop command actually sends > an IPC message to the daemon (iscsid) requesting it to cleanly shut itself > down. Herein lies the rub. > > All of this works great until the daemon happens not to be running. You can > simulate this with "kill -TERM $(pidof iscsid)" when the daemon is running. > Now you are in a situation where systemd started the service and knows it > is now not running, so it seems to send the ExecStop command to cleanly > shut it down. This command hangs! It seems to be stuck in an infinite loop > trying to send the shutdown command to the daemon, waiting for it to > timeout, then trying again. The daemon starts up, sees an IPC error, and > exits. The problem here is that iscsiadm tries to connect to the iSCSI socket. This triggers systemd's socket activation, but systemd doesn't allow conflicting jobs (the systemd terminology for an operation) to execute at the same time, so it enqueues the start job due to socket activation so that it will be executed _after_ the current stop job is complete. Unfortunately iscsiadm hangs until it gets a reply from the socket, so the stop job hangs until the start job has been executed again. > While this clearly seems like a systemd issue, I have found a workaround > that looks clean. Well, as clean as the shutdown command is, anyway. This > involves: > > * modifying the "iscsiadm -k" command to require passing in the PID of the > daemon to be killed > * modifying the iscsiadm to only call kill_iscsid() if positive PID is > passed in, and that PID exists. It verifies this by sending a blank signal > to the process. > * modifying the iscsid.service systemd unit file so that the ExecStop > command becomes "iscsiadm -k 0 $MAINPID" That seems like a reasonable way to work around this problem. > I know other distributions are having been dealing with iscsid service > shutdown issues with systemd for a while now. Perhaps somebody else has a > better solution? In Debian we just don't use socket activation for iscsid, but just install a systemd service file alone. I think I had trouble with socket activation (may well have been the same problem you had, I don't remember), but when I actually thought about it in more detail, I didn't see the point in having socket activation for iscsid in the first place, at least not in Debian, so I just dropped that part. The rationale for why we don't make use of socket activation: - we unconditionally execute iscsiadm -m node --loginall=automatic at boot if open-iscsi is installed - that will cause iscsid to start at boot even with socket activation, and stay active for the entirety of the running system => this means that even if there are no configured sessions we still don't save time at boot - since iscsid is required to be kept around for session recovery it can't auto-exit on idle, because an active session means it should never be idle (and there's currently no support in the code for that) - the corner case where people have iscsid installed but don't use it didn't seem that relevant, especially since iscsid uses less than 4 MiB of RAM on my system if unused - but even if we were to make iscsiadm not contact iscsid when using --loginall=automatic and no sessions are configured, this still wouldn't help us, because there still could be sessions configured in the initramfs, for which we'd want to have iscsid running at boot to perform session recovery The only thing I could think of to make this at least somewhat useful is to have iscsid exit if there are no active sessions and a certain time has passed => exit on idle. Doesn't save boot time, but saves a small amount of resources in the corner case where the user has no active sessions. However, that still leaves a potential hang on shutdown: if iscsid is killed manually (or even stopped via systemctl stop), and then
Re: iscsiadm --logoutall=all vs. sessions without match in node database
On 11/01/2016 03:34 PM, The Lee-Man wrote: > What about having open-iscsi update the node database entry when the TPG > changes? I'd rather not see iscsid shutting down targets that were not > specified. I'm a bit unsure about magically updating the node database behind the user's back. At the moment certain operations will update the node database (-m discovery, -m node --op update, etc.), while others will not (-m node --login). The former is something the user will call themselves explicitly (hence knowing that the node database is updated) while the latter isn't. (Plus, in Debian we keep the database in /etc/iscsi for policy reasons, because we consider it to be configuration, and /etc could be read-only at session login time, think virtualization and the such.) > What I would actually like to solve this problem more generally is a way to > say "logout of all sessions except 'onboot' sessions", whether or not > there's a node database entry. Well, if you want to keep the current semantics for all, we could add a new keyword ALL (capital letters, current versions reject it, so it won't break anything) that has this new semantics Then we'd have: --logoutall=all current semantics, if session not in DB, ignore it --logoutall=ALL new semantics, if session not in DB, consider it regardless That retains backwards compatibility while still being reasonably legible. That said: if after login the resulting session can result in a different TPGT, I would want to implement a two-step matching of sessions regardless. Example: - target: iqn.dummy - portal: 127.0.0.1:3260 - tpgt at target: 42 - tpgt in node database: 1 iscsiadm -m node -T iqn.dummy -p 127.0.0.1:3260 --login => logs into target iscsiadm -m node -T iqn.dummy -p 127.0.0.1:3260 --logout => fails at the moment (IIRC) I would therefore in addition want to implement session matching in the node database in the following way (but for running sessions only): - if exact combination of is available, use that - if has a _unique_ entry with a different tpgt, use that instead In that case, --logoutall=all (lowercase) would still match the session (because it effectively is in the database), as well as the manual logout command I presented above. Would you agree to both of these changes? I'd be willing to write and submit patches for that. Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: open-isns: BUG: Discovery Domain membership duplicated when restoring from disc
On 11/01/2016 03:23 PM, The Lee-Man wrote: > Apologies. I get how the versioning works now. I hadn't updated the > version since you had added that, and I shouldn't have been more > careful. No worries, it worked out in the end, because: > It's fixed now. I had never actually pushed the tag for v0.97 yet, > so I tagged the latest commit, which reverts the changes to libisns. Oh, fantastic. :-) Thanks! Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: iscsiadm --logoutall=all vs. sessions without match in node database
Hello again, On 10/02/2016 12:21 PM, Christian Seiler wrote: > Recently there has been a bug report in Debian about -U all not > logging out of all active iSCSI sessions on shutdown: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838540 > > I've isolated the problem, and what happens is as follows: > > 1. An external tool sets up a node configuration manually [1], but >makes a small mistake, by not setting a target portal group tag >at all, so open-iscsi will default to 1 - instead of the correct >value of 257 for that target. (In the case of the bug reporter.) > > 2. The external tool logs in on that portal via iscsiadm. > > 3. The login succeeds, but either iscsid or the kernel (I'm not >deep enough in the code to know exactly where that happens) >figures out "hey, the actual portal target group tag is 257, >so use that". Hence, login succeeds, but the node database >references the wrong portal group. > > 4. On shutdown, iscsiadm --logoutall=all is called. The >__logout_by_startup callback tries to run idbm_rec_read() on >the session, that fails, so it completely skips that session. > > This behavior in (4) seems wrong to me in two ways: > > a. If the tpgt can change after login, then the matching against > the tpgt should be relaxed. > > i.e. first try to match the tpgt exactly, if that fails, > just try to find the same match but without fixing the tpgt. > That way, if a login changed the tpgt implicitly, this > would still match the right config with the right session. > > b. Regardless of that, there could be active iSCSI sessions > without a corresponding configuration. For example, if the > configuration was wiped accidentally before shutting down > the session. Or someone accidentally used iscsistart on a > already booted system without knowing what they were doing. > In that case, would it not be better if --logoutall=all is > specify to not skip that session, even if there's no match > in the node database? After all, the manpage says -U all > will logout of all active sessions that are NOT onboot, > and it doesn't say "all sessions that have a config AND are > not onboot". > > The counterpoint to that would be: if someone were have a > setup with root on iSCSI, and the session of the root > filesystem not configured in the node database at all (but > rather just in some separate config used by the initramfs > they were using), then the current behavior treats that as > if onboot were set in that case, whereas my proposed change > would be treat that as automatic or manual and -U all > would also kill that. In Debian that wouldn't be a problem, > as we already have logic in the shutdown script to > dynamically detect the session on which the root filesystem > (and potentially /usr) is located, but other distros > probably don't. > > But maybe we could add --logoutall=reallyall or something? > (Maybe with a better name?) > > I'm mostly interested in fixing (a), because that's what's > causing the immediate problem the bug reporter is experiencing. > But (b) deserves some consideration as well IMHO. > > Now of course, the original bug is the external tool generating > a static node config with the wrong tpgt - and if open-iscsi > were to simply refuse logins in the first place, I'd also be > fine with that behavior. But since that's not the case (and it's > very likely true that a lot of people are in some way relying on > the fact that the tpgt isn't that important at login, so it's > not going to be realistic to change that), and the login does > succeed anyway, I think the automated logout should as well. > > I can work on a patch, but before I start, I'd like to hear > some thoughts on this first. Thanks! I would appreciate it if I could get some feedback on this, because I would really like to see this fixed. While I'd be able and willing to write a patch for that, I'd first like to hear back so I don't waste time going on in a direction that'll ultimately be rejected. Thanks! Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: open-isns: BUG: Discovery Domain membership duplicated when restoring from disc
> At the same time, I fixed a few cosmetic issues and updated the > version to 0.97. Unfortunately, that broke ABI for the shared library (if that's enabled via --enable-shared), by replacing all references to 0.96 in the version script with 0.97. That's not how version scripts work - and if I now compile the shared library and install it, all programs linked against 0.96 would immediately fail to load (symbol version not found), even though nothing in the code is actually incompatible. If a new public function had been added in 0.97 one would add a new section to the version script with that specific function, to clearly indicate that that function was added in 0.97. But as long as current functions remain compatible, their version tag should _not_ change. (When I sent the original pull request for the shared library support including symbol versioning, I added a comment to the top of the version script with some information on how the file works.) Could you revert the libisns.vers change back to 0.96 as there were no symbol changes (looking over the git changes)? And maybe release 0.97a or 0.97.1 or so with that fixed? (Just a new tarball/tag, there doesn't have to be a change in the source code, that can still call itself 0.97, because the code is still the same.) (In general, I'd be happy to maintain the version script and the shared library stuff in open-isns so you don't have to care about that - I did add that and I'm probably the primary user of that by means of the Debian packaging - but I would need a bit of a heads-up before a release.) Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] iscsi_ibft,iscsi_boot: remove CAP_SYS_ADMIN restriction for reading entries
On 10/05/2016 08:28 PM, Dan Williams wrote: > On Tue, 2016-10-04 at 19:23 -0400, Konrad Rzeszutek Wilk wrote: >> On Oct 4, 2016 12:11 PM, "Dan Williams" wrote: >>> >>> >>> On Tue, 2016-10-04 at 12:08 -0400, Peter Jones wrote: On Tue, Oct 04, 2016 at 11:03:05AM -0500, Dan Williams wrote: > > > All the iSCSI boot entries are read-only anyway; it's unclear > why > the > CAP_SYS_ADMIN restriction is in place since this information > isn't > particularly sensitive and cannot be changed. Userspace > applications > may want to read this without requiring CAP_SYS_ADMIN for their > entire process just for iBFT info. > > Signed-off-by: Dan Williams Uh, because there are login credentials to the target in there. >>> >>> Fair enough. So can we just check CAP_SYS_ADMIN for the login >>> credentials, and not check it for all the IP details and such? >> >> The only consumer is iscsiadm - which runs as root. So why expose >> this >> information to non root ? > > This is more about root processes dropping unnecessary privileges after > starting. But at least for the network stuff, there doesn't seem to be > a good reason to restrict stuff to root either; like 'ifconfig' doesn't > require root access to display info. > > While NetworkManager currently spawns iscsiadm to read this stuff, NM > only cares about the iBFT network settings and we'd rather just read > sysfs directly instead of spawing and parsing iscsiadm output. So I > wouldn't expect the only consumer to be iscsiadm in the near future. > > Once we do this, NM would also like to drop CAP_SYS_ADMIN after staring > since we don't actually need it for anything except reading iBFT. Maybe CAP_SYS_ADMIN is simply the wrong capability here? If this is supposed to remain restricted, maybe using CAP_NET_ADMIN for the network configuration data (NetworkManager has that, right?) and CAP_SYS_ADMIN for the rest? (Target name, portal, auth data.) That would still be rather restrictive, but better suited for the use case in mind? Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Thanks for merging + other things
Thanks for your response! On 10/03/2016 07:48 PM, Chris Leech wrote: > - Removing the stub code for BSD. We have escaped the interface > abstractions and become heavily Linux only and that's not going to > change. FYI, FreeBSD has it's own initiator implementation anyway: https://www.freebsd.org/doc/handbook/network-iscsi.html#network-iscsi-initiator > - Build system improvements. We could switch everything to autotools if > needed, but there are some directory things that distros are patching > that should be configurable with whatever build system we use. I would really prefer either autotools (and with that I mean autoconf + automake + libtool) or CMake, because those handle a lot of things for you automatically. (Both support out of tree builds, for example, and automatically take care of build flags, compiler selection and cross building; plus they both provide integration with pkg-config.) Since iscsiuio already uses autotools (although the logic there could be improved, automake outputs a lot of warnings currently, subdir-objects is missing, for example), the best choice would probably be to use that throughout. I could work on a pull request for that, but before I do so (because that's going to be a bit of work) I'd like to have some kind of confirmation that that's the way this is headed. Also, if everything is moved to autotools, then the question remains if iscsiuio should still have a separate configure script (and could hence be decoupled from open-iscsi again) or whether one would rather integrate it completely into the upper build system. > - Look at what distros are doing in systemd unit files and try to get > a better set of those standard in the upstream release. FYI: In Debian we do a lot of things due to legacy stuff we still need to support due to the way this was previously integrated. We do want to remove a lot of baggage after the next Debian release (sometime next year). I can provide a detailed explanation of what we currently do (and what of that we want to keep) if you'd be interested. Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Thanks for merging + other things (was: Re: Patches carried in Debian)
Hi again, Many thanks for merging PR #29 and adding them to 2.0.874. I'd still like to hear your thoughts on the two other things I mentioned here: On 09/18/2016 06:42 PM, Christian Seiler wrote: > We carry an additional patch in Debian that removes the callout to > the kernel subdirectory in 'make clean'. Otherwise, make clean > would fail in build environments, because no kernel source would > be installed there. (And Debian's packaging tools always call make > clean during build before building the source.) I would again propose to just remove the kernel/ subdirectory from the tree, because the kernel code is now upstream, and people needing the patches for really old kernels can just grab an old release of open-iscsi, it's not like the kernel patches are updated anymore. (I'd expect that the current code in there contains quite a few bugs that have been fixed for a long time in the upstream kernel.) Finally, there's also this: > Furthermore, we have an additional patch in Debian that replaces > /var/run with /run and /var/lock with /run/lock; I realize that > not all distributions have done this change though, so would you > be willing to take an extra patch that would allow to pass in > these directories via the build system? (And use the /var ones > if nothing is specified.) Would you be agreeable to that? I can create pull requests for both of these things. Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: version 2.0.874 tagged
Hi Chris, On 09/29/2016 08:42 PM, Chris Leech wrote: > There's been a lot of requests for an overdue tagged release with a new > version. I've gone ahead and done that on github, creating version > 2.0.874. I merged a few typo fixes, updated URLs and version numbers, > but there shouldn't be any surprises from what's been on the development > head for a while now. >From my Debian point of view: many, many thanks! Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
iscsiadm --logoutall=all vs. sessions without match in node database
Hello, Recently there has been a bug report in Debian about -U all not logging out of all active iSCSI sessions on shutdown: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838540 I've isolated the problem, and what happens is as follows: 1. An external tool sets up a node configuration manually [1], but makes a small mistake, by not setting a target portal group tag at all, so open-iscsi will default to 1 - instead of the correct value of 257 for that target. (In the case of the bug reporter.) 2. The external tool logs in on that portal via iscsiadm. 3. The login succeeds, but either iscsid or the kernel (I'm not deep enough in the code to know exactly where that happens) figures out "hey, the actual portal target group tag is 257, so use that". Hence, login succeeds, but the node database references the wrong portal group. 4. On shutdown, iscsiadm --logoutall=all is called. The __logout_by_startup callback tries to run idbm_rec_read() on the session, that fails, so it completely skips that session. This behavior in (4) seems wrong to me in two ways: a. If the tpgt can change after login, then the matching against the tpgt should be relaxed. i.e. first try to match the tpgt exactly, if that fails, just try to find the same match but without fixing the tpgt. That way, if a login changed the tpgt implicitly, this would still match the right config with the right session. b. Regardless of that, there could be active iSCSI sessions without a corresponding configuration. For example, if the configuration was wiped accidentally before shutting down the session. Or someone accidentally used iscsistart on a already booted system without knowing what they were doing. In that case, would it not be better if --logoutall=all is specify to not skip that session, even if there's no match in the node database? After all, the manpage says -U all will logout of all active sessions that are NOT onboot, and it doesn't say "all sessions that have a config AND are not onboot". The counterpoint to that would be: if someone were have a setup with root on iSCSI, and the session of the root filesystem not configured in the node database at all (but rather just in some separate config used by the initramfs they were using), then the current behavior treats that as if onboot were set in that case, whereas my proposed change would be treat that as automatic or manual and -U all would also kill that. In Debian that wouldn't be a problem, as we already have logic in the shutdown script to dynamically detect the session on which the root filesystem (and potentially /usr) is located, but other distros probably don't. But maybe we could add --logoutall=reallyall or something? (Maybe with a better name?) I'm mostly interested in fixing (a), because that's what's causing the immediate problem the bug reporter is experiencing. But (b) deserves some consideration as well IMHO. Now of course, the original bug is the external tool generating a static node config with the wrong tpgt - and if open-iscsi were to simply refuse logins in the first place, I'd also be fine with that behavior. But since that's not the case (and it's very likely true that a lot of people are in some way relying on the fact that the tpgt isn't that important at login, so it's not going to be realistic to change that), and the login does succeed anyway, I think the automated logout should as well. I can work on a patch, but before I start, I'd like to hear some thoughts on this first. Thanks! Regards, Christian [1] iscsiadm --mode node --portal ... --targetname ... --op new The portal here is specified by the external tool as only IP:PORT. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Any Stable git commit after 2.0-872?
On 09/19/2016 09:04 PM, Raghu Murugesan wrote: > I am currently using version 2.0-872 in my project. Can anyone suggest a > *stable* version/git commit that I can make use of. (Anything after 2.0-873 > will be better) Well, in Debian I've recently uploaded the current git master, f951a06beb55d7ccc4d9c13a3a83ec2bee96636d. So far it seems to work very well (no regressions in any tests I did, and nobody running Debian sid has complained so far). We've also had a version in Debian (sid first, then testing) for over a month based on git commit 4c1f2d90ef1c73e33d9f1e4ae9c206ffe015a8f9. Current Debian stable (frozen fall 2014) is based on git commit 3b4b45001b6d8412aad76a55347de42d30d694f7 (from 2013), however we do not provide iscsiuio support in stable - and from the amount of fixes added to iscsiuio in the mean time I would not recommend using that commit if you plan to use iscsiuio (I'd rather recommend one of the other commits I mentioned in that case). OTOH, if you want to just use the initiator itself (without the iscsiuio offloading daemon), then that commit is really solid, because it's running on a LOT of Debian stable machines successfully. Note though that the first two commits I mentioned (i.e. the ones not in Debian stable) are after the open-isns split, so you'd need to compile open-isns first before compiling open-iscsi. (open-isns 0.96 works well.) Apart from that though: just from my personal experience in packaging open-iscsi: the changes in git master a well reviewed, so I actually believe that it is perfectly fine to follow git master at the moment. (Of course, check the commit log before upgrading from one snapshot to the next, and judge a bit for yourself.) Should there be no new release of open-iscsi until Debian freezes at the end of the year, the version of open-iscsi we'll be shipping in Debian Stretch will likely be the most current git snapshot at the time of the freeze of Debian. tl;dr version: I'd simply recommend the current git master branch at the moment (see above for the commit id I mean). Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: When is the next release of open-iscsi?
On 09/15/2016 10:28 PM, Raghu Murugesan wrote: > When in next version of open-iscsi planning to be released? As one of the maintainers of open-iscsi in Debian, we'd also like to see a new official release in the not too distant future, because we are currently packaging git snapshots (and are using version numbers like 2.0.873+gitN.ABCDEF01, where N is a counter and ABCDEF01 are the first 8 chars of the git commit hash - not very pretty). The latest git snapshot I just uploaded today. Just as a reference: Debian will freeze around the end of the year, so it'd be great if a new open-iscsi release could happen by the beginning of January the very, very latest, so we could release Debian with a properly released version, and not another git snapshot. Thanks for considering! Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Patches carried in Debian
Hi, I just opened PR #29 that contains most patches we current carry in Debian (the latest package in Debian sid is current git master plus patches): https://github.com/open-iscsi/open-iscsi/pull/29 It would be great if these patches could be merged, so we don't have to carry them downstream anymore. If required, I can also send the patch series to this list. We carry an additional patch in Debian that removes the callout to the kernel subdirectory in 'make clean'. Otherwise, make clean would fail in build environments, because no kernel source would be installed there. (And Debian's packaging tools always call make clean during build before building the source.) I didn't send it here, because to be honest I think the better course of action would be to just remove the kernel directory from the package: this has been in the upstream kernel forever now, and people who really want to support older kernel versions may as well grab an older open-iscsi version to get the patch, as there were no changes there since 2010. So the best course of action would be to just remove the kernel/ subdirectory entirely. (The history would be retained in git anyway.) Thoughts? Furthermore, we have an additional patch in Debian that replaces /var/run with /run and /var/lock with /run/lock; I realize that not all distributions have done this change though, so would you be willing to take an extra patch that would allow to pass in these directories via the build system? (And use the /var ones if nothing is specified.) Thanks! Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: iscsistart takeover vs iface names
Hi, On 06/01/2016 11:35 PM, Mike Christie wrote: > Ccing Christian and dropping list to make sure the mail does not get > lost in his open-iscsi filters. It's actually the other way around: I get emails from the list just fine, but in the end I resorted to creating a gmail account to be able to post to the list, because emails from my real email address were just rejected by the list for no apparent reason. (cc'ing the list again.) > How does debian implement iscsi boot? > > Does it: > 1. Run iscsistart for the root sessions/targets in the initramfs and > then start iscsid during the normal startup procedure and run iscsiadm > at that time for other non boot/root related sessions? Yes. You can find the current code used by Debian (and by extension Ubuntu) in the initramfs here: http://sources.debian.net/src/open-iscsi/2.0.873%2Bgit0.3b4b4500-15/debian/extra/initramfs.local-top/ Basically, there are 3 ways you can boot from iSCSI at the moment in Debian (via the officially supported hook to initramfs-tools): 1. You create a special file /etc/iscsi/iscsi.initramfs (source by the shell in the initramfs) with a couple of settings (ISCSI_TARGET_IP=..., ISCSI_USERNAME=..., etc.). That file is copied into the initramfs image, which then calls iscsistart. If you install Debian on iSCSI via the official installer, it will create this file with the corresponding settings. 2. You create the file /etc/iscsi/iscsi.initramfs with the setting ISCSI_AUTO=true, then the initramfs will use iscsistart -f to auto- configure the iSCSI sessions. (And also iscsistart -N to configure the the network interfaces, if required.) 3. This has been added very recently: root=iscsi:... (RFC 4173 syntax) is now also supported, there you don't need to create any special file, just have the package installed. In that case, also iscsistart will be used. In no case is the iSCSI database or iscsid used in the initramfs at the moment. (That means that you can use the iscsi.initramfs file to configure a session separate from the iscsi database btw.) (Note that dracut is available as an alternative in Debian, and it brings its own iSCSI support. I haven't gotten around to testing that so far, though; but I'm pretty sure it won't work, because dracut does start iscsid in the initramfs since fall of last year IIRC, but due to Debian policies we install the iSCSI database directly in /etc/iscsi instead of /var/lib/..., whereas IIRC the dracut code tries to copy the database from the official upstream location. Making sure dracut also works in Debian with iSCSI is on my TODO list for Debian 9.) The system startup code (once the root file system is mounted) is independent of the initramfs and boils down to basically the following two steps: 1. start iscsid 2. iscisadm -m node --loginall=automatic If a session is configured both in the database as well as the iscsi.initramfs file, iscsiadm will display a warning and return exit code 15 (already logged in), but we use SuccessExitStatus in our systemd service file, so it's not treated as an error. (The shutdown logic is more involved, because we try to detect which sessions are used for the root and /usr filesystems, if any, and only shut down all the _other_ sessions. But we also allow the admins to override that and not shutdown any session at all, in case they have a storage configuration that we don't properly detect.) > 2. Run iscsiadm and iscsid in the initramfs, stop iscsid, and then > restart it and maybe run iscsiadm again for non root/boot related > sessions/targets during the normal startup procedures? We have a low-priority TODO item to think about maybe (perhaps optionally) supporting using iscsid in the initramfs, but haven't gotten around to that so far. Hope that answers your question. That all said, we're not married to the internals of the current approach, so if there were to be good reasons to do something differently, so for example if you decided to drop iscsistart upstream and say the only supported way is to have iscsid running in the initramfs, we'd be open to that, as long as we can support all the potential previous use cases with it. Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: NoPortalsFound
Hi, On 03/25/2016 04:01 PM, Graham Welsh wrote: > ii open-iscsi 2.0.873-3.13.2014 amd64 High That version is not directly from Debian. Either it's based on a very old Debian package and modified - or they packaged open-iscsi themselves, independently of Debian (the Debian revision part of the version looks a bit like a date in US format). Can't give you any details about that version though... > I generated a new initiatorname and received the following : > > InitiatorName=iqn.2005-03.org.open-iscsi:9b96ddaa68f4 > > So, I tried again to connect and failed. I put the intitator name and IP > into the target again, reset tgtd, but no change : You need to restart iscsid before this change works. If your version is somewhat related to an older Debian package, do: service open-iscsi restart (Note: don't do this on Debian systems if there are iSCSI devices mounted. On newer Debian systems you can restart the 'iscsid' service instead, which won't affect mounted devices.) If it was packaged independently by your OS vendor instead, that may or may not be helpful. Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: NoPortalsFound
Hi, (I'm one of the current Debian maintainers of open-iscsi.) On 03/25/2016 04:37 AM, ZER0SEN wrote: > root@control:~# cat /etc/iscsi/initiatorname.iscsi > GenerateName=yes This was specific to Debian up to very recently: the default configuration file initiatorname.iscsi contained GenerateName=yes and the startup script for open-iscsi would detect that and generate a name on the fly. We've changed that in recent versions, so that the initiator name is now generated at package installation time, but older versions still had that. Now the thing is, that I've recently added systemd support in Debian and refactored a lot of the startup logic - and during a short period of time, the startup logic for generating the initiator name was broken (regardless of init system) because of a bug. This was fixed (even before we moved the generation logic to package installation time), but if Univention grabbed the Debian package from the Debian unstable distribution during that period where it was buggy, it would explain why you see this. (Or, maybe they have an extremely old version that had a similar bug.) To check, could you please do: dpkg -l open-iscsi and tell me what version of open-iscsi is running on your system? To solve your immediate problem: you generate a unique initiator name by doing (as root): echo "InitiatorName=$(iscsi-iname)" > /etc/iscsi/initiatorname.iscsi Then look at the contents of the file and that is your unique initiator name (which you can use in the target's access control, for example). Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id
On 03/09/2016 09:05 PM, Mike Christie wrote: > On 03/08/2016 11:21 AM, Chris Leech wrote: >> On Fri, Feb 12, 2016 at 09:38:53AM -0800, Lee Duncan wrote: >>> The scsi_transport_iscsi module already uses the ida_simple >>> routines for managing the target ID, if requested to do >>> so. This change replaces an ever-increasing atomic integer >>> that tracks the session ID itself with the ida_simple >>> family of routines. This means that the session ID >>> will be reclaimed and can be reused when the session >>> is freed. >>> >>> Note that no maximum is placed on this value, though >>> user-space currently only seems to use the lower 24-bits. >>> It seems better to handle this in user space, though, >>> than to limit the value range for the session ID here. >>> >>> Signed-off-by: Lee Duncan >> >> Acked-by: Chris Leech >> > > Dropping lkml and linux-scsi for a moment for some userspace stuff. > > If we do this patch, then we need Chris's sysfs attr cache removal and > in another patch I think we also need to drop the dev_list cache from > open-iscsi/usr/sysfs.c? > > For example, I think we could hit a bug because we could match a session > id but the cached device's parent could be different than before. This will cause problems if I want to use current userspace open-iscsi with a newer kernel version once the kernel patch is merged, right? Example use case: I install a stable version of any long term supported distro (RHEL, SLES, Ubuntu, Debian), but use a newer kernel because I want to install it on newer server hardware. OTOH, I get why you want to make this change in the kernel and I agree with the rationale for it. What about this logic? - still keep an atomic int additionally - pass that atomic int as the start parameter to ida_simple_get - upon return, increment the atomic int (replace value with MAX(current atomic int value, new id) atomically) finally: - if atomic int >= 0x7ff (the max for ida) just use 0 as start value and don't modify the atomic int anymore (then we have wrap around anyway, and then the current code doesn't handle that well anyway, so it doesn't deteriorate) (I'm not a kernel hacker, and I'm assuming that ida_simple_get will use low numbers by default that increase slowly - otherwise this obviously won't work very well.) This is more complicated, but it will preserve current semantics until a wrap-around occurs and not break the current userspace code. Then, in a couple of years or so, we can drop the additional atomic int complication in the kernel and just use ida for ID allocation, once we know that the removal of the cacvhe has been in userspace for long enough. Thoughts? Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Antw: [PATCH] Build system: sort object file lists
Hi, On 02/15/2016 08:38 AM, Ulrich Windl wrote: >>>> Christian Seiler schrieb am 13.02.2016 um >>>> 01:05 in > Nachricht <56be734d.1000...@gmail.com>: >> Hi, >> >> Debian is currently working on making the entire archive build >> reproducibly. <https://reproducible-builds.org/> is a good >> resource describing the motivation behind this effort. >> >> There was one problem that was found in the open-iscsi package >> build system that prevented builds from being reproducible: >> the list of object files generated by the wildcard Makefile >> function are not in a deterministic order, causing changes in >> the output depending on the order in the underlying filesystem. > > Hi! > > I wonder: Would adding those objects to an object library (and use > that library to add the needed objects) also fix this problem? (I > thought objects in a library are sorted) Unfortunately not, that would suffer from the same problem - the order of the object files determines to some extent the order of the functions in the final executable. An object library is not really that much different than from specifying a list of object files explicitly, and the order in which they were added to the object library matters. The result of the build is of course functionally equivalent (which is why the current state of having a random order at build time depending on the underlying file system is not a problem in terms of functionality), but not bit-for-bit identical, which is what reproducible builds are about. (Whether using an object library during the open-iscsi build process is a good idea irrespective of reproducible builds is something I don't have any opinion on.) Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
[PATCH] Build system: sort object file lists
Hi, Debian is currently working on making the entire archive build reproducibly. <https://reproducible-builds.org/> is a good resource describing the motivation behind this effort. There was one problem that was found in the open-iscsi package build system that prevented builds from being reproducible: the list of object files generated by the wildcard Makefile function are not in a deterministic order, causing changes in the output depending on the order in the underlying filesystem. I've attached a patch against the current git master that sorts the list of object files within the Makefile, making the order deterministic and allowing reproducible builds to be made. See also: <https://reproducible-builds.org/docs/stable-inputs/> It would be great if you could apply this patch upstream, so we don't have to carry it in Debian. Thanks! Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout. From a919d214d10870a54c6a5e383a19a6e82e5f8a54 Mon Sep 17 00:00:00 2001 From: Christian Seiler Date: Sat, 13 Feb 2016 00:56:19 +0100 Subject: [PATCH] Build system: sort object file lists The object file list generated by the wildcard Makefile function is not deterministic, because it may change depending on the underlying file system. Use the sort function to make the list deterministic in these cases, to be able to build open-iscsi deterministically. See <https://reproducible-builds.org/> for further details. Signed-off-by: Christian Seiler --- usr/Makefile| 4 ++-- utils/fwparam_ibft/Makefile | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/usr/Makefile b/usr/Makefile index 5ac0726..277ac6a 100644 --- a/usr/Makefile +++ b/usr/Makefile @@ -34,7 +34,7 @@ CFLAGS += $(WARNFLAGS) -I../include -I. -D$(OSNAME) $(IPC_CFLAGS) PROGRAMS = iscsid iscsiadm iscsistart # libc compat files -SYSDEPS_SRCS = $(wildcard ../utils/sysdeps/*.o) +SYSDEPS_SRCS = $(sort $(wildcard ../utils/sysdeps/*.o)) # sources shared between iscsid, iscsiadm and iscsistart ISCSI_LIB_SRCS = iscsi_util.o io.o auth.o iscsi_timer.o login.o log.o md5.o \ sha1.o iface.o idbm.o sysfs.o host.o session_info.o iscsi_sysfs.o \ @@ -45,7 +45,7 @@ ISCSI_LIB_SRCS = iscsi_util.o io.o auth.o iscsi_timer.o login.o log.o md5.o \ INITIATOR_SRCS = initiator.o scsi.o actor.o event_poll.o mgmt_ipc.o kern_err_table.o # fw boot files -FW_BOOT_SRCS = $(wildcard ../utils/fwparam_ibft/*.o) +FW_BOOT_SRCS = $(sort $(wildcard ../utils/fwparam_ibft/*.o)) # core discovery files DISCOVERY_SRCS = $(FW_BOOT_SRCS) strings.o discovery.o diff --git a/utils/fwparam_ibft/Makefile b/utils/fwparam_ibft/Makefile index 773d8eb..ade8a56 100644 --- a/utils/fwparam_ibft/Makefile +++ b/utils/fwparam_ibft/Makefile @@ -21,7 +21,7 @@ # "Prasanna Mumbai" # -SYSDEPS_OBJS = $(wildcard ../sysdeps/*.o) +SYSDEPS_OBJS = $(sort $(wildcard ../sysdeps/*.o)) OBJS := fw_entry.o fwparam_sysfs.o $(SYSDEPS_OBJS) ../../usr/iscsi_net_util.o OBJS += prom_lex.o prom_parse.tab.o fwparam_ppc.o CLEANFILES = $(OBJS) *.output *~ -- 2.1.4
[PATCH] Some spelling fixes in man pages and messages
Hi, I've noticed some spelling mistakes in man pages and messages. Patch is attached. Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout. >From 7af74c4f13da8da003ac310153a8cfdbdaac4c0a Mon Sep 17 00:00:00 2001 From: Christian Seiler Date: Sun, 31 Jan 2016 19:47:46 +0100 Subject: [PATCH] Some spelling fixes in man pages and messages Signed-off-by: Christian Seiler --- doc/iscsi_discovery.8 | 4 ++-- doc/iscsiadm.8| 18 +- doc/iscsistart.8 | 2 +- usr/iscsistart.c | 4 ++-- usr/login.c | 2 +- 5 files changed, 15 insertions(+), 15 deletions(-) diff --git a/doc/iscsi_discovery.8 b/doc/iscsi_discovery.8 index e28065c..807fce3 100644 --- a/doc/iscsi_discovery.8 +++ b/doc/iscsi_discovery.8 @@ -34,7 +34,7 @@ init.d startup script. .\" .SH OPTIONS .TP .BI [-p=]\fIport\-number\fP -set the port number (defualt is 3260). +set the port number (default is 3260). .TP .BI [-d] print debugging information. @@ -52,7 +52,7 @@ force the transport specified by the argument of the \-t flag. manual startup - will set manual startup (default is automatic startup). .TP .BI [-l] -login - login to the new discovered nodes (defualt is false). +login - login to the new discovered nodes (default is false). .SH AUTHOR Written by Dan Bar Dov diff --git a/doc/iscsiadm.8 b/doc/iscsiadm.8 index c7d8c92..5c91e59 100644 --- a/doc/iscsiadm.8 +++ b/doc/iscsiadm.8 @@ -228,7 +228,7 @@ display help text and exit .TP \fB\-H\fR, \fB\-\-host=\fI[hostno|MAC]\fR -The host agrument specifies the SCSI host to use for the operation. It can be +The host argument specifies the SCSI host to use for the operation. It can be the scsi host number assigned to the host by the kernel's scsi layer, or the MAC address of a scsi host. @@ -251,10 +251,10 @@ layer's interface name (iface.net_ifacename), and it must have the driver/transport_name The available drivers/iscsi_transports are tcp (software iSCSI over TCP/IP), -iser (software iSCSI over infinniband), or qla4xxx (Qlogic 4 HBAs). The +iser (software iSCSI over InfiniBand), or qla4xxx (Qlogic 4 HBAs). The hwaddress is the MAC address or for software iSCSI it may be the special value "default" which directs the initiator to not bind the session to a -specific hardware resource and instead allow the network or infinniband layer +specific hardware resource and instead allow the network or InfiniBand layer to decide what to do. There is no need to create a iface config with the default behavior. If you do not specify a iface, then the default behavior is used. @@ -268,7 +268,7 @@ In discovery mode multiple interfaces can be specified by passing in multiple "iscsiadm \-m discoverydb \-t st \-p ip:port \-I iface0 \-I iface2 \-\-discover" Will direct iscsiadm to setup the node db to create records which will create -sessions though the two intefaces passed in. +sessions though the two interfaces passed in. In node mode, only a single interface is supported in each call to iscsiadm. .IP @@ -303,7 +303,7 @@ This option is only valid for discovery and node modes. .TP \fB\-L\fR, \fB\-\-loginall==\fI[all|manual|automatic]\fR For node mode, login all sessions with the node or conn startup values passed -in or all running sesssion, except ones marked onboot, if all is passed in. +in or all running session, except ones marked onboot, if all is passed in. .IP This option is only valid for node mode (it is valid but not functional for session mode). @@ -352,7 +352,7 @@ In discovery mode, if the \fIrecid\fR and new operation is passed in, but the \f .IP \fIupdate\fR will update the \fIrecid\fR with \fIname\fR to the specified \fIvalue\fR. In discovery node, if iscsiadm is performing discovery the \fIrecid\fR, \fIname\fR and \fIvalue\fR arguments are not needed. The update operation will operate on the portals returned by the target, and will update the node records with info from the config file and command line. .IP -\fIshow\fR is the default behaviour for node, discovery and iface mode. It is +\fIshow\fR is the default behavior for node, discovery and iface mode. It is also used when there are no commands passed into session mode and a running sid is passed in. \fIname\fR and \fIvalue\fR are currently ignored when used with \fIshow\fR. @@ -445,7 +445,7 @@ This option is only valid for node and session mode. .TP \fB\-U\fR, \fB\-\-logoutall==\fI[all,manual,automatic]\fR logout all sessions with the node or conn startup values passed in or all -running sesssion, except ones marked
Re: I/O errors with recent Linux versions
On 01/29/2016 09:41 PM, Mike Christie wrote: >> So something must have also changed with the initiator some >> time after 3.16 that it now triggers the bug... > > The block layer used to cap block/fs IO at I think around 1024 sectors. > It now lets you go up to the a min of the driver and what the target > says it can handle. > > Check out > > /sys/block/sdX/queue/max_hw_sectors_kb > and > /sys/block/sdX/queue/max_sectors_kb > > in the different kernel versions. In the newer kernel you will see > max_sectors_kb a lot higher. You can work around the problem by manually > setting that lower. Yes. max_hw_sectors_kb is always 32767, but with the older kernel max_sectors_kb is 512, with the newer one it's 8192. Setting that down to 4096 doesn't give me any errors anymore, even with the newer kernel on the initiator side. (Target is still on the old kernel, as I'd have to reboot that machine, so that'll have to wait until tomorrow.) However: > When you login to the target do a > > sg_inq -p 0xb0 /dev/sdX > > and check if the optimal/max transfer lengths are 0. For the newer > versions it should give you a non zero value. No, even with the old target (still have to try newer one) I get the following output: VPD INQUIRY: Block limits page (SBC) Maximum compare and write length: 1 blocks Optimal transfer length granularity: 1 blocks Maximum transfer length: 16384 blocks Optimal transfer length: 16384 blocks Maximum prefetch transfer length: 0 blocks I assume 1 block == 512 bytes, so 16ki blocks would be 8 MiB. This matches max_sectors_kb on the new kernel. So it seems that the new kernel takes the maximum transfer length from LIO and uses it as max_sectors_kb (which seems to be correct behavior to me), while the old kernel just assumes 1024 blocks as the limit. I therefore think the new kernel does behave correctly, because the limit is set according to what LIO reports - it just appears to be the case that my target can't actually properly handle what it reports, so this appears to be a definite bug in at least older LIO versions. I'll check with a newer kernel on the target side and go on from there (if it fixes the issue, I'll do some bisecting, if it doesn't, I'll report to the LIO people). Thanks for all your help, very much appreciated. Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: I/O errors with recent Linux versions
On 01/29/2016 09:07 PM, Mike Christie wrote: > On 01/27/2016 05:17 PM, Christian Seiler wrote: >> The test setup is quite simple: LIO target running on the host with >> fileio backend (I tried both Debian Jessie host with 3.16 kernel and >> Ubuntu 15.04 host with 3.19 kernel, no difference), initiator >> running inside a libvirt/KVM instance (Debian sid); nothing special >> about the setup otherwise. (The target itself shows no problems.) > > So there are no other log messages on the LIO box? Something about max > sectors being violated or a memory allocation failure? I didn't notice that earlier, but I get: kernel: fd_do_rw() write returned -22 (-22 is -EINVAL) Weird. I could have sworn that when I first encountered the problem I didn't see anything in the target's logs... Obviously I'm mistaken and I'm very sorry that I didn't notice that earlier. > What kernel version is LIO running on in these tests? LIO targets I've tried: - 3.16.7-ckt20 (Debian Jessie) - 3.19.0-43-generic (Ubuntu 15.04) I'll try a newer version tomorrow and see if the problem persists. > I think you are hitting a bug where the block layer is now sending > really large IOs that LIO cannot handle or does not want to. > > There was a change in LIO to better tell the the initiator what size to > use, so get the LIO kernel version so we can check that. > > You can still hit memory allocation failures in LIO and hit a similar > issue, but with just a dd of 4MB IOs you should not hit the problem. I just checked: 8388608 bytes (8 MiB) in a single dd are fine, 8388609 (1 byte more) consistently reproduces the error. Ok, so this is then not actually an initiator problem but a LIO target problem... Ok, thanks, then I'll investigate in that direction (and ask the LIO people for help if I run into problems). But I'm curious - why haven't I seen any problems with older kernel versions for the initiator? I've been using the same LIO target for a long time (3.16 was released 1.5 years ago) and I've never had any problems with it, with multiple different kernel versions for the initiator (going back as far as 3.2). So something must have also changed with the initiator some time after 3.16 that it now triggers the bug... Btw. is there any setting (sysctl or iscsid configuration option) to adjust the IO size to work around the target problem? Thanks a lot for your help! Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
I/O errors with recent Linux versions
Hi, While working on improvements w.r.t. open-iscsi userspace package in Debian, I've stumbled upon a weird kernel bug in recent kernel versions that makes the iSCSI initiator unusable. The test setup is quite simple: LIO target running on the host with fileio backend (I tried both Debian Jessie host with 3.16 kernel and Ubuntu 15.04 host with 3.19 kernel, no difference), initiator running inside a libvirt/KVM instance (Debian sid); nothing special about the setup otherwise. (The target itself shows no problems.) iSCSI login works perfectly fine, reading data from the iSCSI shows no problems otherwise; writing small amounts of data to the iSCSI device also works fine. But writing a bit more at once to the iSCSI device will cause I/O errors in the kernel. Sample messages: [ 21.473911] sd 2:0:0:0: [sda] tag#3 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 21.473914] sd 2:0:0:0: [sda] tag#3 Sense Key : Not Ready [current] [ 21.473916] sd 2:0:0:0: [sda] tag#3 Add. Sense: Logical unit communication failure [ 21.473917] sd 2:0:0:0: [sda] tag#3 CDB: Write(10) 2a 00 00 38 15 d8 00 20 28 00 [ 21.473918] blk_update_request: I/O error, dev sda, sector 3675608 [ 21.473939] EXT4-fs warning (device sda1): ext4_end_bio:329: I/O error -5 writing to inode 46 (offset 50331648 size 4214784 starting block 459707) [ 21.473941] Buffer I/O error on device sda1, logical block 457403 This is obviously a kernel problem, as using Debian Jessie's 3.16 kernel with the same userland will work perfectly fine and not produce any I/O errors, but with more recent kernels this is trivially reproducible for me. I had reported this in the Debian bugtracker against the kernel a while ago, and somebody mentioned that this problem should have been fixed in 4.4, but once I got around to testing 4.4, I can still reproduce that problem. Just now I tried to use the current upstream Linux git branch (basically 4.5-rc1 + the things that Linus already pulled since then as of writing this email) and the problem still persists. The Debian bugreport can be found under: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805252 Further details, including more log messages, can be found there. I'm not an expert on the block device driver subsystem in the kernel, so I don't really know where to start debugging this, so any help would be appreciated. Thank you. Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] Reformat man page synopsis sections
On 06/02/2015 07:40 PM, Mike Christie wrote: > Can other people see the original email below on the list? I got a mail, > but I am not seeing it on the open-iscsi list web interface. It's on the web interface, just well hidden: https://groups.google.com/forum/#!topic/open-iscsi/7Bj9MI-S_Wc (Search for 'Reformat man page') The problem here is that the web interface uses a flat view, which makes it difficult to find things in longer threads. Also, AFAICT there's no way to directly link individual messages. Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Antw: [PATCH 2/4] buildsys: respect CFLAGS and LDFLAGS from the outside
On 05/29/2015 01:02 PM, Ulrich Windl wrote: >>>> Christian Seiler schrieb am 29.05.2015 um 12:43 in > Nachricht <556842d3.8070...@iwakd.de>: >> - Sometimes you need to debug something and disable optimization for >>that. Then you might need want to rebuild a package with a different >>-O level than the package typically has. Of course, one can >>tediously look at the means that different software provides to do >>so (if at all) - or one can just assume that setting CFLAGS="-O0" >>before running configure / make will do the trick. > > Yes, but someone could also define `CC="gcc -O0"' and it might work. > My proposal was mostly _against_ such misusing of flags. Ok, CC="gcc -O0" is definitely misuse, because some build systems will assume that CC contains the compiler directly (without options), which will break them. But why do you consider setting CFLAGS="-O0" to be misuse? I consider that possibility to be a feature, not a bug. (And according to the way most build systems are structured, I'm not alone in that.) > Also, you cannot easily _add_ flags to the existing set of flags. I really don't get what you mean here. Who should add flags to what existing set? >> - There is a goal to harden as much software as possible in Debian, so >>there's a recommendation that things like -fstack-protector-strong >>are to be used (unless the software doesn't work otherwise). > > IMHO this is useful for the developer to fix his/her bugs, but for > production systems it will just make software bigger and slower. I disagree here vehemently that it's only useful for development (in fact, I would assert that it's rather useless for development and only really useful in production), but this would go off a tangent, so I'll leave it at that. For the purposes of the discussion here let me just say that Debian also activates other measures as well, some of those with a completely negligible performance impact. Thus the original point I was trying to make, namely that there are legitimate use cases for modifying build flags by default, still stands. >> (Of course, checking that the compiler supports your flag is always >> better, there is a macro for that; and things like pthread actually >> have a standardized macro that do that automatically.) >> Alternatively, you can set it directly in Makefile.am via >> AM_CFLAGS = -additional-flags >> which will automatically be added to the list of flags. > > With all these solutions we have the problem that the user who > compile (configres) the software has to be kind of an expert to know > al the flags and syntaxes. You probably are such an expert. I don't > know all of these. What's your point here? That people could set flags that they shouldn't set? Sure. I'm not saying people SHOULD override the compiler flags externally if they don't know what they're doing, I'm just saying that people who do know what they're doing should be able to do so. > I also hope you got what I tried to say. No, sorry, I really have no idea where you're coming from, at least from a big picture kind of perspective. The reason I sent the original patch is, in a nutshell: - there are legitimate use cases for overriding flags externally - there's a standard way of doing so that the vast majority of projects follow => thus the patch updates the build system to support that method, because it will make life easier for people Nothing more, nothing less. What exactly do you want to achieve? And why? And perhaps more importantly, that's not clear to me at all after re-reading your emails: do you object to my patch? Or are you just throwing general ideas around? Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
[PATCH] Reformat man page synopsis sections
Hi, (Hoping this gets through, Google Groups has recently rejected messages by me for no apparent reason.) Thanks for your suggestions. On 29.05.2015 08:49, Ulrich Windl wrote: > A comment on likes like this: >> +\fBiscsiadm\fR \-m discoverydb [ \-hV ] [ \-d debug_level ] [ \-P >> printlevel ] > > I think such lines should be restructured for redability and better diff-ing > like this: I've created a patch that implements this for iscsiadm.8 and attached it to this email. The patch applies on top of the escaping fixes of 4/4. Best regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout. >From 63d1da3427a18581b60a2ed39c7cf1e143cfd5aa Mon Sep 17 00:00:00 2001 From: Christian Seiler Date: Fri, 29 May 2015 13:35:05 +0200 Subject: [PATCH] Reformat man page synopsis sections Reformat the synopsis section of the iscsiadm(8) and iscsi_discovery(8) man pages to follow traditional man page style more closely. Thanks to Ulrich Windl for the suggestion. --- doc/iscsi_discovery.8 | 12 +++- doc/iscsiadm.8| 172 +- 2 files changed, 166 insertions(+), 18 deletions(-) diff --git a/doc/iscsi_discovery.8 b/doc/iscsi_discovery.8 index a4affc6..e28065c 100644 --- a/doc/iscsi_discovery.8 +++ b/doc/iscsi_discovery.8 @@ -8,7 +8,17 @@ .SH NAME iscsi_discovery \- discover iSCSI targets .SH SYNOPSIS -.B iscsi_discovery [-p ] [-d] [-t [-f]] [-m] [-l] +.B iscsi_discovery +.I +.RB [ -p +.IR ] +.RB [ -d ] +.RB [\ -t +.IR +.RB [ -f ] +.R ] +.RB [ -m ] +.RB [ -l ] .SH DESCRIPTION Perform send-targets discovery to the specified IP. If a discovery record diff --git a/doc/iscsiadm.8 b/doc/iscsiadm.8 index 64ef2e0..f046236 100644 --- a/doc/iscsiadm.8 +++ b/doc/iscsiadm.8 @@ -2,23 +2,161 @@ .SH NAME iscsiadm \- open-iscsi administration utility .SH SYNOPSIS -\fBiscsiadm\fR \-m discoverydb [ \-hV ] [ \-d debug_level ] [ \-P printlevel ] [ \-I iface \-t type \-p ip:port [ \-lD ] ] | [ [ \-p ip:port -t type ] \ -[ \-o operation ] [ \-n name ] [ \-v value ] [ \-lD ] ] - -\fBiscsiadm\fR \-m discovery [ \-hV ] [ \-d debug_level ] [ \-P printlevel ] [ \-I iface \-t type \-p ip:port [ \-l ] ] | [ [ \-p ip:port ] [ \-l | \-D ] ] - -\fBiscsiadm\fR \-m node [ \-hV ] [ \-d debug_level ] [ \-P printlevel ] [ \-L all,manual,automatic ] [ \-U all,manual,automatic ] [ \-S ] [ [ \-T targetname \-p ip:port \-I iface ] [ \-l | \-u | \-R | \-s] ] -[ [ \-o operation ] [ \-n name ] [ \-v value ] [ \-p ip:port ] ] - -\fBiscsiadm\fR \-m session [ \-hV ] [ \-d debug_level ] [ \-P printlevel ] [ \-r sessionid | sysfsdir [ \-R ] [ \-u | \-s | \-o new ] ] - -\fBiscsiadm\fR \-m iface [ \-hV ] [ \-d debug_level ] [ \-P printlevel ] [ \-I ifacename | \-H hostno|MAC ] [ [ \-o operation ] [ \-n name ] [ \-v value ] ] [ \-C ping [ \-a ip ] [ \-b packetsize ] [ \-c count ] [ \-i interval ] ] - -\fBiscsiadm\fR \-m fw [ \-d debug_level ] [\-l] - -\fBiscsiadm\fR \-m host [ \-P printlevel ] [ \-H hostno|MAC ] [ [ \-C chap [ \-x chap_tbl_idx ] ] | [ \-C flashnode [ \-A portal_type ] [ \-x flashnode_idx ] ] | [ \-C stats ] ] [ [ \-o operation ] [ \-n name ] [ \-v value ] ] - -\fBiscsiadm\fR \-k priority +.B iscsiadm +.B \-m discoverydb +.RB [ \-hV ] +.RB [ \-d +.IR debug_level ] +.RB [ \-P +.IR printlevel ] +.R [\ +.BI \-I\ iface\ \-t\ type\ \-p\ ip:port +.RB [ \-lD ] +.R ] | [ +.RB [ \-p +.I ip:port +.B \-t +.IR type ] +.RB [ \-o +.IR operation ] +.RB [ \-n +.IR name ] +.RB [ \-v +.IR value ] +.RB [ \-lD ] +.R ] + +.B iscsiadm +.B \-m discovery +.RB [ \-hV ] +.RB [ \-d +.IR debug_level ] +.RB [ \-P +.IR printlevel ] +.R [\ +.BI \-I\ iface\ \-t\ type\ \-p\ ip:port +.RB [ \-l ] +.R ] | [ +.RB [ \-p +.IR ip:port ] +.RB [ \-l | \-D ] +.R ] + +.B iscsiadm +.B \-m node +.RB [ \-hV ] +.RB [ \-d +.IR debug_level ] +.RB [ \-P +.IR printlevel ] +.RB [ \-L +.IR all,manual,automatic ] +.RB [ \-U +.IR all,manual,automatic ] +.RB [ \-S ] +.R [ +.RB [ \-T +.IB targetname\ \-p\ ip:port\ \-I\ iface +.R ] +.RB [ \-l | \-u | \-R | \-s ] +.R ] +.R [ +.RB [ \-o +.IR operation ] +.RB [ \-n +.IR name ] +.RB [ \-v +.IR value ] +.RB [ \-p +.IR ip:port ] +.R ] + +.B iscsiadm +.B \-m session +.RB[ \-hV ] +.RB [ \-d +.IR debug_level ] +.RB [ \-P +.IR printlevel ] +.R [ +.B \-r +.IR sessionid | sysfsdir +.RB [ \-R ] +.RB [ \-u | \-s | \-o +.IR new ] +.R ] + +.B iscsiadm +.B \-m iface +.RB [ \-hV ] +.RB [ \-d +.IR debug_level ] +.RB [ \-P +.IR printlevel ] +.R [ +.BI \-I\ ifacename +.R | +.BI \-H\ hostno|MAC +.R ] +.R [ +.RB [ \-o +.IR operation ] +.RB [ \-n +.IR name ] +.RB [ \-v +.IR value ] +
Re: Antw: [PATCH 2/4] buildsys: respect CFLAGS and LDFLAGS from the outside
On 05/29/2015 08:19 AM, Ulrich Windl wrote: > Some remarks on the CFLAGS thing: > In one of my projects I used this approach for messing with CFLAGS: > -- > CFLAGS=-pthread > CWARNFLAGS=-Wall -Wextra -Wshadow > COPTFLAGS=-pipe -O2 > CDEBUGFLAGS=-g -fstack-protector-all > CFLAGS+=$(CWARNFLAGS) > CFLAGS+=$(COPTFLAGS) > #CFLAGS+=$(CDEBUGFLAGS) > LDFLAGS=-lpthread -lrt > -- > It's somewhat GNU-makish, but you can easily switch CFLAGS by > (un)commenting some of the "CFLAGS+=" lines. > [...] > So my CFLAGS are the absolute minimum required for a correct compile, > and everything else are extras. The code you posted has the opposite effect of what my patch wants to achieve. There appears to be some confusion as to the purpose of my patch, so maybe I should go a bit into detail about what the point here is. When compiling software, either for distributions that want to create a package from it, or for end users that want to call it, one will often want to set some global compiler and linker flags to influence package build. - Sometimes you need to debug something and disable optimization for that. Then you might need want to rebuild a package with a different -O level than the package typically has. Of course, one can tediously look at the means that different software provides to do so (if at all) - or one can just assume that setting CFLAGS="-O0" before running configure / make will do the trick. - When compiling with a compiler other than gcc, you might need to add some flags in order to make it work. - There is a goal to harden as much software as possible in Debian, so there's a recommendation that things like -fstack-protector-strong are to be used (unless the software doesn't work otherwise). It has long been standard practice among open source projects that if external CC, CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS, ... are supplied when building, those flags will influence the build. So what one typically does is partition the CFLAGS into to sets: those required for compilation (such as -pthread) and a default set of flags if no external ones are specified. For example, if you use a default autoconf + automake setup, these will typically set -O2 -g as the default set of flags (if on gcc and the compiler supports -g). But if one does CFLAGS="-sometingelse" ./configure or ./configure CFLAGS="-sometingelse" it will use -somethingelse instead of -O2 -g. Same thing with the other environment variables. And those flags that are required to make the package compile should simply be added to the current set of flags. In a standard autoconf and automake setup, you can do it in configure.ac along the lines of: CFLAGS+=" -additional-flags" (Of course, checking that the compiler supports your flag is always better, there is a macro for that; and things like pthread actually have a standardized macro that do that automatically.) Alternatively, you can set it directly in Makefile.am via AM_CFLAGS = -additional-flags which will automatically be added to the list of flags. Since this is somewhat standardized, this has the great advantage that you don't need to invest time into figuring out how each different piece of software requires to change its own build flags. If you package things for your distribution, there are often a lot of automatisms that use this mechanism to provide set default set of flags - and you don't have to do anything for all these things to just work[tm]. But if a package doesn't do it the standard way, then you have to work around all these sorts of things. But your piece of code goes even further than than a custom mechanism: it doesn't provide a way to influence CFLAGS externally at all! With a custom mechanism, you can figure it out (both as a user that wants to compile it as well as a packager) and then use it. But if you hard-code CFLAGS = ... in your Makefile (as per your example), one actually needs to patch the software to achieve this goal. Now what is the state of open-iscsi's current git? - There's a custom mechanism for setting CFLAGS by the way of a variable named OPTFLAGS. It mostly works, with a couple of excpetions: - OPTFLAGS is not properly respected in utils/sysdeps/Makefile because while it's referenced there, -O2 and -g are appended in all cases. - OPTFLAGS is not properly respected for the compilation of iscsiuio for two reasons: - iscsiuio/configure.ac explicitly overrides CFLAGS - top-level Makefile doesn't pass CFLAGS="$(OPTFLAGS)" to iscsiuio's configure statement (as it does with open-isns) - LDFLAGS are not used in the implicit linker rules for the binaries, thus not being honored if set (open-iscsi doesn't need any custom ones here) - other variables, such as CPPFLAGS and CC are indeed honored, because open-iscsi uses implicit rules for its iscsid etc. code and automake for open-isns + iscsiui. And there it automatically
[PATCH 4/4] Spelling and escaping error fixes.
From: Ritesh Raj Sarraf
---
doc/iscsiadm.8 | 14 +++---
usr/auth.c | 2 +-
usr/initiator_common.c | 2 +-
usr/netlink.c | 2 +-
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/iscsiadm.8 b/doc/iscsiadm.8
index 05793b2..64ef2e0 100644
--- a/doc/iscsiadm.8
+++ b/doc/iscsiadm.8
@@ -2,10 +2,10 @@
.SH NAME
iscsiadm \- open-iscsi administration utility
.SH SYNOPSIS
-\fBiscsiadm\fR \-m discoverydb [ \-hV ] [ \-d debug_level ] [ \-P printlevel ]
[ \-I iface \-t type \-p ip:port [ \-lD ] ] | [ [ -p ip:port -t type ] \
+\fBiscsiadm\fR \-m discoverydb [ \-hV ] [ \-d debug_level ] [ \-P printlevel ]
[ \-I iface \-t type \-p ip:port [ \-lD ] ] | [ [ \-p ip:port -t type ] \
[ \-o operation ] [ \-n name ] [ \-v value ] [ \-lD ] ]
-\fBiscsiadm\fR \-m discovery [ \-hV ] [ \-d debug_level ] [ \-P printlevel ] [
\-I iface \-t type \-p ip:port [ \-l ] ] | [ [ -p ip:port ] [ \-l | \-D ] ]
+\fBiscsiadm\fR \-m discovery [ \-hV ] [ \-d debug_level ] [ \-P printlevel ] [
\-I iface \-t type \-p ip:port [ \-l ] ] | [ [ \-p ip:port ] [ \-l | \-D ] ]
\fBiscsiadm\fR \-m node [ \-hV ] [ \-d debug_level ] [ \-P printlevel ] [ \-L
all,manual,automatic ] [ \-U all,manual,automatic ] [ \-S ] [ [ \-T targetname
\-p ip:port \-I iface ] [ \-l | \-u | \-R | \-s] ]
[ [ \-o operation ] [ \-n name ] [ \-v value ] [ \-p ip:port ] ]
@@ -70,15 +70,15 @@ Specify the submode for mode. op must be name of submode.
Currently iscsiadm support ping as submode for iface. For example,
-iscsiadm -m iface -I ifacename -C ping -a ipaddr -b packetsize -c count -i
interval
+iscsiadm \-m iface \-I ifacename \-C ping \-a ipaddr \-b packetsize \-c count
\-i interval
For host, it supports chap , flashnode and stats as submodes. For example,
-iscsiadm -m host -H hostno -C chap -x chap_tbl_idx -o operation
+iscsiadm \-m host \-H hostno \-C chap \-x chap_tbl_idx \-o operation
-iscsiadm -m host -H hostno -C flashnode -x flashnode_idx -o operation
+iscsiadm \-m host \-H hostno \-C flashnode \-x flashnode_idx \-o operation
-iscsiadm -m host -H hostno -C stats
+iscsiadm \-m host \-H hostno \-C stats
.TP
\fB\-d\fR, \fB\-\-debug=\fIdebug_level\fP
@@ -127,7 +127,7 @@ are experimental and the use is not supported as a stable
interface yet.
In discovery mode multiple interfaces can be specified by passing in multiple
\-I/\-\-interface instances. For example,
-"iscsiadm \-m discoverydb \-t st \-p ip:port \-I iface0 \-I iface2 --discover"
+"iscsiadm \-m discoverydb \-t st \-p ip:port \-I iface0 \-I iface2
\-\-discover"
Will direct iscsiadm to setup the node db to create records which will create
sessions though the two intefaces passed in.
diff --git a/usr/auth.c b/usr/auth.c
index 1e72547..00b4388 100644
--- a/usr/auth.c
+++ b/usr/auth.c
@@ -2002,7 +2002,7 @@ acl_dbg_status_to_text(int dbg_status)
"AuthMethod negotiation failed",
"AuthMethod negotiated to none",
"CHAP algorithm negotiation failed",
- "CHAP challange reflected",
+ "CHAP challenge reflected",
"Local password same as remote",
"Local password not set",
"CHAP identifier bad",
diff --git a/usr/initiator_common.c b/usr/initiator_common.c
index e30e419..ee856b3 100644
--- a/usr/initiator_common.c
+++ b/usr/initiator_common.c
@@ -65,7 +65,7 @@ int iscsi_setup_authentication(struct iscsi_session *session,
if (auth_cfg->username_in[0] || auth_cfg->password_in_length) {
/* sanity check the config */
if (auth_cfg->password_length == 0) {
- log_warning("CHAP configuratoin has incoming "
+ log_warning("CHAP configuration has incoming "
"authentication credentials but has no "
"outgoing credentials configured.");
return EINVAL;
diff --git a/usr/netlink.c b/usr/netlink.c
index 57d4693..2b85efe 100644
--- a/usr/netlink.c
+++ b/usr/netlink.c
@@ -942,7 +942,7 @@ ktransport_ep_disconnect(iscsi_conn_t *conn)
iov[1].iov_len = sizeof(ev);
rc = __kipc_call(iov, 2);
if (rc < 0) {
- log_error("connnection %d:%d transport disconnect failed for "
+ log_error("connection %d:%d transport disconnect failed for "
"ep %" PRIu64 " with error %d.", conn->session->id,
conn->id, conn->transport_ep_handle, rc);
} else
--
2.1.4
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
[PATCH 3/4] Remove outdated Debian packaging code.
There are now official Debian and Ubuntu packages for open-iscsi that
were originally based on this code but have been updated with new
versions. The current packaging code on the other hand here hasn't been
updated in 10 years and is out of date (probably doesn't even build
anymore).
Remove it, this is better maintained downstream in the respective
distributions, especially when it comes to integration with the boot
process.
---
debian/README.Debian | 44 -
debian/changelog | 6 --
debian/compat | 1 -
debian/control | 27
debian/control.modules.in | 20 --
debian/copyright | 12
debian/dirs| 3 -
debian/docs| 4 --
debian/postinst.modules.in | 11
debian/rules | 152 -
debian/rules.modules | 39
11 files changed, 319 deletions(-)
delete mode 100644 debian/README.Debian
delete mode 100644 debian/changelog
delete mode 100644 debian/compat
delete mode 100644 debian/control
delete mode 100644 debian/control.modules.in
delete mode 100644 debian/copyright
delete mode 100644 debian/dirs
delete mode 100644 debian/docs
delete mode 100644 debian/postinst.modules.in
delete mode 100644 debian/rules
delete mode 100644 debian/rules.modules
diff --git a/debian/README.Debian b/debian/README.Debian
deleted file mode 100644
index 98ebd23..000
--- a/debian/README.Debian
+++ /dev/null
@@ -1,44 +0,0 @@
-linux-iscsi for Debian
-
-The linux-iscsi package contains the userspace portion the Linux iSCSI project.
-It has a dependency on the linux-iscsi-modules package, which needs to be
built from the linux-iscsi-modules-source against the specific kernel version
running
-on your system.
-
-Building
-
-Modules cannot be built against the kernel-headers alone. You will need
-to extract and configure your kernel tree, then use the make-kpkg command
-(from the kernel-package package) to build a new kernel and modules.
-See the make-kpkg man page, particularly the modules-image section. The
-following example shows how to build the linux-iscsi-modules package; just
-substitute the appropriate version strings. Follow these instructions
-(as root) in order to build the linux-iscsi-modules package for your kernel:
-
-dpkg -i linux-iscsi-modules-source_5.0.0.0.3rc6-363_all.deb
-cd /usr/src
-rm -rf modules/linux-iscsi
-tar jxpvf linux-iscsi-modules-source.tar.bz2
-cd linux-2.6.11.11 (or your appropriate version)
-make-kpkg --added-modules linux-iscsi modules-image
-
-By default, make-kpkg will assume /usr/src/linux-iscsi-modules-source.tar.bz2
-has been extracted under /usr/src. However, that also requires building as
-root. If you want to do the build as a non-root user, you need to use the
-MODULE_LOC environment variable. For example:
-
-cd ~/builds
-export MODULES_LOC=$PWD/modules
-tar jxpvf /usr/src/linux-iscsi-modules-source.tar.bz2
-cd ~/builds/linux-2.6.11.11 (or your appropriate version)
-make-kpkg --added-modules linux-iscsi modules-image
-
-Installing
---
-
-Once you have built the linux-iscsi-modules package, you can install the
-binaries:
-
-dpkg -i linux-iscsi_5.0.0.0.3rc6-363_i386.deb
linux-iscsi-modules-2.6.11.11_5.0.0.0.3rc6-363+10.00.Custom_i386.deb
-
- -- Chad Tindel , Mon, 30 May 2005 15:17:53 -0600
diff --git a/debian/changelog b/debian/changelog
deleted file mode 100644
index f71577e..000
--- a/debian/changelog
+++ /dev/null
@@ -1,6 +0,0 @@
-linux-iscsi (5.0.0.0.3rc6-363) unstable; urgency=low
-
- * Initial Release.
-
- -- Chad Tindel Mon, 30 May 2005 15:17:53 -0600
-
diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index b8626c4..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-4
diff --git a/debian/control b/debian/control
deleted file mode 100644
index d333569..000
--- a/debian/control
+++ /dev/null
@@ -1,27 +0,0 @@
-Source: linux-iscsi
-Section: net
-Priority: optional
-Maintainer: Chad Tindel
-Build-Depends: debhelper (>= 4.0.0), libdb4.3, libdb4.3-dev
-Standards-Version: 3.6.1
-
-Package: linux-iscsi
-Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, linux-iscsi-modules
-Description: high performance, transport independent implementation of
RFC3720.
- linux-iscsi is a high performance, transport independent, implementation of
- RFC3720.
-
-#Package: linux-iscsi
-#Architecture: all
-#Description: Documentation for linux-iscsi
-#linux-iscsi is a high performance, transport independent, implementation of
-#RFC3720.
-
-Package: linux-iscsi-modules-source
-Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}, module-assistant, debhelper (>=
4.0.0), bzip2
-Description: Source Code for the Linux iSCSI Kernel Modules
- Along with make-kpkg, this package maybe used to build a linux-iscsi-modules
- package for a kernel-image package.
-
diff --git a/debian/control.mo
[PATCH 2/4] buildsys: respect CFLAGS and LDFLAGS from the outside
Make the build systsem respect CFLAGS and LDFLAGS set from the outside.
Previously, OPTFLAGS could be set to alter CFLAGS (which were
overridden completely), but that is non-standard, so also check for
user-set CFLAGS. This will make life easier when packaging this for
distributions. If OPTFLAGS is set, prefer that to CFLAGS to retain the
old behavior in that case (and not break current builds).
Additionally, also use LDFLAGS for linking the binaries, which was not
respected at all previously.
---
Makefile| 13 -
iscsiuio/configure.ac | 3 ++-
usr/Makefile| 10 +-
utils/Makefile | 5 +++--
utils/fwparam_ibft/Makefile | 4 ++--
utils/sysdeps/Makefile | 3 ++-
6 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/Makefile b/Makefile
index 188e3bd..1ef9273 100644
--- a/Makefile
+++ b/Makefile
@@ -20,6 +20,17 @@ INSTALL = install
ETCFILES = etc/iscsid.conf
IFACEFILES = etc/iface.example
+# Compatibility: parse old OPTFLAGS argument
+ifdef OPTFLAGS
+CFLAGS = $(OPTFLAGS)
+endif
+
+# Export it so configure of iscsiuio & open-isns will
+# pick it up.
+ifneq (,$(CFLAGS))
+export CFLAGS
+endif
+
# Random comments:
# using '$(MAKE)' instead of just 'make' allows make to run in parallel
# over multiple makefile.
@@ -44,7 +55,7 @@ user: utils/open-isns/Makefile iscsiuio/Makefile
@echo "Read README file for detailed information."
utils/open-isns/Makefile: utils/open-isns/configure utils/open-isns/Makefile.in
- cd utils/open-isns; ./configure CFLAGS="$(OPTFLAGS)" --with-security=no
+ cd utils/open-isns; ./configure --with-security=no
iscsiuio/Makefile: iscsiuio/configure iscsiuio/Makefile.in
cd iscsiuio; ./configure
diff --git a/iscsiuio/configure.ac b/iscsiuio/configure.ac
index 7ee1e73..6c0013b 100644
--- a/iscsiuio/configure.ac
+++ b/iscsiuio/configure.ac
@@ -53,7 +53,8 @@ AC_LIBTOOL_DLOPEN
# libtool stuff
AC_PROG_LIBTOOL
-CFLAGS="${CFLAGS} -O2 -Wall"
+: ${CFLAGS:="-O2"}
+CFLAGS="${CFLAGS} -Wall"
## check for --enable-debug first before checking CFLAGS before
## so that we don't mix -O and -g
AC_ARG_ENABLE(debug,
diff --git a/usr/Makefile b/usr/Makefile
index 9209d5d..e23fee1 100644
--- a/usr/Makefile
+++ b/usr/Makefile
@@ -28,9 +28,9 @@ IPC_OBJ=ioctl.o
endif
endif
-OPTFLAGS ?= -O2 -g
+CFLAGS ?= -O2 -g
WARNFLAGS ?= -Wall -Wstrict-prototypes
-CFLAGS += $(OPTFLAGS) $(WARNFLAGS) -I../include -I. -I../utils/open-isns \
+CFLAGS += $(WARNFLAGS) -I../include -I. -I../utils/open-isns \
-D$(OSNAME) $(IPC_CFLAGS)
PROGRAMS = iscsid iscsiadm iscsistart
@@ -55,14 +55,14 @@ all: $(PROGRAMS)
iscsid: $(ISCSI_LIB_SRCS) $(INITIATOR_SRCS) $(DISCOVERY_SRCS) \
iscsid.o session_mgmt.o discoveryd.o
- $(CC) $(CFLAGS) $^ -o $@ -L../utils/open-isns -lisns -lrt -lmount
+ $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@ -L../utils/open-isns -lisns -lrt
-lmount
iscsiadm: $(ISCSI_LIB_SRCS) $(DISCOVERY_SRCS) iscsiadm.o session_mgmt.o
- $(CC) $(CFLAGS) $^ -o $@ -L../utils/open-isns -lisns
+ $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@ -L../utils/open-isns -lisns
iscsistart: $(ISCSI_LIB_SRCS) $(INITIATOR_SRCS) $(FW_BOOT_SRCS) \
iscsistart.o statics.o
- $(CC) $(CFLAGS) $^ -o $@ -lrt -lmount
+ $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@ -lrt -lmount
clean:
rm -f *.o $(PROGRAMS) .depend $(LIBSYS)
diff --git a/utils/Makefile b/utils/Makefile
index 2c7e891..f65f1e7 100644
--- a/utils/Makefile
+++ b/utils/Makefile
@@ -1,12 +1,13 @@
# This Makefile will work only with GNU make.
-CFLAGS += $(OPTFLAGS) -O2 -fno-inline -Wall -Wstrict-prototypes -g
+CFLAGS ?= -O2 -fno-inline -g
+CFLAGS += -Wall -Wstrict-prototypes
PROGRAMS = iscsi-iname
all: $(PROGRAMS)
iscsi-iname: md5.o iscsi-iname.o
- $(CC) $(CFLAGS) $^ $(DBM_LIB) -o $@
+ $(CC) $(CFLAGS) $(LDFLAGS) $^ $(DBM_LIB) -o $@
clean:
rm -f *.o $(PROGRAMS) .depend
diff --git a/utils/fwparam_ibft/Makefile b/utils/fwparam_ibft/Makefile
index c72bb7f..773d8eb 100644
--- a/utils/fwparam_ibft/Makefile
+++ b/utils/fwparam_ibft/Makefile
@@ -26,9 +26,9 @@ OBJS := fw_entry.o fwparam_sysfs.o $(SYSDEPS_OBJS)
../../usr/iscsi_net_util.o
OBJS += prom_lex.o prom_parse.tab.o fwparam_ppc.o
CLEANFILES = $(OBJS) *.output *~
-OPTFLAGS ?= -O2 -g -fPIC
+CFLAGS ?= -O2 -g
WARNFLAGS ?= -Wall -Wstrict-prototypes
-CFLAGS += $(OPTFLAGS) $(WARNFLAGS) -I../../include -I../../usr -D_GNU_SOURCE
+CFLAGS += -fPIC $(WARNFLAGS) -I../../include -I../../usr -D_GNU_SOURCE
all: $(OBJS)
diff --git a/utils/sysdeps/Makefile b/utils/sysdeps/Makefile
index 53c10e5..4299164 100644
--- a/utils/sysdeps/Makefile
+++ b/utils/sysdeps/Makefile
@@ -1,6 +1,7 @@
# This Makefile will work only with GNU make.
-CFLAGS += $(OPTFLAGS) $(WARNFLAGS) -O2 -fno-inline -Wall -Wstrict-prototypes -g
+CFLAGS ?= -O2 -fno-inline -g
+CFLAGS += $(WARNFLAGS) -Wall -Wstrict-prototypes
SYSDEPS_OBJS=sysdeps.o
[PATCH 1/4] buildsys: make 'make clean' idempotent
Make sure 'make clean' will always succeed. Also make distclean in iscsiuio subdirectory. --- Makefile | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 79bad84..188e3bd 100644 --- a/Makefile +++ b/Makefile @@ -69,9 +69,10 @@ clean: $(MAKE) -C utils clean $(MAKE) -C usr clean $(MAKE) -C kernel clean - $(MAKE) -C iscsiuio clean - $(MAKE) -C utils/open-isns clean - $(MAKE) -C utils/open-isns distclean + [ ! -f iscsiuio/Makefile ] || $(MAKE) -C iscsiuio clean + [ ! -f iscsiuio/Makefile ] || $(MAKE) -C iscsiuio distclean + [ ! -f utils/open-isns/Makefile ] || $(MAKE) -C utils/open-isns clean + [ ! -f utils/open-isns/Makefile ] || $(MAKE) -C utils/open-isns distclean # this is for safety # now -jXXX will still be safe -- 2.1.4 -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
[PATCH 0/4] Assorted fixes
Hi, I've been going through Debian's packaging of open-iscsi and I've noticed that a couple of fixes that should go upstream (with some improvements I'll make to Debian's package this will bring the number of patches in Debian down to zero). I've polished them a bit and am forwarding them here. Summary of the patches: 1. make clean is now idempotent (can be called multiple times without failing) and also does make distclean in iscsiuio. 2. CFLAGS and LDFLAGS set on the outside are now respected. 3. remove debian/ This is really outdated (was added 10 years ago and never changed since), is better maintained downstream. 4. Some speilling fixes that have been in the Debian package for quite a while. This patch is not by me, so I've set the git author accordingly. (I can also create a github pull request if you prefer that.) Best regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Restarting iscsid, iscsi socket protocol stability
Thanks for your quick reply. On 05/26/2015 10:56 PM, Mike Christie wrote: > On 5/26/15, 1:24 PM, Christian Seiler wrote: >> 1. How stable is the socket protocol between iscsiadm and iscsid? Are >> there any guarantuees there? Or could it happen that you upgrade and >> then the new iscsiadm can't properly talk to the old iscsid (which is >> needed at e.g. shutdown to log out)? > > It is not stable. It is assumed that when you upgrade one you upgrade the > other. Thanks for confirming, that's what I suspected. >> 2. What I'd rather like to do is just restart iscsid (but keep the >> currently active iSCSI sessions). From my short tests it seems to work, >> and I observe this: > > Restarting iscsid is ok and is supported. Great, thanks, that helps a ton! >> - Stopping iscsid seems to be completely harmless, the TCP connections >> of the current session remain open and storage is still acessible. >> Obviously, if you need to react to external events and e.g. change >> portals, that won't happen in this case (without iscsid running), >> but for a short period of time, this should be perfectly fine. > > The most common problem would be if something happened to the > connection while iscsid is down. If the network went down at this > time, since iscsid is not up then we would not be able to relogin to > handle the problem like we normally do. So if you were also updating > networking packages at the same time you might want to be careful. Well, Debian (und probably all other distributions as well) serializes postinstall actions of packages, so even if the network goes down while upgrading packages (and I've never actually seen that happening), it should be back up before iscsid is stopped. Otherwise, I would consider that a bug of the network packages. > Yeah, that is correct, when iscsid restarts it restarts the > connections/sessions. When it does this, it will block incoming IO > until the session is restarted and will restart IO that was in > process of executing it restarted. > > It will only block IO for replacement_timeout/recovery_timeout > seconds though, so if that is really short like one or two seconds > you could get IO errors. Good to know, thanks! >> What I want to know there is: >> >> - Is it safe to restart iscsid? (As long as it can log in to the >> target again it should be, right?) Are there any side effects? > > It is safe. However, you probably want to check > > /sys/class/iscsi_session/sessionX/recovery_tmo > > and if it is set to a short value then temporarily increase it. Do something > like > > copy /sys/class/iscsi_session/sessionX/recovery_tmo > echo 120 > /sys/class/iscsi_session/sessionX/recovery_tmo > kill iscsid > Update tools and daemon > restart iscsid > echo original > /sys/class/iscsi_session/sessionX/recovery_tmo That's really helpful, thanks! I'll add something about that to Debian's README file and add a variant of your snippet to the postinst script for upgrades. Final question regarding that matter: iscsid takes a while to perform recovery of sessions, but it forks off immediately after starting. Is there a way (using e.g. iscsiadm) to explicitly wait until recovery is complete or a timeout is reached? I'd like to make sure that a) no recovery is in progress before stopping iscsid in the postinst (and fail postinst if there is still one in progress and ask the admin to check manually) and b) after postinst of the open-iscsi package is complete, the recovery has already taken place. Thus I'd like to use (combining that with your recovery_tmo setting snippet) something like save_recovery_timeout wait_for_recovery || exit 1 restart iscsid wait_for_recovery || message "something got really screwed up, sorry" restore_recovery_timeout Is that possible? (I'm basically looking for the equivalent of udevadm settle for iSCSI sessions.) Best regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Restarting iscsid, iscsi socket protocol stability
Hi there, I want to improve open-iscsi packaging in Debian and I've stumbled upon the question of what to do on package upgrades. Currently, Debian's package doesn't do anything on upgrades, i.e. the old iscsid is left running. (The current documentation in Debian is misleading when it comes to updates btw.) I have a couple of questions about that: 1. How stable is the socket protocol between iscsiadm and iscsid? Are there any guarantuees there? Or could it happen that you upgrade and then the new iscsiadm can't properly talk to the old iscsid (which is needed at e.g. shutdown to log out)? But even if the protocol is guaranteed to be stable: is that a good idea? In principle, there could be security upgrades in the future, where you'd want to restart iscsid... which leads to: 2. What I'd rather like to do is just restart iscsid (but keep the currently active iSCSI sessions). From my short tests it seems to work, and I observe this: - Stopping iscsid seems to be completely harmless, the TCP connections of the current session remain open and storage is still acessible. Obviously, if you need to react to external events and e.g. change portals, that won't happen in this case (without iscsid running), but for a short period of time, this should be perfectly fine. - Starting iscsid again, it will close the current TCP connections for the sessions, reconnect to the portal and then use that. It also says 'connection1:0 is operational after recovery (1 attempts)', although that typically takes a couple of seconds after it started. I didn't notice any trouble with the storage, filesystems reamined mounted, no kernel messages (even active I/O would continue, blocking only for a very short amount of time). - Also, with root on iSCSI, you typically have the configuration: initramfs uses iscsistart to log in initially, then when the system comes up properly iscsid is started for the first time. So there you already have the case that iscsid is regularily started with already active iSCSI sessions. On the other hand, I don't have any weird corner-case configurations here (my test system is in fact a VM that connects to a software target), so I can't test any really weird setups. What I want to know there is: - Is it safe to restart iscsid? (As long as it can log in to the target again it should be, right?) Are there any side effects? - If it generally is: can you think of any idea why it wouldn't be a good idea to restart iscsid after upgrading the package? Note: package upgrades of open-iscsi should be a rare occurrence: during the lifetime of a Debian stable release there should only be some if there are really serious bugs (security or otherwise), and then every time an upgrade is done to a new Debian version. Thanks in advance for your responses. Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
[PATCH] Fix small typo in iscsid.conf
Hi there, I've recently started co-maintaining the open-iscsi package in Debian and was going through the list of bugs in Debian's bugtracker. I'm attaching a patch to fix a small typo in iscsid.conf. The original bug report can be found under: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627908 (I set the git author of the attached patch to be the reporter of the bug.) Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout. >From 5dd4c293d22ea54b93e53650daec5dc2cbf2f8b7 Mon Sep 17 00:00:00 2001 From: Salvatore Bonaccorso Date: Thu, 21 May 2015 20:32:59 +0200 Subject: [PATCH] Fix small typo in iscsid.conf --- etc/iscsid.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/etc/iscsid.conf b/etc/iscsid.conf index 6d9a5c0..c30a7dc 100644 --- a/etc/iscsid.conf +++ b/etc/iscsid.conf @@ -83,7 +83,7 @@ node.leading_login = No # Timeouts # # -# See the iSCSI REAME's Advanced Configuration section for tips +# See the iSCSI README's Advanced Configuration section for tips # on setting timeouts when using multipath or doing root over iSCSI. # # To specify the length of time to wait for session re-establishment -- 2.1.4
