search

open-iscsi / targetd

Remote configuration of a LIO-based storage appliance
GNU General Public License v3.0
71 stars 28 forks source link

Fedora packages missing backends #70

Closed gnunn1 closed 4 years ago

gnunn1 commented 4 years ago

I'm trying to use targetd on Fedora 31 and it appears like the package is missing the backends module. Starting the service returns the following error:

[gnunn@lab-server target]$ sudo systemctl status targetd
● targetd.service - targetd storage array API daemon
   Loaded: loaded (/usr/lib/systemd/system/targetd.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2020-09-10 12:14:51 PDT; 4s ago
  Process: 3836 ExecStart=/usr/bin/targetd (code=exited, status=255/EXCEPTION)
 Main PID: 3836 (code=exited, status=255/EXCEPTION)
      CPU: 78ms

Sep 10 12:14:51 lab-server systemd[1]: Started targetd storage array API daemon.
Sep 10 12:14:51 lab-server targetd[3836]: ERROR:root:ModuleNotFoundError("No module named 'targetd.backends'")
Sep 10 12:14:51 lab-server systemd[1]: targetd.service: Main process exited, code=exited, status=255/EXCEPTION
Sep 10 12:14:51 lab-server systemd[1]: targetd.service: Failed with result 'exit-code'.

Looking at the package (0.8.12-1.fc31) it does not appear to include the backends. Is there a newer rpm I should be using?

tasleson commented 4 years ago

@gnunn1 I'll create a new rpm to address, sorry about that.

gnunn1 commented 4 years ago

No worries, stuff happens. Appreciate the quick reponse!

tasleson commented 4 years ago

The setup.py was updated after I cut the 0.8.12 release, thus the reason we are missing backends. I think I'm going to cut a new release and then roll new packages.

tasleson commented 4 years ago

Did a new release and created some new packages.

https://bodhi.fedoraproject.org/updates/FEDORA-2020-487cb31798

Please try it out and report status there, positive karma will get it moved to stable repository. I installed/configured and ran the rawhide version of this newly created package to make sure it would run. I'm planning on adding automated CI tests in fedora to ensure something like this doesn't happen again.

gnunn1 commented 4 years ago

I tried the package but it looks like it was missing the libblockdev-lvm-dbus dependency as per below:

● targetd.service - targetd storage array API daemon
   Loaded: loaded (/usr/lib/systemd/system/targetd.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2020-09-10 15:08:58 PDT; 4s ago
  Process: 3261 ExecStart=/usr/bin/targetd (code=exited, status=255/EXCEPTION)
 Main PID: 3261 (code=exited, status=255/EXCEPTION)
      CPU: 92ms

Sep 10 15:08:58 lab-server systemd[1]: Started targetd storage array API daemon.
Sep 10 15:08:58 lab-server targetd[3261]: ERROR:root:Error initializing block module: VG pool vg-targetd not found, nested error: The 'lvm' utilit>
Sep 10 15:08:58 lab-server targetd[3261]: ERROR:root:TargetdError("VG pool vg-targetd not found, nested error: The 'lvm' utility is not available")
Sep 10 15:08:58 lab-server systemd[1]: targetd.service: Main process exited, code=exited, status=255/EXCEPTION
Sep 10 15:08:58 lab-server systemd[1]: targetd.service: Failed with result 'exit-code'.

Once I installed that, I'm getting the following error now:

● targetd.service - targetd storage array API daemon
   Loaded: loaded (/usr/lib/systemd/system/targetd.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2020-09-10 15:12:25 PDT; 6s ago
  Process: 3583 ExecStart=/usr/bin/targetd (code=exited, status=255/EXCEPTION)
 Main PID: 3583 (code=exited, status=255/EXCEPTION)
      CPU: 99ms

Sep 10 15:12:25 lab-server systemd[1]: Started targetd storage array API daemon.
Sep 10 15:12:25 lab-server targetd[3583]: g_dbus_connection_call_sync_internal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
Sep 10 15:12:25 lab-server targetd[3583]: /usr/lib64/python3.7/site-packages/gi/overrides/BlockDev.py:1030: Warning: g_variant_get_va: assertion 'value != NULL' f>
Sep 10 15:12:25 lab-server targetd[3583]:   ret = orig_obj(*args, **kwargs)
Sep 10 15:12:25 lab-server targetd[3583]: /usr/lib64/python3.7/site-packages/gi/overrides/BlockDev.py:1030: Warning: g_variant_unref: assertion 'value != NULL' fa>
Sep 10 15:12:25 lab-server targetd[3583]:   ret = orig_obj(*args, **kwargs)
Sep 10 15:12:25 lab-server targetd[3583]: ERROR:root:Error initializing block module: VG pool vg-targetd not found, nested error: Failed to get properties of the >
Sep 10 15:12:25 lab-server targetd[3583]: ERROR:root:TargetdError('VG pool vg-targetd not found, nested error: Failed to get properties of the (null) object: GDBu>
Sep 10 15:12:25 lab-server systemd[1]: targetd.service: Main process exited, code=exited, status=255/EXCEPTION
Sep 10 15:12:25 lab-server systemd[1]: targetd.service: Failed with result 'exit-code'.

I've confirmed I have a volumegroup called vg-targetd:

  --- Volume group ---
  VG Name               vg-targetd
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <465.76 GiB
  PE Size               4.00 MiB
  Total PE              119234
  Alloc PE / Size       0 / 0   
  Free  PE / Size       119234 / <465.76 GiB
  VG UUID               2dglLm-K8Pu-UtdR-zZIJ-IoqT-A7KN-TA2axM
gnunn1 commented 4 years ago

Here's my config file in case it's something I'm doing:

# See http://www.yaml.org/spec/1.2/spec.html for more on YAML.
#
# A sample /etc/target/targetd.yaml file.
#

# No default password, please pick a good one.

password: xxxxxxx

# defaults below; uncomment and edit
block_pools: [vg-targetd] # just 1 by default, but can be more
#zfs_block_pools: [] # you can also use zfs as backend
#fs_pools: []  # Path to btrfs FS, eg. /my_btrfs_mount
user: admin
target_name: iqn.2003-01.org.linux-iscsi.gnunn-server:targetd

# log level (debug, info, warning, error, critical)
#log_level: info

ssl: false
# if ssl is activated:
#ssl_cert: /etc/target/targetd_cert.pem
#ssl_key: /etc/target/targetd_key.pem
tasleson commented 4 years ago

Do you have selinux in enforcing mode? If you do please put it in permissive mode and try again. I was working on making targetd work with selinux ref. https://github.com/fedora-selinux/selinux-policy-contrib/pull/222 I'll revisit that.

tasleson commented 4 years ago

Also for lvm it's best to specify a thin pool to use to get all the cool features for targetd, so create one from your VG and specify that in your targetd.yaml

$ sudo lvcreate -L <size> -T vg-targetd/thin_pool
block_pools: [vg-targetd/thin_pool]
tasleson commented 4 years ago

The libblockdev-lvm-dbus shouldn't be required, I'll check into that too. AFAIK our automated CI testing does not install it.

gnunn1 commented 4 years ago

Installing libblockdev-lvm-dbus also installed another dependency, could have been lvm2-dbusd which is noted in the readme but I can't remember for sure.

gnunn1 commented 4 years ago

Setting SELInux to permissive works, thanks for the tip

tasleson commented 4 years ago

@gnunn1 You're welcome

New PR's submitted for SELinux updates

https://github.com/fedora-selinux/selinux-policy/pull/431 https://github.com/fedora-selinux/selinux-policy-contrib/pull/334

gnunn1 commented 4 years ago

Thanks @tasleson for the quick turnaround, much appreciated.