Re: [Users] Unable to activate iSCSI domain after crash of host

2014-02-10 Thread Alon Bar-Lev


- Original Message -
 From: Dafna Ron d...@redhat.com
 To: Gianluca Cecchi gianluca.cec...@gmail.com, Alon Bar-Lev 
 alo...@redhat.com
 Cc: users users@ovirt.org
 Sent: Monday, February 10, 2014 11:31:33 AM
 Subject: Re: [Users] Unable to activate iSCSI domain after crash of host
 
 adding Alon
 
 On 02/08/2014 05:42 PM, Gianluca Cecchi wrote:
  where can I find the function that encrypts iscsi chap password and
  put the encrypted value into storage_server_connections table?
  So that I can try to reinsert it and verify.

You can just put plain password, it should work...

If you want to encrypt use:

echo -n 'PASSWORD' | openssl pkeyutl -encrypt -certin -inkey 
/etc/pki/ovirt-engine/certs/engine.cer  | openssl enc -a | tr -d '\n'

But Dafna, isn't there a way at UI to re-specify password, so it be encrypted 
by the application?

 
  Thanks
  Gianluca
 
 
 --
 Dafna Ron
 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Unable to activate iSCSI domain after crash of host

2014-02-10 Thread Gianluca Cecchi
On Mon, Feb 10, 2014 at 10:56 AM, Alon Bar-Lev alo...@redhat.com wrote:


 - Original Message -
 From: Dafna Ron d...@redhat.com
 To: Gianluca Cecchi gianluca.cec...@gmail.com, Alon Bar-Lev 
 alo...@redhat.com
 Cc: users users@ovirt.org
 Sent: Monday, February 10, 2014 11:31:33 AM
 Subject: Re: [Users] Unable to activate iSCSI domain after crash of host

 adding Alon

 On 02/08/2014 05:42 PM, Gianluca Cecchi wrote:
  where can I find the function that encrypts iscsi chap password and
  put the encrypted value into storage_server_connections table?
  So that I can try to reinsert it and verify.

 You can just put plain password, it should work...

 If you want to encrypt use:

 echo -n 'PASSWORD' | openssl pkeyutl -encrypt -certin -inkey 
 /etc/pki/ovirt-engine/certs/engine.cer  | openssl enc -a | tr -d '\n'

 But Dafna, isn't there a way at UI to re-specify password, so it be encrypted 
 by the application?

 
  Thanks
  Gianluca


 --
 Dafna Ron


In my opinion when I first defined the ISCSI domain and input a wrong
password there was something not correctly managed when I then used
the correct one.
In fact in my opinion it seems there is no correspondence between
storage_domains table and storage_server_connections table.

If I take a glusterfs domain named gv01 I see this:

engine=# select * from storage_server_connections where id=(select
storage from storage_domains where storage_name='gv01');
  id  |  connection   | user_name |
password | iqn | port | portal | storage_type | mount_options |
vfs_type
| nfs_version | nfs_timeo | nfs_retrans
--+---+---+--+-+--++--+---+---
+-+---+-
 3b6a-aff3-47fa-b7ca-8e809804cbe2 | ovnode01:gv01 |   |
  | |  ||7 |   | glusterfs
| |   |
(1 row)

Instead for this ISCSI domain named OV01

engine=# select * from storage_server_connections where id=(select
storage from storage_domains where storage_name='OV01');
 id | connection | user_name | password | iqn | port | portal |
storage_type | mount_options | vfs_type | nfs_version | nfs_timeo |
nfs_retran
s
++---+--+-+--++--+---+--+-+---+---
--
(0 rows)


In particular:

engine=# select * from storage_domains where storage_name='OV01';
  id  |storage
| storage_name | storage_description | storage_comment |
storage_pool_id| available_disk_size | used_disk_size
| commited_disk_size | actual_images_size | status | storage_pool_name
|
 storage_type | storage_domain_type | storage_domain_format_type |
last_time_used_as_master | storage_domain_shared_status | recoverable
--++--+-+-+---
---+-+++++---+
--+-++--+--+-
 f741671e-6480-4d7b-b357-8cf6e8d2c0f1 |
uqe7UZ-PaBY-IiLj-XLAY-XoCZ-cmOk-cMJkeX | OV01 |
 | | 546cd2
9c-7249-4733-8fd5-317cff38ed71 |  44 |  5
| 10 |  1 |  4 | ISCSI
|
3 |   0 | 3  |
   0 |2 | t
(1 row)


engine=# select * from storage_pool where
id='546cd29c-7249-4733-8fd5-317cff38ed71';
  id  | name  | description |
storage_pool_type | storage_pool_format_type | status |
master_domain_version |
spm_vds_id | compatibility_version | _create_date  |
  _update_date  | quota_enforcement_type |
