Data_exporter app showcase - live demo
CC Attribution - ShareAlike 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Villafáñez, Juan Pablo
The data_exporter aims to migrate user data from one server to another. This live demo will showcase the app The demo will show the current status of the app as well as go through the whole process of exporting and importing a user from one server to another.
 Okay, so I'm Juan Pablo. I'm developing the data supported app. It's still a work in progress, but I think we have enough to show something right now. So as it was told a couple of days ago, the data is supported up is used to migrate users from one instance to another, and that's what we are going to do right now. So we have two different instances here. Both are with the onCloud 10.09, and right now we are going to create some new users here that are the ones that we are going to import in the other one. So let's create a couple of users. And then let's login with one of them and add some files here. So let's share this file with the other user, which is user2. And also let's create a public link so anyone can access to this file. In addition, the older user will have more files. You can see here the shared file. We can add a new one. And share this file with the first user. So right now we can see more or less an average setup. We can also share with another third party server. So what we are going to do is to import these users to this other server, which the server doesn't have those users yet. So let's see how we can do that. On the left side we have a command line for the first server with both users. And on the right side we have the new server where we are going to import those users. So let's see what commands are available to do this export. So we have the export user command, which is the command that we are going to use to export all the information. So let's export the user1 and we are going to export in the Temporal folder, for example, all that information. So if we go here we can see the user1 folder, which contains all the exported information that will be used in the older server. So let's compress that information in order to send it back to the second server. And then send to the older server. So let's just compress here the file we have sent. So in the new server right now we have the information that we have exported from the first server. So right now we are going to import that information here. With the import user command that we have, we need just the directory that we have taken back from the first server. So right now we have imported the user here. The imported user has a random password set, so we have to reset the password to an unknown one. So we can log in here with the new user. We can see here the imported file from the older server as well as the sharing information that is generated. We have automatically shared this file with the user2 from the older server. We can check here that the notification has arrived. So here we have the file that is shared from this second server. We can check also that the information is basically the same that is shared by user1 which is mostly this user. So this is not finished because if we check what files we have here, we have this file which is shared by the user2 which should also be shared against the first user which doesn't appear here. So in order to fix this, we have to run a second command in the old server which is the export migrate share which takes the user ID of the user that has been exported and the target remote server in order to rewire the missing shares. So let's do it. So once this is done, we can check, we'll reverse here that this file has been also shared with the user1 from the remote server which is this one. We can check that the notification is here and right now you have access to the file shared here in the old server. So we can go a bit forward and we can go a bit forward and migrate also the user2 to the new server. The process is basically the same. So let's export the user2 into the same temporal folder as well as compress and send the information back to the new server. So let's decompress the data here and import the user. Same as before, we have to reset the password of the user. So if we access with the user2 here, we have the same file we have here also properly shared with the proper users. We have here the file shared with the user1 which is in the same server in this case because it has been migrated. And also we have this file which has been shared for the user1. So right now since the process has been finished, we could delete the user4 from the old server and effectively finish the migration of the users. So this is the most of the demo. So as the application for the use cases of this app, we can maybe either split or merge different servers into one for example as well as migrate users from one server to your public server. So I guess this is all that we have to show right now. So any questions? Yeah. So the question is basically that we have to... So why we have to do it manually? Well, it has to be like that. Exactly, automatically I mean... So here we have to migrate the server to the user1. So here right now the focus is on the very consistent term that is going to operate through the export. So this will add another layer basically that will make this will be much more basic concept. At this point the old export challenge was to first have a unit data meter data for hard which is understood for other versions of the export data including the metadata and the import is possible to do in the main way. So you can think of how the tie values will change. Can you open the import command that will help? There's a little feature which could be very interesting for lots of other people. You can even change the utility. My interface is... Is it working with changing the utility already? Not right now. But it's planning to be out there. So by the way, we can do that manually. We create these values, but we pre-sort the metadata, bounce the parameters and we can give them... Is there probability to have an import? All is for call. Is it right to have a unit for the users? Because they can do it in cache. They can have state heat to do this. Because I'm not sure if they will make a backup from that. I mean, there's probability to make one. But that applies to any script that you're making by a monitor. We decided to not automatically tie the whole thing, not to make a re-automation. This is how security will do automatically. So, you focus your really on the challenges. This takes more than one time to manage the data. You see a better time to manage the data. And you have to open the repository for that. So you can have a look at the code. And by feedback, you have possibility to ask more questions. Yeah. Thank you. It's very great to have this... Could I see the old instance? The browser again. So there you have two files, two shares from the old user and from the new server. You would have to delete the old user in their own instance to make this share easier. Because I see there I have the same file twice, right? Yes. We decided to not delete any file, nor share. Just in case something goes wrong and we can retry. I can remove it afterwards for COK, import the new instance, but well, I can delete the old... Yeah. Yes. Once we have finished the import process, you can delete the old users. Okay. All the new export files do take care about file versions and addresses? What's the next question? Right now I think we have only file version that we have exported and trash bin I think is on the way. And tags? Tags I think is also planned now. I think so. You have to make new account with the file. I don't know about the old one. But you have another same domain, you can see it on the page. We reserve the intersection. Yeah. You know you will have to double pay. What will happen if there is a user to first system export data and there is a user to the system? By default, we'll reuse that account if it's possible. But it's not even version now. I think that's not the question that the problem is that there are files that appears in the second system where there is a new user to the system. Now you can send a new user ID or you can choose an existing user ID and you will just add the data by default. That's not the problem. As long as the backend is the same we can reuse the user account. So more questions? What do you think about groups? We have some plans also for migrating groups. We have in tech just that. You will not get remote group chat. Let's go back to the question. We cannot group the new users and group the new users. We will not care about the members of the group to have them the same way. If they are the same way, you can export them in the same way, you can also add the group chat. And that will be the same thing. You will not be able to make a lot of groups chat because you will not care about having groups set up the same way. So I have to make sure that the group and the user automatically can add the group or you have to take care of the subject. You can export the groups and you can align to the list of groups that people have. So if the new cases for migrating is not a major problem. You can also modify the data. It's a basic format and you have two sets of revocations. You can't even manage the data or fit the data. There is a lot of functionality. You need to find a way to deal with challenges like that. You want to fit or change the data. There is a lot of possibility because it would be really powerful. You want to work with the people. So the groups will be kept. The user name changes. It was cut as a stop-shift for example. I would belong to the same group. Very likely, yeah. I think we can do that. How about the end-up users? Would it be possible to link with the new home-cloth server with the end-up stream or whatever so that they can be really important to the preference of the end-up? As long as the user ID is the same, yes. If the user ID changes, we can do that. Maybe with the alias we can somehow manage to rewire the user, but it's something to test anyway. I choose a different data configuration that I should be in comparison with the previous configuration. Well, but that will change the user ID of both users. So if the user ID is different, we can rewire it. So, more questions? And that's all. Thank you. Thank you.
 Okay, so I'm Juan Pablo. I'm developing the data  supported app. It's still a work in progress, but I think we have enough to show something right now. So as it was told a couple of days ago, the data is  supported up is used to migrate users from one instance to another, and that's what we are going to do right now. So we have two different instances here. Both are with  the onCloud 10.09, and right now we are going to create some new users here that are the ones that we are going to import in the other one. So let's create a couple of users.  And then let's login with one of them and add some files here.  So let's share this file with the other user, which is user2.  And also let's create a public link so anyone can access to this file. In addition, the older user will have more files.  You can see here the shared file. We can add a new one.  And share this file with the first user. So right now we can see more or less an average setup. We can also share with another  third party server.  So what we are going to do is to import these users to this other server, which the server doesn't have those users yet. So let's see how we can do that.  On the left side we have a command line for the first server with both users. And on the right side we have the new server where we are going to import those users.  So let's see what commands are available to do this export.  So we have the export user command, which is the command that we are going to use to export all the information.  So let's export the user1 and we are going to export in the Temporal folder, for example, all that information.  So if we go here we can see the user1 folder, which contains all the exported information that will be used in the older server.  So let's compress that information in order to send it back to the second server.  And then send to the older server.  So let's just compress here the file we have sent.  So in the new server right now we have the information that we have exported from the first server.  So right now we are going to import that information here.  With the import user command that we have, we need just the directory that we have taken back from the first server.  So right now we have imported the user here.  The imported user has a random password set, so we have to reset the password to an unknown one.  So we can log in here with the new user.  We can see here the imported file from the older server as well as the sharing information that is generated.  We have automatically shared this file with the user2 from the older server.  We can check here that the notification has arrived.  So here we have the file that is shared from this second server.  We can check also that the information is basically the same that is shared by user1 which is mostly this user.  So this is not finished because if we check what files we have here, we have this file which is shared by the user2  which should also be shared against the first user which doesn't appear here.  So in order to fix this, we have to run a second command in the old server which is the export migrate share  which takes the user ID of the user that has been exported and the target remote server in order to rewire the missing shares.  So let's do it.  So once this is done, we can check, we'll reverse here that this file has been also shared with the user1 from the remote server which is this one.  We can check that the notification is here and right now you have access to the file shared here in the old server.  So we can go a bit forward and we can go a bit forward and migrate also the user2 to the new server.  The process is basically the same.  So let's export the user2 into the same temporal folder as well as compress and send the information back to the new server.  So let's decompress the data here and import the user.  Same as before, we have to reset the password of the user.  So if we access with the user2 here, we have the same file we have here also properly shared with the proper users.  We have here the file shared with the user1 which is in the same server in this case because it has been migrated.  And also we have this file which has been shared for the user1.  So right now since the process has been finished, we could delete the user4 from the old server and effectively finish the migration of the users.  So this is the most of the demo.  So as the application for the use cases of this app, we can maybe either split or merge different servers into one for example as well as migrate users from one server to your public server.  So I guess this is all that we have to show right now.  So any questions?  Yeah.  So the question is basically that we have to...  So why we have to do it manually?  Well, it has to be like that.  Exactly, automatically I mean...  So here we have to migrate the server to the user1.  So here right now the focus is on the very consistent term that is going to operate through the export.  So this will add another layer basically that will make this will be much more basic concept.  At this point the old export challenge was to first have a unit data meter data for hard which is understood for other versions of the export data including the metadata and the import is possible to do in the main way.  So you can think of how the tie values will change.  Can you open the import command that will help?  There's a little feature which could be very interesting for lots of other people.  You can even change the utility.  My interface is...  Is it working with changing the utility already?  Not right now.  But it's planning to be out there. So by the way, we can do that manually. We create these values, but we pre-sort the metadata, bounce the parameters and we can give them...  Is there probability to have an import? All is for call.  Is it right to have a unit for the users?  Because they can do it in cache.  They can have state heat to do this.  Because I'm not sure if they will make a backup from that. I mean, there's probability to make one.  But that applies to any script that you're making by a monitor.  We decided to not automatically tie the whole thing, not to make a re-automation.  This is how security will do automatically.  So, you focus your really on the challenges.  This takes more than one time to manage the data.  You see a better time to manage the data.  And you have to open the repository for that.  So you can have a look at the code.  And by feedback, you have possibility to ask more questions.  Yeah.  Thank you.  It's very great to have this...  Could I see the old instance?  The browser again.  So there you have two files, two shares from the old user and from the new server.  You would have to delete the old user in their own instance to make this share easier.  Because I see there I have the same file twice, right?  Yes. We decided to not delete any file, nor share.  Just in case something goes wrong and we can retry.  I can remove it afterwards for COK, import the new instance, but well, I can delete the old...  Yeah.  Yes. Once we have finished the import process, you can delete the old users.  Okay.  All the new export files do take care about file versions and addresses?  What's the next question?  Right now I think we have only file version that we have exported and trash bin I think is on the way.  And tags?  Tags I think is also planned now.  I think so.  You have to make new account with the file.  I don't know about the old one.  But you have another same domain, you can see it on the page.  We reserve the intersection.  Yeah.  You know you will have to double pay.  What will happen if there is a user to first system export data and there is a user to the system?  By default, we'll reuse that account if it's possible.  But it's not even version now.  I think that's not the question that the problem is that there are files that appears in the second system where there is a new user to the system.  Now you can send a new user ID or you can choose an existing user ID and you will just add the data by default.  That's not the problem.  As long as the backend is the same we can reuse the user account.  So more questions?  What do you think about groups?  We have some plans also for migrating groups.  We have in tech just that.  You will not get remote group chat.  Let's go back to the question.  We cannot group the new users and group the new users.  We will not care about the members of the group to have them the same way.  If they are the same way, you can export them in the same way, you can also add the group chat.  And that will be the same thing.  You will not be able to make a lot of groups chat because you will not care about having groups set up the same way.  So I have to make sure that the group and the user automatically can add the group or you have to take care of the subject.  You can export the groups and you can align to the list of groups that people have.  So if the new cases for migrating is not a major problem.  You can also modify the data.  It's a basic format and you have two sets of revocations.  You can't even manage the data or fit the data.  There is a lot of functionality.  You need to find a way to deal with challenges like that.  You want to fit or change the data.  There is a lot of possibility because it would be really powerful.  You want to work with the people.  So the groups will be kept.  The user name changes.  It was cut as a stop-shift for example.  I would belong to the same group.  Very likely, yeah. I think we can do that.  How about the end-up users?  Would it be possible to link with the new home-cloth server with the end-up stream or whatever  so that they can be really important to the preference of the end-up?  As long as the user ID is the same, yes.  If the user ID changes, we can do that.  Maybe with the alias we can somehow manage to rewire the user,  but it's something to test anyway.  I choose a different data configuration that I should be in comparison with the previous configuration.  Well, but that will change the user ID of both users.  So if the user ID is different, we can rewire it.  So, more questions?  And that's all.  Thank you.  Thank you.
ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_0_71.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_72_203.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_204_515.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_516_611.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_612_1151.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_1152_1679.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_1680_2435.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_2436_3647.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_3648_5159.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_5160_5795.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_5796_6995.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_6996_11387.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_11388_11435.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_11436_11519.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_11520_11675.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_11676_13667.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_13668_14363.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_14364_14447.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_14448_15779.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_15780_19043.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_19044_19163.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_19164_19211.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_19212_22463.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_22464_26315.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_26316_26387.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_26388_26615.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_26616_29327.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_29328_29711.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_29712_32807.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_32808_34535.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_34536_39659.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_39660_39767.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_39768_39815.png ownCloud_conference_2018_Data_exporter_app_showcase_-_live_demo_uh1AF6h4IWI_39816_39956.png