WEBVTT 00:00.000 --> 00:13.560 Yeah, hello. One question upfront, who was here in this talk last year? Okay, only very 00:13.560 --> 00:18.360 few people, that's good, because I believe in some slides I copied from last year, just 00:18.360 --> 00:27.920 to give an intro into the topic. So, overall, what's SME3 Unix extensions? Essentially, 00:27.920 --> 00:38.400 what we do want to do is, in drastic words, kill NFS. And that's a very great. I know 00:38.400 --> 00:46.240 this won't happen until I retire, but what can you do? So, why? So, in my world, we have 00:46.240 --> 00:53.720 two dominant file system protocols, the one is NFS, and which is native and historically 00:53.720 --> 00:59.720 native to the Linux, or Unix, or Solaris, or AIX, or whatever. And that's SMB, which comes 00:59.720 --> 01:10.040 from the Windows world. And NFS has really native support in all Unix's, in all Linux's. 01:10.040 --> 01:16.080 It's pretty simple to set up initially. You just edit some files in EDC export, or add some 01:16.080 --> 01:22.080 lines in EDC exports, and it just works. So, you don't have to think about authentication. 01:22.080 --> 01:27.320 You don't have to think about security, nothing it just works, which is very, very handy 01:27.320 --> 01:37.760 for simple setups that you just want to quickly set up and so on. It is reasonably compatible 01:37.760 --> 01:47.080 with what Windows application expect. It's not 100% local coherent. One particularly bad 01:47.080 --> 01:54.480 example is how to delete open files. I hold a file open, I delete it, and in a local file 01:54.480 --> 01:59.520 system like X4, it just disappears from the namespace. The data is still there, it will 01:59.520 --> 02:06.320 still be hailed, held in NFS, NFS has to play tricks and rename that to dot NFS, and then 02:06.320 --> 02:12.960 some long number, and just for the file to still be accessible, while it's still open on 02:13.040 --> 02:26.320 the client. In plain NFS metadata cashing is particularly bad. So, one example is the file M time. 02:26.320 --> 02:31.680 There are applications which depend on the last modification time to be accurate, and this 02:31.680 --> 02:39.040 just doesn't work over NFS just because always if you want to do a stat, the M time can 02:39.120 --> 02:44.800 always change, and you don't need to do cashing, and there is no coherent cashing mechanism 02:44.800 --> 02:51.680 at all. Then, file locking doesn't work at all, for reasonably okay. I can't say it doesn't 02:51.680 --> 02:58.720 really work at all, but it has very bad corner cases. There's a huge discussion about, or there's 02:58.720 --> 03:04.960 a huge section in the NFS before IRFCs, how to make locking work, how does the server notice 03:05.040 --> 03:09.600 when a client has gone? How does a client notice when a server has gone? How do we retain 03:09.600 --> 03:17.200 locking state? How do we establish locking state if both are back? A lot of work. Next point, 03:17.200 --> 03:24.960 there is no file security, and in general, I mean, yes, you can make it secure with courberals, 03:24.960 --> 03:31.600 but I have yet to come across a scalable or scaling large deployment where you have courberals 03:31.680 --> 03:37.920 NFS, and people are happy with it. That combination is the piece that makes it difficult to achieve. 03:40.240 --> 03:49.360 SMB, on the other hand, also similar goal, just share files and directories, and very similar 03:49.360 --> 03:58.560 goal from like 10 miles above, with some differences, it's secure by default. In any sense that 03:58.640 --> 04:08.320 you have RF, authenticated connections, you can easily just enable transport encryption, 04:09.360 --> 04:14.960 transport signing is mandatory anyway for a few release now of the SMB protocol, so 04:17.120 --> 04:22.960 in the default installation, it's much more secure from my point of view than NFS is. 04:22.960 --> 04:30.720 When you have a decent mechanism for cash coherency, I know that NFS we fought out something, 04:31.600 --> 04:40.080 added direct releases, added leases, and they call it delegations, but it's not implemented everywhere, 04:40.880 --> 04:48.560 so SMB has all this really embedded into the core protocol and everybody just implemented. 04:49.520 --> 04:57.200 Locking works in the protocol as such, and this is because Microsoft has to be compatible with local 04:57.200 --> 05:03.840 applications, and you can say a lot of bad things about Microsoft, but they are really good at 05:03.840 --> 05:10.400 one thing, which is application compatibility to the core OS. This means they have to make lock 05:11.120 --> 05:16.320 in work, and it just works across the protocol. There might always be problems, of course, 05:16.960 --> 05:25.200 with implementations, but the protocol provides good locking, and yeah, so it was just everywhere, 05:26.160 --> 05:35.280 and if you just read a little whatever intro, it's not really much more complicated than setting up 05:35.360 --> 05:41.040 ETC exports, adding a line there, and the server will just work. Of course, you have to take into account 05:41.040 --> 05:48.640 this secure by default, you have to take care about users and groups, but yeah, this is a downside 05:48.640 --> 06:02.320 of NFS I would believe. So, from in my world NFS is pretty arcane, and I come from the SMB world, 06:02.400 --> 06:08.960 of course, so take this with a grain of salt. We want to make SMB a competitor to NFS. What does 06:08.960 --> 06:16.640 that mean? There is, of course, the Linux client, by the French, that where you can mount SMB 06:16.640 --> 06:25.120 shares, but they have severe limitations when using these clients against native SMB without these 06:25.200 --> 06:32.640 extensions. In particular, in this is what I'm going to talk about, we have fine-name handling, 06:33.600 --> 06:42.160 we have POSIX metadata, and we have special files. You want to run your SSH-added agent, 06:42.160 --> 06:49.440 you want your SSH agent on your client to open a socket where your home directory is on SIFS, 06:49.760 --> 06:58.640 or, yeah, SMB mount.SIFS, it's still called mount.SIFS. When you have your home directory on 06:58.640 --> 07:05.280 SMB, you want your SSH agent to open a unix domain socket, and that has to live on SMB. 07:05.840 --> 07:10.800 And this is something plain SMB doesn't do properly right now. How do we do this? 07:11.760 --> 07:19.680 The SMB's two protocol is really open. It was designed with extensibility in mind. 07:20.800 --> 07:27.440 The first thing we do is we call it negotiate protocol. Client tells the server, 07:27.440 --> 07:31.600 hey, I have these capabilities. As the first packet, completely unauthenticated. 07:31.600 --> 07:36.640 First packet is, okay, I want to speak this version, I have these extensions and so on. 07:36.640 --> 07:42.720 Please server tell me what you can do. As a client we offer the ability, hey, we are speaking 07:42.720 --> 07:46.720 POSIX extensions with a negotiate context. That's what it's called technically. 07:47.920 --> 07:53.920 Server tells us, yes, I know. I know the extensions and it answers properly. If it doesn't do that, 07:53.920 --> 08:00.080 it just ignores this request and we can now figure out, yes, the server can do 08:01.360 --> 08:04.800 POSIX extensions. What would that activate? 08:06.800 --> 08:17.600 That would activate that when we deal with file names, we are privileged or we can send a 08:17.600 --> 08:24.880 so-called POSIX create context. So, server tells us, yes, I know POSIX. And then when we open 08:24.880 --> 08:31.520 a file, when we start a file essentially, when we look up a file name, we can tell the server, 08:31.600 --> 08:37.600 yes, for this file name, please handle it POSIX like. Which in particular means, 08:38.720 --> 08:44.880 it's case sensitive, because that's one of the main differences between Linux or within NFS, 08:44.880 --> 08:53.440 between NFS and SMB. SMB is case in sensitive. So, you can only have one file test or text. 08:54.240 --> 08:59.360 In NFS, you can have a gazillion file test or text with different upper case lower case 08:59.360 --> 09:07.760 combination. And we can tell on a per call basis, yes, for this file name, please treat it in the 09:07.760 --> 09:16.720 POSIX way. That's long implemented. Then you want to query POSIX metadata. What is it? 09:17.600 --> 09:24.880 If you look at the statuses call, it's structs.net, there are things that POSIX knows a file that 09:24.960 --> 09:34.320 NTFS doesn't natively know. Yes, we have owning group, we have owner and so on. We have a lot of 09:34.320 --> 09:40.160 things in common. For example, one thing we don't have is number of links, number of heart links. 09:42.000 --> 09:48.320 The POSIX permission bits, yes, you could probably hide them in whatever anacle is style of 09:48.960 --> 09:57.920 but the POSIX permission bits are particularly hard to get. So, we added them to a so-called POSIX 09:57.920 --> 10:06.240 information class. I'll talk about that in a minute. We have all this documented as an protocol extension. 10:06.960 --> 10:12.560 Go there. That's just a pure document. That's not code. Go there. And this is, of course, open 10:12.560 --> 10:24.400 for discussion and extensions. Coming back to this, SSH agent. And SSH agent wants to open 10:24.400 --> 10:30.640 or debug server, debug session server. SSH agent wants to create a socket in my home directory. 10:30.640 --> 10:37.040 It can't right now. And there are other cases here. For example, if you want a discless boot, 10:37.120 --> 10:42.240 you also need block devices and character devices. And so on. All the, you want to represent 10:42.240 --> 10:49.600 properly all these file types beyond regular files and directories. Of course, Samba, 10:50.640 --> 10:55.200 since inception has done files and directories, obvious. I mean, otherwise you wouldn't be a file server. 10:57.280 --> 11:01.840 But what do we do about the others? Block devices, character devices, and so on. 11:07.120 --> 11:11.120 What's the block device? What's the character device? Essentially, in the Unix Word, 11:11.840 --> 11:19.520 this is a link to hardware on the local system. I open Dev SDA and I get direct access 11:19.520 --> 11:24.400 to the blocks on my scuzzi disc or whatever is behind Dev SDA with these days. 11:27.200 --> 11:34.400 So if I now present a block device over a network protocol, there's essentially two choices 11:34.400 --> 11:42.000 that you could make in theory. I could say, okay, I'll open Dev SDA over a network protocol. 11:42.720 --> 11:51.600 And the question is, who interprets this as a device? And Dev SDA might still be a reason to say, 11:51.600 --> 11:56.080 okay, I opened Dev SDA over a network protocol and I want to look at the server side 11:57.840 --> 12:03.760 hard drive. Could be reasons for it. I think it's not a good idea, but there could be reasons for that. 12:04.800 --> 12:09.120 The example I gave there, Dev now, you don't want to send the garbage, you want to send to Dev 12:09.120 --> 12:17.520 now over the network for the server to just throw it away. So the idea here is that if a character 12:17.520 --> 12:23.360 or block device is presented over the network, it's only an indication for the client system 12:24.400 --> 12:29.760 to look at the local devices it has. That's the idea. 12:30.240 --> 12:37.200 FIFA's and sockets, what is that? Essentially, that's an interprocess communication mechanism 12:37.200 --> 12:45.200 for processes local on a system. Here as well, you could argue that, okay, I want to open a socket 12:45.200 --> 12:52.400 on the client and I want to talk to the server process. You could argue that. This is in general 12:52.400 --> 12:58.800 not what we want to do, because again, we want to have the SSH agent. I don't want the SSH agent 12:58.800 --> 13:06.000 to run over SMB on the server. I want to look at it locally. So my home directory needs sockets 13:06.000 --> 13:17.280 to be presented like local sockets. Same for FIFA's. We already do handle sockets as a cross, 13:17.280 --> 13:24.160 cross node network interprocess communication mechanism. There's a special share in the Windows 13:24.160 --> 13:31.200 work called IPC Dollar in the process communication. Dollar means not visible. We do that for DCRPC, 13:32.160 --> 13:37.520 printing, remote registry, a whole bunch of others. We have patches pending for the Windows search 13:37.520 --> 13:46.000 protocol, which is not DCRPC but raw pipes. So we already do that in the process communication 13:46.000 --> 13:52.320 mechanism over the network for special cases for this share for the general home directory you don't want this. 13:54.400 --> 14:01.040 Then the last one, some links. There's, I mean, really heated discussions and even the rust 14:01.040 --> 14:07.760 community was hit by a simling race. Everybody was hit by a simling crisis. So the question is, 14:08.640 --> 14:14.320 are some links a good idea overall? I mean, they are there. You could argue and know you don't need 14:14.320 --> 14:19.520 some links. You don't want some links just make them go away. It won't happen. We all know that 14:20.400 --> 14:28.400 the only thing is the server should not bother. And if you look at the NFS RFCs, symbolic links 14:28.400 --> 14:34.640 are not a server thing in the NFS specification. It's only a client thing. Somebody historically 14:35.600 --> 14:43.760 has treated simling's server side. And I will show example, an example later on. We fixed that. 14:44.640 --> 14:55.440 Okay. Locking character devices, sockets, fifos, special types of files. So we could extend the 14:55.440 --> 15:03.280 protocol with all these things. There is a native Windows mechanism called repass points. 15:05.040 --> 15:12.160 That interestingly enough, the Windows based NFS server also uses to represent sockets, 15:12.800 --> 15:20.720 sockets and all the other ones. The NFS server on Windows uses repass points. What repass point? 15:22.720 --> 15:32.640 Essentially, it's a mechanism to extend functionality of the NFS file system. What does it mean? 15:32.720 --> 15:41.840 You take a file and essentially you just create a special extended attribute on that file on 15:41.840 --> 15:52.880 NTFS. When this extended attribute exists, what happens at open time is, the native NTFS 15:52.880 --> 16:00.160 implementation sees, okay, this extended attribute exists. This extended attribute then points 16:00.160 --> 16:07.680 at some DLL on Windows, dynamic link library, shared object, Linux, and when this extended 16:07.680 --> 16:14.880 attribute exists, essentially some function is called to take care of this whatever special 16:14.880 --> 16:22.480 functionality for this file. Essentially, you can intercept open calls. That's what the repass 16:22.640 --> 16:31.680 point is, and this is what they used here. They have a special error message. So you set 16:31.680 --> 16:39.920 a repass point, extended attribute, pointing at some DLL and that DLL is stressed out there. 16:41.280 --> 16:47.920 When trying to open that file, all you get is repass tag not handled, which is fair, because I told 16:48.080 --> 16:54.560 the system, hey, use this whatever hierarchical storage management mechanism to open that file, 16:54.560 --> 16:59.040 but whatever HSM software was installed, repass tag not handled anymore. 17:00.960 --> 17:09.360 And so this is, as I said, a general mechanism to extend NTFS functionality with some magic. 17:09.440 --> 17:19.120 MSFCC, that's one of these several thousand lines of document. Google for this in brackets MSFCC, 17:19.680 --> 17:27.440 and that's one of the documents that Microsoft have published. They define a few dozen repass 17:27.440 --> 17:34.240 tags, which is special, extended attributes. This repass tag does that. This repass tag does this 17:34.320 --> 17:41.760 and so on. They have to define some of these. Some of them, or most of them, are not meaningful 17:41.760 --> 17:46.320 over the wire, which means we don't document, we don't want to document them. 17:49.040 --> 17:55.680 The Windows NFS server just does exactly this. It uses repass points to represent 17:56.000 --> 18:07.840 special files, like Firefox, sockets, and all the others. So when Windows NFS client comes in and does a 18:07.840 --> 18:16.080 make-not or a socket call, what the Windows NFS server does is it creates a file, it attaches a 18:16.080 --> 18:23.440 data name it here, special defined repass tag NFS, one of these special extended attributes, 18:24.400 --> 18:30.080 and as content of this extended attribute, they have the major and minor device number if it's 18:30.080 --> 18:39.280 a block device. This is what they do, and they define subtypes of this extended attribute, 18:39.280 --> 18:48.000 just look up this spec, I mean it's pretty obvious. They have NFS siblings. Interestingly, 18:48.960 --> 18:57.360 Windows properties shows just L for all of these, which means it believes the Windows 18:57.360 --> 19:03.280 explorer application. Beliefs whenever there's one of these repass tags, it's a native Windows 19:03.280 --> 19:13.360 signalling, but that's just a GUI glitch I would say. Okay. So now we have established that 19:14.320 --> 19:21.760 we want to, when a Samba server lists slash dev, you will find all sides of special devices, 19:21.760 --> 19:28.880 if you do it, L is minus L on slash dev. The very first column is the file type. 19:30.640 --> 19:37.840 If you look at the read here, system call, which is get the entities days, but if you look at the read 19:37.920 --> 19:44.320 here documentation, all you get, when you application on Linux does a read here call, all you 19:44.320 --> 19:48.880 get, it's a name essentially. There's more, of course, but all you get is the name. 19:50.320 --> 19:57.840 And if L is minus L, wants to attach nice colors to sockets and nice whatever, there's a pin 19:57.840 --> 20:04.640 for pipes, it has to stat every time. For each of the name, 10 minutes, thank you. For each of the 20:05.600 --> 20:11.520 name, which means round flip to the server, because the NFS read your call only gave names. 20:12.320 --> 20:17.920 This is why they implemented read your plus, which already in that first run gives 20:19.360 --> 20:27.120 the attributes, the relevant attributes. SMB does exactly the same. When you do a read your call 20:27.120 --> 20:33.520 over SMB, you can ask so called info levels. So this is essentially a read your plus plus, 20:34.080 --> 20:40.400 with roughly maybe 10 or 15 different info levels defined with different level of detail. 20:40.400 --> 20:50.720 And what we did is we added another info level for projects. And if you listen to all of these 20:50.720 --> 20:58.720 SMB specific Unix extension talks, there was a hot debate, what style of similar videos, 20:58.720 --> 21:04.080 what a story, what style of repass points we use. There's not only the NFS server, there's other 21:04.080 --> 21:09.280 applications, there's Windows subsystem for Linux using its own repass points, and there are 21:09.280 --> 21:17.360 downside and upsides for each of these specific ways to represent repass, represent special files. 21:18.400 --> 21:27.600 And what we settled upon is, we have extended our struct info level. We have extended 21:27.760 --> 21:32.560 an info level for structs that. And this is the first thing I want to show you here just 21:32.560 --> 21:43.840 upon wire, short trace. So, pause it's read here. Can everybody read that? 21:44.560 --> 21:53.040 large enough. So, going down, going down, going down, find requests. I mean that's, yeah, 21:53.760 --> 22:03.120 that's the way to ask for read the information. And this is a directory with a lot of files in 22:03.120 --> 22:10.320 there. And we could probably extend wire, short to show the name here. But what we do, what we find here 22:10.320 --> 22:22.560 is, it is a name called a file called FIFO. And that's what we think, what's missing in the summary. 22:22.640 --> 22:28.800 So, I just didn't realize in a directory with a FIFO called FIFO. And I mean, that's really pretty 22:28.800 --> 22:42.720 detail. We represented as repass tag NFS. But the point is, the shift client with just repass tag NFS 22:42.720 --> 22:48.880 should have asked what's the content of the repass tag. To find out, is it a socket, is it a FIFO, 22:48.880 --> 22:56.240 is it a block device? And this is something that got an a hunt, hot debate. And the way we just 22:56.240 --> 23:02.640 solve this is, we already have pause-expermissions. And if you look at normal pause-expermissions, 23:02.640 --> 23:07.840 I mean, there's a few bits in the 32 bit mask left out of those nine. And we just defined, 23:07.840 --> 23:13.440 okay, we have space here. The old tactic, okay, don't really extend the protocol, just use some 23:13.680 --> 23:18.960 unused bits. And this is kind of, no, that's one thing that's new since last year. 23:20.240 --> 23:29.040 That LLs minus L is just as efficient as Retier plus NFS. That's one of the things 23:29.840 --> 23:32.960 that are new. And which are, I think, a good way to do things. 23:33.680 --> 23:49.120 Okay. Simnings. And I don't have too much time left. We have three ways, or I think there 23:49.120 --> 23:58.000 was even one more way. We have three ways to repress in Simnings. One is, Windows subsystem 23:58.000 --> 24:05.360 for links, it finds its own Simnings. And if S has yet another version, and then Windows and T has 24:05.360 --> 24:10.400 Simnings. I mean, Windows does have Simnings. They also have hard links, but that's another story. 24:10.400 --> 24:16.640 They have Simnings in NTFS. And we settled on, I already passed Tag Simnings, 24:18.240 --> 24:26.320 the native Windows way, for one specific reason. So LS had Simnings, races are 24:27.200 --> 24:32.480 present all over the place. They have been present in the Simnings server side. We solved those. 24:33.360 --> 24:38.000 But we want to get rid of Simnings handling in the Simnings server completely. 24:40.000 --> 24:48.000 What do we do? When we hit a Simnings, we just tell the client, I had to stop on Simnings 24:48.960 --> 24:54.160 and let the client deal with it. And there's a very nice error message, and I want to show you 24:54.160 --> 25:08.800 that as well. No. Okay, what did I do? I have a directory, and there's a sub directory called A. 25:09.360 --> 25:18.160 This one here. There's a sub directory of that called B. And within that sub directory, there's a 25:18.240 --> 25:36.320 Simnings, that points at B. B, CDC, extra text. What did I do? I try to open the file A slash 25:36.320 --> 25:55.920 D slash C slash X dot text. Oh, that was it. Crab. Here we go. 25:56.480 --> 26:10.960 And this is the error. So you'll see here, I try to open A slash D slash D and so on. That's 26:10.960 --> 26:18.160 what I try to open this here. I hit the Simnings, and what I want to point out here is this 26:18.240 --> 26:22.240 really nice error message, and I like actually like that, which essentially tells me, 26:26.240 --> 26:37.120 if I could now click correctly. Okay, rep unpassed past it. What does it mean? 26:38.880 --> 26:44.480 It gives me this error message when trying to open that file gives me the Simnings target. Remember, 26:44.560 --> 26:51.840 I pointed D or at B. It directly in the error in the return gives me the target. It also tells 26:51.840 --> 26:59.920 me by a this field where the Simnings is in those path components, which means that the client 26:59.920 --> 27:05.440 can easily just from this answer, resolve that Simnings. Doesn't have to go back to the server. 27:06.640 --> 27:13.200 It can directly say, okay, the ultimate target file is this all information there. 27:13.840 --> 27:18.080 One thing around fab, Simnings can be completely on the client. The server doesn't have to solve 27:18.080 --> 27:30.880 Simnings. Okay, I'm a bit in a hurry. Long run in compute jobs. I said NFS secure, SMB secure, 27:30.880 --> 27:36.960 you need user accounts, a long run in compute job. Failure on that. Google for 27:37.760 --> 27:43.920 Daniel Cobras's talk with the GSS proxy. There's some first, I believe, first time talk, I don't know. 27:45.360 --> 27:51.200 Google for Daniel Cobras's GSS proxy talk brilliant works today. That problem solved. 27:52.640 --> 27:57.680 Current status. Our server side is done for all these special files. 27:57.680 --> 28:04.880 Server side returns stop on Simnings and has the client follow the Simnings. So we can represent 28:04.880 --> 28:09.760 Simnings. We can create Simnings. We can properly handle client-created Simnings with this. 28:10.640 --> 28:17.360 Linux 613 has positive special files and Simnings handling already there. Of course, 28:17.360 --> 28:25.840 backspending try to test it. The big missing piece is axles and that's another kind of 28:25.920 --> 28:29.600 warms. Probably that's a talk for next year. How would you like the act of? 28:33.040 --> 28:38.560 So from a server side, I would say pretty much done except for actals. Now we need client integration 28:38.560 --> 28:43.680 client. Clients doing the Simnings handling properly. Our lib SMB client has on that's pending work. 28:47.360 --> 28:49.040 That's it. 28:55.840 --> 29:03.840 One minute. One minute. The question was for extended attributes. 29:05.040 --> 29:10.720 The NFS, sorry, the SMB protocol natively has extended attributes support. So that's 29:10.720 --> 29:14.800 mainly a client thing to actually make use of those calls. 29:16.800 --> 29:18.240 Server side is implemented. Yes. 29:19.200 --> 29:25.200 How about the different checks with the TFS and WSL whatever? Are you implementing them all and 29:25.200 --> 29:29.680 using them at runtime depending on which files to say which brand of windows we have or how 29:29.680 --> 29:32.800 is this going to work on? How are you working? Can you say again? 29:32.800 --> 29:40.800 You showed the different checkpoints for WSL and the TFS whatever the NFS checks. 29:40.800 --> 29:44.960 Isn't them all depending on what's available in the runtime as well? 29:45.840 --> 29:50.160 Question was about these different tags. Do we use them all? 29:53.120 --> 29:59.760 Depending on what the client does. So the client is free to set the WSL reposted. 29:59.760 --> 30:07.120 And the way we do it and this is a slight ascript ascript. If a client does this to us, it just 30:07.120 --> 30:11.680 creates an empty file and sets a special extended attribute. That's what it does. And we don't 30:11.680 --> 30:19.680 care about those contents. This talk is about how do we represent things we find on this? 30:20.480 --> 30:25.920 When some of our finds a native socket on this, how do we represent those? If you list 30:25.920 --> 30:31.280 slash dev, how do you represent these things? And our decision is go with NFS. 30:32.560 --> 30:35.760 But the client is completely free to do anything. 30:35.760 --> 30:40.000 Time's up. I'm here.