free_text_commen
t
--+---+-+---+--++---+-
---+---+---+---++-
--
 546cd29c-7249-4733-8fd5-317cff38ed71 | ISCSI | |
   3 | 3|  4 | 2 |
   | 3.3   | 2014-02-05 11:46:50.797079+01 |
2014-02-05 23:53:18.864716+01 |  0 |
(1 row)


engine=# select * from storage_server_connections where user_name='ovirt';
  id  |   connection| user_name |

 password

|
 iqn   | port | portal | storage_type

Re: [Users] Unable to activate iSCSI domain after crash of host

2014-02-10 Thread Dafna Ron

On 02/10/2014 08:00 PM, Gianluca Cecchi wrote:

On Mon, Feb 10, 2014 at 10:56 AM, Alon Bar-Lev alo...@redhat.com wrote:


- Original Message -

From: Dafna Ron d...@redhat.com
To: Gianluca Cecchi gianluca.cec...@gmail.com, Alon Bar-Lev 
alo...@redhat.com
Cc: users users@ovirt.org
Sent: Monday, February 10, 2014 11:31:33 AM
Subject: Re: [Users] Unable to activate iSCSI domain after crash of host

adding Alon

On 02/08/2014 05:42 PM, Gianluca Cecchi wrote:

where can I find the function that encrypts iscsi chap password and
put the encrypted value into storage_server_connections table?
So that I can try to reinsert it and verify.

You can just put plain password, it should work...

If you want to encrypt use:

echo -n 'PASSWORD' | openssl pkeyutl -encrypt -certin -inkey 
/etc/pki/ovirt-engine/certs/engine.cer  | openssl enc -a | tr -d '\n'

But Dafna, isn't there a way at UI to re-specify password, so it be encrypted 
by the application?


the problem is that the storage already exists but non-operational and 
we cannot edit a storage in any status other than active.
so if the password changed during a storage issue, the storage cannot 
recover to active state if the password had changed and the luns are not 
visible on the storage and we also cannot edit the password for the 
domain...



Thanks
Gianluca


--
Dafna Ron


In my opinion when I first defined the ISCSI domain and input a wrong
password there was something not correctly managed when I then used
the correct one.
In fact in my opinion it seems there is no correspondence between
storage_domains table and storage_server_connections table.

If I take a glusterfs domain named gv01 I see this:

engine=# select * from storage_server_connections where id=(select
storage from storage_domains where storage_name='gv01');
   id  |  connection   | user_name |
password | iqn | port | portal | storage_type | mount_options |
vfs_type
| nfs_version | nfs_timeo | nfs_retrans
--+---+---+--+-+--++--+---+---
+-+---+-
  3b6a-aff3-47fa-b7ca-8e809804cbe2 | ovnode01:gv01 |   |
   | |  ||7 |   | glusterfs
| |   |
(1 row)

Instead for this ISCSI domain named OV01

engine=# select * from storage_server_connections where id=(select
storage from storage_domains where storage_name='OV01');
  id | connection | user_name | password | iqn | port | portal |
storage_type | mount_options | vfs_type | nfs_version | nfs_timeo |
nfs_retran
s
++---+--+-+--++--+---+--+-+---+---
--
(0 rows)


In particular:

engine=# select * from storage_domains where storage_name='OV01';
   id  |storage
 | storage_name | storage_description | storage_comment |
 storage_pool_id| available_disk_size | used_disk_size
| commited_disk_size | actual_images_size | status | storage_pool_name
|
  storage_type | storage_domain_type | storage_domain_format_type |
last_time_used_as_master | storage_domain_shared_status | recoverable
--++--+-+-+---
---+-+++++---+
--+-++--+--+-
  f741671e-6480-4d7b-b357-8cf6e8d2c0f1 |
uqe7UZ-PaBY-IiLj-XLAY-XoCZ-cmOk-cMJkeX | OV01 |
  | | 546cd2
9c-7249-4733-8fd5-317cff38ed71 |  44 |  5
| 10 |  1 |  4 | ISCSI
|
 3 |   0 | 3  |
0 |2 | t
(1 row)


engine=# select * from storage_pool where
id='546cd29c-7249-4733-8fd5-317cff38ed71';
   id  | name  | description |
storage_pool_type | storage_pool_format_type | status |
master_domain_version |
spm_vds_id | compatibility_version | _create_date  |
   _update_date  | quota_enforcement_type |
free_text_commen
t
--+---+-+---+--++---+-
---+---+---+---++-
--
  546cd29c-7249-4733-8fd5-317cff38ed71 | ISCSI | |
3 | 3|  4 | 2 |
| 3.3   | 2014-02-05 11:46:50.797079

Re: [Users] Unable to activate iSCSI domain after crash of host

2014-02-08 Thread Gianluca Cecchi
where can I find the function that encrypts iscsi chap password and
put the encrypted value into storage_server_connections table?
So that I can try to reinsert it and verify.

Thanks
Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Unable to activate iSCSI domain after crash of host

2014-02-07 Thread Gianluca Cecchi
On Fri, Feb 7, 2014 at 2:02 PM, Dafna Ron  wrote:
 what does multipath get?

 I am not sure which table the chap will be saved in.
 try to list teh db tables - there are not that many for storage so it should
 he easy to find.


there is yet the historical warning about getuid_callout not valid
any more for fedora based distro...
but if I remember well should not be of influence in output apart the
warnings, correct?

[root@ovnode03 ~]# multipath -ll
Feb 07 14:09:49 | multipath.conf +5, invalid keyword: getuid_callout
Feb 07 14:09:49 | multipath.conf +18, invalid keyword: getuid_callout

I'm going to check rdbms tables too...

Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Unable to activate iSCSI domain after crash of host

2014-02-07 Thread Gianluca Cecchi
On Fri, Feb 7, 2014 at 2:11 PM, Gianluca Cecchi wrote:


 I'm going to check rdbms tables too...

 Gianluca

it seems that the table is storage_server_connections

but the value seems (correctly in my opinion) encrypted... how can I
update it eventually?

engine=# select * from storage_server_connections ;
  id  |  connection
  | user_name |

  password

  |   iqn   |
port | portal | storage_type | mount_options | vfs_type  | nfs_version
|
 nfs_timeo | nfs_retrans
--+--+---+
--
--
--+-+--++--+---+---+-+
---+-


 6a5b159d-4c11-43cc-aa09-55c325de47b3 | 192.168.230.101
  | ovirt |
lf1mtw6jWq0tcO/jBeLtSdrx9WSMvLOJxMF/Z4UWsgK
W10jYKXzkxG8iPgX9xMEcOhTJCeMNtC6EQES5Tq0MjHGPfuzigwL9nejZEZwtDvOFmKZtCBSGaKoOyjQpU8hfoqq7u47jvGE5VmVwDQ40p6goXWDHMWPxdCk2IzAOBsDlsnrJGmqLioRDj
JQVya28cJsgzGoaLFHZMQD8bfW7ay3cQ6k8Hxlz99MKNpxxoV0fju1Blpfrqpa2bCSpQ5w0PrVHmJrW4eiBEd/Rg/XV497PGatAcwQr7hD5/uG/GLoqBbCMyR9S11Ot90aprL0Gd9cOlM4
VngzCD/2JqFmvhA== | iqn.2013-09.local.localdomain:c6iscsit.target11 |
3260 | 1  |3 |   |   |
|
   |

Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Unable to activate iSCSI domain after crash of host

2014-02-07 Thread Dafna Ron

what happens when you try to update from the UI? (edit the storage)

On 02/07/2014 02:06 PM, Gianluca Cecchi wrote:

On Fri, Feb 7, 2014 at 2:11 PM, Gianluca Cecchi wrote:


I'm going to check rdbms tables too...

Gianluca

it seems that the table is storage_server_connections

but the value seems (correctly in my opinion) encrypted... how can I
update it eventually?

engine=# select * from storage_server_connections ;
   id  |  connection
   | user_name |

   password

   |   iqn   |
port | portal | storage_type | mount_options | vfs_type  | nfs_version
|
  nfs_timeo | nfs_retrans
--+--+---+
--
--
--+-+--++--+---+---+-+
---+-


  6a5b159d-4c11-43cc-aa09-55c325de47b3 | 192.168.230.101
   | ovirt |
lf1mtw6jWq0tcO/jBeLtSdrx9WSMvLOJxMF/Z4UWsgK
W10jYKXzkxG8iPgX9xMEcOhTJCeMNtC6EQES5Tq0MjHGPfuzigwL9nejZEZwtDvOFmKZtCBSGaKoOyjQpU8hfoqq7u47jvGE5VmVwDQ40p6goXWDHMWPxdCk2IzAOBsDlsnrJGmqLioRDj
JQVya28cJsgzGoaLFHZMQD8bfW7ay3cQ6k8Hxlz99MKNpxxoV0fju1Blpfrqpa2bCSpQ5w0PrVHmJrW4eiBEd/Rg/XV497PGatAcwQr7hD5/uG/GLoqBbCMyR9S11Ot90aprL0Gd9cOlM4
VngzCD/2JqFmvhA== | iqn.2013-09.local.localdomain:c6iscsit.target11 |
3260 | 1  |3 |   |   |
|
|

Gianluca



--
Dafna Ron
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users