My name is Ryan Lane. I'm from Wikimedia Foundation. I run a project called Wikimedia Labs. And today I'm going to talk to you about LDAP integration for OpenStack. So I'm going to do a show of hands. Who in here is an LDAP administrator? I apologize to you for the rant that is about to come from me. So there's a thing about LDAP, and that's like basically no one actually understands LDAP. LDAP administrators understand LDAP, but people that actually want to use LDAP don't really get it. And I've thought about this in the past as like, why don't people understand LDAP? They understand SQL, they understand NoSQL. And there's this trend in like going to NoSQL for things, because people don't want to deal with MySQL, they don't want to deal with the schema, and they don't want to deal with having to like know how to do their queries properly and indexing and things like this.  But this is much, much worse when it comes to LDAP. LDAP has a very strict schema.  Like when you actually want to do anything inside of LDAP, you can't. You can't do any rights. You can't change the schema, because the LDAP administrators won't let you do it. And this doesn't really make any sense. Like, I'm also an LDAP administrator, and I've been through this in the past. And I've really thought about this, and in the way that OpenStack works, and the way that the cloud kind of works now, we're moving away from a model where you have operators in control of everything. And with LDAP, this is also one of these things where we need to give up some control. So that's the question. It's like, why are we keeping control of these things like this? And there's a mantra that I think every LDAP administrator should chant to themselves before they tell a user no for something. LDAP is just another data store. This is just a place for you to store information. And specifically, this information is something with a strict schema that a number of different client applications understand because it has a strict schema. But part of this is that it's also for authentication and authorization, and LDAP administrators are seriously paranoid. They're worried you're going to write something into the LDAP database that can then be used by other client applications accidentally to give out authorization to clients. But realistically, LDAP is very fine-grained in its access controls. So there's definitely ways to control this and make it work inside of a cloud environment. And basically, this is just the end of my rant. It's just a rant. My talk is actually going to be about integrating LDAP with OpenStack. But to actually integrate LDAP with OpenStack really well, you have to give up some control. And so we're doing this inside of Wikimedia Labs. Some background on Wikimedia Labs. Its mission is to enable the world to treat Wikimedia's infrastructure like any of its projects in that anyone can edit it.  As a regular user, you can do these things. So Wikimedia Labs is meant to be a cloud environment where anyone in the world can come. They can join a project. They can start doing some infrastructure work. They can push changes into Puppet. We can deploy them to a top five website. We're actually giving anyone in the world root-level access to our actual technical infrastructure. So with this, we have this kind of concept of our OpenStack cloud that's somewhat different than public clouds in that we have the labs infrastructure itself, which we give a production level of support to. Inside of this, we have projects. These projects reflect real-world projects. So we have a tools project. This is partially maintained by the operations team, but it's also partially maintained by a volunteer community. And in this, we have things like bots that edit our different projects like Wikipedia and Commons and Wikidata, et cetera. We also have tools that people run that are too expensive to run on our cluster, but are expensive enough to run in this because if they just break, they break, and they have to deal with it. We also have some other projects like deployment prep, which is a beta portion of our environment that is a QA environment. We also have a community-made projects. So in these projects, we give a user a project. They can create virtual machines. They can give floating IP addresses. Just random people in the internet can have this access as long as it's Wikimedia-related. So inside of this, we have a very large number of fairly non-technical users. These users have basic understanding of how to write code and write bots that edit Wikipedia and things like this, but they're not operations people. They have need a little bit of hand-holding, and they need some things done for them automatically. So there's a number of things that we do inside of our projects on the user's behalf. The project is just a regular open-stack project, but we've extended this concept in a number of ways. For instance, inside of a project, users can create instances. Inside of those interest instances, they have immediate access to shared storage that's just for their project. So it's per project-shared storage, hopefully do in the future. Then we also have something called service groups. These are per project users and groups that users can create themselves that span across all of the instances. We also have MySQL replicas from our production environment. We take the data that is on Wikipedia in the databases, and we replicate it into this environment in a sanitized way so that they can do queries for research or tools or bots and counter-vandalism and things like this directly inside of this environment. We also have pulled out the idea of SSH keys from being an open-stack. I'll explain why soon. But the thing about these MySQL replicas is that they're available to every single project inside of the entire environment. So this is something that's not really supported by something like Trove. We've had to do some interesting things to make that work. And all of these things, for the most part, we're using LDAP to do, and we're using LDAP to create a multi-tenant environment inside of our open-stack environment. So this is our directory information tree. And in this directory information tree, we have the Keystone information. That's the users and the projects. Then we also have a set of global information. This is information that's available to every single instance across every single project. And that's user information, group information, hosts for DNS. This will hopefully move the designate. And hosts is also for Puppet as well. Then we also have autoFS information that's global. We have pseudo-words information that is global. And this is so that we can set up global shares that each different instance can access, like home directories, per project shared data storage that's just available automatically when people create instances or projects. And then we have global pseudo-words information so that us as the operations team have root on every single instance. So here's our user objects. There's a set of information that's used for Keystone authentication, and then there's a set of information that's used for Shell authentication. The username, password, and email address is for Keystone. The UID name, the UID, the GID, and SSH keys are for Shell authentication. Similar here are instance objects and host objects. These are in the hosts OU. The instance object holds both DNS information for each instance, and it also holds puppet information for each instance. Then we have separate host objects that also exist in the hosts OU, and that's used for public IP and public DNS information. We're using pDNS with an LDAP backend for all of this information. It points into LDAP in the same places. Then we also have global groups. Those are in the group OU. We have a couple special groups. Well, a couple sets of special groups. We have a Shell group where when we give people shell access, that allows them to get shell access in any of the projects, but it doesn't actually give them shell access yet. It just allows them to have it or not. So if we remove shell from someone, they're removed from the entire environment. Then we also have a set of project groups. So every single project that we create in OpenStack makes a global POSIX group that can be used inside of all of the different instances in each one of the different projects so that you can do access controls inside of the projects using group information. So you can do cross-project shares that have NFS information across them. You can set up a number of different things like that for authorization, PAM, et cetera. Then we have project-specific information. So looking at the DIT, this is under Keystone's information. And then under each individual project, we have a full set of OU's that are specific for those individual projects. And so we have users and groups. We have pseudoers. We have autoFS. And any other thing that we want to add in there, we can. It's under each individual project. So it's per project. It's basically a per-project root for each different project so the instances can be configured to use those roots. So for this, autoFS, we have autoFS, and the autoFS itself is manageable by the project admins. We have the global autoFS that makes things accessible to every single project. But then we also allow users to add their own autoFS entries so that they can set up shared file systems, maybe through Manila or something like that, and then have the ability for these to automatically be created as autoFS entries so that all of their instances automatically get that share. These, of course, override the global policies. So, for instance, if that project doesn't want to share global home directories, they can override those home directories or a project-specific set of home directories. Same thing for the project storage, et cetera. For the pseudomers' information, similarly, we have global policies. These policies are actually merged with the project-specific policies. So project-specific policies can't override global policies so that they can't take root away from the operations team. These are... Users that are project admins can go in and they can make new policies saying, like, these sets of users or these sets of groups have root on these sets of instances inside of their project so that they have the ability to control access within their projects. Similarly, we have a concept called service groups. So the users and groups information that we allow people to create inside of LDAP is basically... you create something called a service group. The concept that we had was that users need to be able to create system accounts, but we manage everything through Puppet, and everything that goes in through Puppet has to be approved by the operations team, which puts a very large review burden on us. So instead of requiring people to push in system accounts for everything they do in their project, instead we give them the ability to create project-wide system accounts. And these are we call service groups. When you create a service group, it makes both the user and group that is the same name. Inside of the groups themselves, you can add any project member into that group. One thing that we also do with this is we integrate the sudoer's information with this. So when a service group is created, a sudo account is also automatically created with... a sudo policy is also created with that. So you create the service group and user, and then a policy that says any user that is a member of this group is allowed to sudo to this user, thereby giving them access to the system account and allowing them to install software underneath it and things like that. So the basic flow of how we do things inside of labs... So when an instance is created, as the user creates an instance, our system automatically creates an LDAP entry for this, which has the puppet information and the host information for DNS. Then it also injects a small amount of user data, which actually we've kind of pulled that step out. We make images that have this information pre-populated. But then it goes through and it joins Puppet. The Puppet Master sees that there is a signing request. It checks LDAP to ensure that this is actually something that's in LDAP and was created by someone. It signs the request, and then it builds the instance. When the instance builds, Puppet automatically does a certain number of things on the system. So looking at the instance configuration, this is the NSLCD configuration. It sets up the base, which is the root of the entire directory information tree, and then it sets up global users and groups in the NSLCD.com, which sets up the global OU for groups and users, which is people. And then after that, it sets up another set of roots, and these are specific to the project itself. So it sets up the same exact thing for groups and users, but it uses the project sub-drate. So this exposes the service groups and users to every instance in the project. So we also use access.com, and one of the things that we do in here is we allow root for everything because then the system breaks without that. The next thing we do is allow the service groups to be available. We have a naming convention for the project roots, which I'll go over later when I discuss how we integrate Garrett with all of this. We have a very specific naming convention for compatibility reasons with some things. But basically, we allow the service groups next, and then after that, we ensure that the user is in the shell group. If the user is not in the shell group, they get denied access. After that, we allow every project member. So we're using the POSIX group that the user is a member of to allow or deny them access into that project. So if someone is not a member of a project, they can't SSH into the project. And now I should go back to why we're pulling the SSH keys out of OpenStack. We don't allow OpenStack to actually inject SSH keys into our instances at all. We have a global NFS share that's read-only. We have a script that pulls all of the SSH information from each individual user and then writes that into the user's sets of authorized keys file. We set up SSH to... I think I have SSH in here. I forgot the SSH slide. Sorry. We set up the SSH daemon to both read from Roots authorized keys file and then also the NFS share for the SSH keys for all of the different users. This allows us to... When a user creates an account in labs, they automatically have global access to every single project, but only assuming that they're in that project group for these different projects. Similarly for SUDU. A lot of different things have this concept of being able to add multiple Roots, so that's really easy. So the SUDU is Root. The first one is the project subtree added in from the user's policies and then there's the base one as well. Actually, I guess this does allow... I think this is probably flipped in production. This allows SUDU to be overridden, but it's flipped in production. Similarly for AutoFS, you have the ability to set multiple bases. So this allows the project subtree being first to override the base configurations. And this allows it to pull policy from multiple places. We also set up something in the options so that you can use variables inside of your definitions. So we have project-specific ones that can be used. You can pass options into AutoFS for variables, and we use Puppet to set that project name there. And that allows you inside of your AutoFS definitions to use that project variable to actually reference your own project name. So then we have Garrett integration. Garrett does not support the concept of multiple bases. So there's some configuration challenges that go along with that. Garrett does have LDAP integration. It can pull groups from LDAP. So the concept that we went with is to point the Garrett LDAP configuration for groups to the root. And by doing this, we have the POSIX user object class. And so by doing this, it can pull the global groups information, and it can pull each one of the different project-specific service groups so that in Garrett you can allow access to the groups by service groups or by each individual project. So you can create a repository, and then you can give access to that repository to an entire project, or the members of that project, to access to individual service groups inside of that project. This allows each individual project or service group to maintain its own code. So one of the things that we had to do to make this work is that we have to make everything globally unique for groups. And so the naming scheme that we went for with the POSIX group was project-name, and there was a reason that we used project-. We originally did not, and then we had people creating groups like Apache, or projects like Apache and root, and other projects like that, giving them immediately access to the root group or the Apache group, which is really dangerous. So we prepend this to make it something unique on the systems themselves, and that's per project. And then inside of the projects, we have the service groups, and the service group names that we use for that are the project-name.the-service-group. And this makes the actual service group unique across all of the different projects in LDAP, so that you can use them in applications that don't have the ability to do global and then subtree configurations. Saltstack is an interesting integration with LDAP. There's actually a lot of ways to do this to make it multi-tenant. One is that you can use environments. So each project would be a different environment. That information can be configured via LDAP by setting the environment of the instances or the minions to use the project name as their environment. Similarly, you can also use Git for all of your pillar information and your state information and some other things underneath Salt so that it will automatically switch between branches. So you can set up branches for each one of your different environments that then also allow people to push Salt code into their different branches, which they have access to through Garrett, by giving them access via the projects. Additionally, you can set up a grain for each one of the different projects. So when Puppet runs, it'll add grains into the configuration for Salt so that you can target instances inside of a project as an admin by using the grains. Unfortunately, the grains are something users can just set up, so you can't really trust that. So one of the other things that you can do is you can use pillars, which are global configuration, but they're managed by the server. So not only can you do pillars that exist on the server itself, but you can also pull these from an external system, which could be OpenStack itself or it could be LDAP in our situation. And with these, you can target instances inside of a project using their pillars, which are something that the users can't modify themselves. So this gives operations engineers the ability to make calls across the entire environment or individual projects inside of an environment. Past that, Salt also has a peer system that allows minions to call things on other minions or sets of other minions inside of its own project. So by making a combination of the pillar system and the peer system, you have the ability to grant access to one instance inside of a project and to make calls against all of the other instances in a project, thereby giving your users the ability to do remote execution inside of a project. Similarly, there's a lot of other things that you can do. One of the things is there's a Salt API which provides a REST API interface that you can write modules for so that you can give users the ability to pass in calls to the Salt API using possibly Keystone integration if someone writes the Keystone integration for this, please do, I want it. Which would allow you to do Keystone authentication for remote execution calls outside of the entire environment, just like you would with Nova. There's a ton of other possibilities with this as well. I would go over Puppet, but Puppet is actually fairly limited in how its LDAP integration works. We are using Puppet for LDAP integration. It's using the LDAP ENC. But unlike Salt where you can use the environments in some same way by having branches and things like that, there's no way to really control in Puppet what users are allowed to run on the server since they can run server functions. So if they push code in and they do a Puppet run, they can own your master. So there's definitely some limitations in what you can do with Puppet which is why I'm not really going to go into any detail there. For my SQL itself with the shared replicas, this is a disgusting hack and probably no one else should do this, but the actual idea behind it is kind of interesting. So we have to give users in all of the different projects and the service users inside of these different projects access to the database information inside of these. We also have to give them the ability to create databases inside of this or create tables on replicas that we're pushing out. For this, we create grants for the different service groups and the users, but there's a limitation here in that mySQL has a username limit. It's a certain number of characters. So we had to come up with a scheme for mapping users to the databases and the scheme that we came up with was to use P and then their UID number and then U and their UID number for service groups so that it's the project's group ID and the user, the service user inside of that group ID mashed together. Similarly for global users, we just used U and the UID because those are unique across everything. And then we also allow the users to create databases and basically the grants that we give allow them to do this. The only real reason that we give grants for most of these things is that if we have a user in a project that's abusing the system making long queries, et cetera, that we can just block them. Because realistically, the majority of the data is replicated from another source. Then we also have NFS. So realistically, this is a terrible hack as well and I would like to replace this with Manila as soon as possible. We have a script that pulls LDAP information since we inject the puppet information and the host information into LDAP automatically when we create instances, we can use that information to actually populate shares inside of NFS. So we have scripts that run that say, give me back all of the instances in this project and we run this every once in a while and then we create shares with the IP information for the different projects. This is of course a problem because if you don't run it often enough, then if instances are deleted and recreated and then new instances are created in other projects, there's a race condition into which new instances may have access to data in other projects. So this is definitely something we want Manila for because in Manila when an instance is created or deleted automatically triggers something that would change the shares. We run this very often, we run it once a minute and we've made it fairly efficient so it doesn't kill us but if we had a large enough DIT this would not work. So with NFS there's also a problem similar to MySQL and that NFS has a 12 group limit. There's ways to get around this but basically if a user is in more than 12 groups the server will not understand any of the extra groups that's there. There's something you can do about this and there's one horrible thing that we've done is that we take a dump of all of the users and service groups that are in LDAP and we stuff them into a local group file. This is not fun but this is actually something even with Manila that you would have to do if you're going to do shares with multiple systems and have groups or users that are global at all. So with this this also puts another limitation on how we do users in groups and previously we had to change the system to make groups globally unique and that was for Garrett and this system we also have to make the UID numbers and the GID numbers completely unique as well. So there's some basic patterns that I'm using here and one is to use the project's OU for different things. If you want to limit access to a certain set of data, make an OU and set the system or service to use that project's OU for limited scope of information. Similarly there's also just filtering global information by using attributes and that you can say I only want instances back that have a project name of this thing and I only want to get the information back from that and by doing that you can have a globally flat scoped OU that has all of the information but you can filter by that and then there's a possibility of doing both like what we're doing with Garrett. We have the per project information and we also do filters by posting group. So are there any questions? So the question so the question is what actually when a project is created what creates the project information that goes along with it? Right so in our system we have our web interface actually does this when people create projects or instances. We have some hooks in Nova that will also do some of this information as well. In the future we'll probably use Designate for DNS and we'll put hooks in there for that. But basically it should be set up on some kind of trigger and whichever system is using the information is going to have to have credentials to modify that OU and in those specific situations you would want to create user accounts for each one of the different services that have limited access that only have access to do the things in the specific OUs. So you add ACIs to the OUs that allow those different services to only do their limited scoped things. So your question is did I choose to use LDAP to provide global information over using Keystone. So realistically I'm forced to use Keystone I would probably use LDAP for everything if I could. Keystone is problematic in some ways but realistically the answer is I chose to use LDAP because I have the ability to extend LDAP in ways that the systems understand. So LDAP has been a standard for a very long time and has a very strict schema. Different applications already have LDAP support and in that LDAP support it's fairly configurable on how you actually use it. So for instance I can't extend Keystone to do a lot of the things that I'm doing like the autoFS information etc etc whereas with LDAP I can just extend an OU, I can put information in that and I can scope things inside of those different OUs. So it's really more about flexibility than it is about anything else. So the question is whether I'm choosing one or over the other or if I'm really using them for different purposes one for the system level stuff and one for authentication and authorization. That is basically true I'm using Keystone for open stacks authentication and authorization and I'm using LDAP for basically everything else. Also we have some other applications that are not integrated with Keystone at all like Garrett and a number of other web interfaces like we also do Graphite is using that for authentication and a number of other management tools are using the same set of information where we can't use Keystone. So yeah, it's basically it. It's a method of extending something that is used by other systems that is native. Okay, so the question is how does Keystone integrate with LDAP in this situation? So I actually started off by using Keystones so I should actually say that I started using all of this when NOVA was the only project and during the Bayer release and there was some initial LDAP integration and I rewrote portions of it probably most of it and that's what ended up being the Keystone schema. So Keystone was kind of built off NOVA's LDAP integration and so I kind of built this around Keystone's schema or not the schema but the directory information tree. So I'm actually just extending Keystone's directory information tree. The LDAP integration that goes along with this is standard Keystone integration. So when you create a project that project information is then available inside of Keystone. When you add users as members of that project they're members inside of the project in Keystone, same thing with roles. We have role information that's underneath the different project I use and members are added inside of that as well and so all of that maps one to one. The question is is the password still in the LDAP directory tree and yes I don't use Keystone to do any user or group or role management. Our web interface actually does all of the management when a user creates an account in our web interface it creates an LDAP account and the password assigned is what the user enters, same thing with email address and all of the other information. We also add SSH information through that same web interface we don't use Keystone for any of these things. Keystone uses SSH in a read-only kind of way so it has the ability to pull that information back from LDAP and when it does authentication it just does a strict bind against LDAP. I don't write to LDAP by Keystone now that's not saying I would not if Keystone had good right support. Well in this case the application that we use is writing to LDAP and we're allowing the users to write to it. Not Keystone. Yes! Right. Keystone, the comment was basically that Keystone in Havana release has the ability to separate the authentication information and authorization information and so basically you can allow authentication to LDAP where your information is not stored in LDAP but or I should say your user account information is stored in LDAP but your project and role information is stored in the Keystone database and in my specific use case it's actually way more beneficial for my application in LDAP because then I can use that information for other things and so basically it's what Keystone integration is actually what's providing my multi-tenancy for other applications which makes it really powerful which is again one of the reasons I went in the rant at the beginning because people should allow you to write into LDAP. So the question is whether I think that we should have a managed system that writes into both Keystone and LDAP. When you say Keystone and LDAP do you mean Keystone? No, actually the way I would like things to go is for people to actually write into LDAP. The reason for this is because the point behind LDAP is that it is a system that has a strict schema that can be used by clients in a well-known way. So if you're writing into MySQL all of that information that you're writing into MySQL about projects and roles is gone for everyone else. You can only use it for OpenStack and now you can not use it for anything else at all which kind of defeats the point of like having an infrastructure that's multi-tenant. The question is does this affect the clients that actually talk to OpenStack? No, it doesn't because they still talk Keystone-native. So any of the stuff that they're doing that is OpenStack-native level things, they authenticate to Keystone, they get a token, then they get a scope token, they do what they're going to do. Any other questions? So was the question like so you're saying that by giving users pseudo access in one project that they can use that pseudo access to hop into other projects? So at least to be able to read information from their projects. So yes and no. By giving people pseudo access it only gives them the ability to access things within their same project. They can make policies in their project but the policies they can make only allow them to modify instance information, etc. We actually restrict that through a web interface. But realistically it wouldn't matter anyway if we allowed them direct LDAP and access to modify that and they put in instance names from other projects that wouldn't affect anything because the instances themselves are appointed to that individual subtree. So other instances from other projects aren't reading from that subtree so that information is ignored by everyone else. But otherwise for project hopping it's not actually a concern. We put a lot of effort into ensuring project hopping can occur. So like there are certain things that you could probably do project hopping with. For instance, if you allow people to pseudo and then write into global home directories it would be an issue if SSH keys were put into the global homes. But we actually split that apart and put it into a read-only OU and things like that. So there is definitely care that has to be taken when looking at doing global directory information trees and especially in regards to project hopping because it is a concern. Any other questions? Thank you.


Activate interlocks, dino-therms connected, and throw cells up, mega-thrusters are go. Let's go, Voltron Force. Coming up after this, I'll be talking about Season 2 of Voltron, Legendary Defender, only on Netflix. Stay tuned. All right, so Season 2 started out pretty good, it ended pretty good as well. There will be spoilers in this review, so those of you who don't wanna know what's going on in the season just yet, go ahead and click off, come back after you've watched the season, and watch the video. With that being said, the team is separated. Paige is on her own with some furry alien creatures, and then Keith is on one side of a planet, while Shiro's on another side of the planet, and Keith's gotta come help him. The lions are down, depowered for some reason, and Shiro's being attacked by what appears to be alien hellhounds. So Keith's gotta hurry up and get to him in order to help him. So Keith does end up piloting the black lion right at the get-go, but it's very briefly. After being hinted at all season, during Season 1, it is officially revealed that Zarkon was the original paladin for the black lion, and apparently his connection with the black lion is so strong that if he gets close to the black lion, he can control it. So Voltron has to keep his distance from Zarkon until Shiro can develop an even stronger connection with the lion. It is also revealed that King Alphor was the original paladin of the red lion as well. It's also revealed that King Alphor built the black lion on what I can only assume would be planet Doom. It's destroyed now, but it was Zarkon's home planet, which I believe in the original series was Planet Doom. I can't remember what it is now. There is a Galra resistance against Zarkon, basically rebel Galras, which is the species that Zarkon is. They don't want to be ruled by Zarkon. They want to be, you know, they want to be a part of this new galactic alliance that Princess Allura and the Voltron Paladin, sorry, are forming. And they do actually start forming the galactic alliance as portrayed in the original few series. It is just a start, it's more of a resistance movement, but they are forming this alliance with all these other planets. These rebel Galras actually have people inside Zarkon's forces working against him in high ranking positions too. It's also shown that Voltron's sword can increase in size as shown where Voltron has to cut through an entire massive ship, Galra ship. And in order to do that, it has to increase in size in order to get it all in one swipe. So it goes from being like this, you know, to being about twice the length of Voltron. As I told you guys before, Zarkon has this incredibly strong connection with the Black Lion. So much so that he is able to track down the Voltron Paladins and Princess Allura and the castle and everything by mental, psychically, by the psychic link between him and the Black Lion. It was briefly shown in season one that the alliance can evolve, but it was more so shown in this season. The Black Lion is capable of so much more power. It gets, when he and Shiro are able to bond, create a super strong bond, you know what? In the original series that one little computer thing came up and, you know, Keith did the activate interlocks and, you know, did the switches and everything. Well, that thing comes up and he does the same thing, but he doesn't do the whole activate interlocks, dinotherms connected thing. He just, you know, immediately turns it on and everything. Power boost, the Black Lion gets these enhanced wings that almost look like mechanical feathers coming off of it. And when they do that during, when it forms Voltron, they actually are able to create a version of the blazing sword. Before we've only ever seen the sword itself, not blazing power or anything like that. Once all five lines or once all five paladins are able to create superior bond with their lines, they're able to form the actual blazing version of the sword and end up destroying Zarkon. It's left unclear if Zarkon actually gets destroyed at the end or if he is just severely injured and left in a comatose. I'm not sure that part wasn't really specific. Shiro did tell Keith that if anything happens to him, he wants Keith to lead the team, which Keith takes very reluctantly. It's also revealed, it was kind of hinted at in season one, but Shiro and Keith aren't actually brothers. Keith was an orphan and I guess he was kind of adopted by Shiro's family or whatever, but apparently Keith is part Galra on his mother's side. It's not really specified how much Galra blood he has in him. I know in Voltron Force, it was revealed that he was the same species as Allura, but in this version, he's part Galra, which is the same species as Zarkon. His father was human. His mother, it's not really specific on how much Galra blood she had in her if she was just half Galra, full Galra, whatever, but this really creates a, it upsets the dynamic between Allura and Keith because Allura is so prejudiced against all Galras because they wiped out her race. So it really creates this tension in the group. Before that's revealed though, it's kind of hinted at that Allura is actually in love with Keith. Keith kind of feels the same about her, but it's only hinted at. It's not really bluntly stated, you know. Towards the end of the season, towards the end of the season, it's revealed that Zarkon has this armor. It makes him about the size of Voltron, and the Voltron paladins have an extremely hard time fighting him. He gets super powered by Hagar and her druids, and then while he's fighting the Voltron paladins, then Hagar and her druids are creating this super powerful blast to destroy the castle of lions. So it's very, it's kind of an epic battle. Almost a little bit more epic than Fleet of Doom. It's also revealed. Hagar's not Galra. It's actually revealed that Hagar's an Altaian, which is the same species as Allura and Koran. It's not exactly specified why she turned against her own race or whatever, but Allura does eventually defeat Hagar hand-to-hand, causes her to retreat, and at the end of the season, Shiro goes missing, which strongly hints that Keith will take up the position of the leader of the Voltron paladins and the Black Lion. How they're gonna work that is, I'm not really sure about considering the lions have to bond with their paladins. So they didn't really quite make that clear. And since all five members of the Voltron Force, or excuse me, I keep saying Voltron Force because that's what they've been called up until the Legendary Defender series, all five members of the, or all five paladins have bonded completely with their lion. I'm not really sure how they're gonna be able, how they're gonna switch lions up like that. In the original series, and all the way up until up through Voltron Force. Keith was the Black Lion, Sven was the original pilot of the Blue Lion, and then it became Princess Allura. Lance was the pilot of the Red Lion, and then Hunk, Yellow Lion, and Pitch, Green Lion. Well, they kind of changed that up this time, made Shira, which was actually Sven. They just kind of changed his name to more fit the Go Lion version. They made Shira the pilot of the Black Lion, Keith the pilot of the Red Lion, Lance the pilot of the Blue Lion, and then Hunk and Pitch kept their lions. I'm not really sure how they're gonna work that. I was, there were a few scenes in the series towards the end that made me think that, it actually gave me a little bit of hope that they were gonna go the route of the first three series, Voltron Defender of the Universe, third dimension, and Voltron Force, where you know it does the activate interlock, dyno therms connected, intracells up, megatrossers are go, and form feet and legs, form arms and torso, and all form the head. It really kind of hinted that they were gonna do that at some point during the series, but they don't, which is a little upsetting because I really miss, that's one of the things that made Voltron iconic was the music and the dynamic, the whole sequence they go through before when they form Voltron. It's very memorable, it sticks in mind. Now it just, let's form Voltron, and then they all combine together, and I don't know if I like that too much. I understand why they did it because they need to be able to do it faster, but they could have done it in a similar way that they did with Voltron Force. Overall, I like the season two. I like the series on a whole. I just wish they would incorporate more elements of the original series. I wish they would turn the Blazing Sword back into the original version of the Blazing Sword because that's an iconic looking sword. I really wish they'd go back to the, Voltron formation sequence that they used to do, and bring back the music. Everything else, I don't mind too much. I don't mind that the Paladins of the Lions are switched around and everything. Just a few of those nitpicks that as a fan from way back in the 80s, I grew up with Voltron, I wanna be able to see stuff that I recognize. And this new version of Voltron, they took away the original chest plate and the Voltron cross, which I understand why they took away the cross. I don't wanna offend anybody or whatever, but that was still kind of an iconic look for Voltron. And they turned the chest plate blue instead of the original red and the multicolors or whatever on the emblem. They could have changed up the chest emblem a little bit and kept the entire red chest part though. So I'm not really quite sure why they turned it into a blue V. Like I said, overall, I liked it. I hope you guys enjoy it. The toys are out at Walmart and Target now. I got the legendary black lion and I got my son the small six inch black lion action figure as well. Here soon we'll probably be getting the other lions so that I can form Voltron. But yeah, that was my season two Voltron legendary defender review. I will try and do a review on this every season. And hopefully we'll get a little bit better with the Voltron legendary defender. The only thing I don't like is that they only release it once a year. They release an entire season at the beginning of the year. So you've gotta wait all year long catch the next season. So that's the only thing I, that's one of the things I don't really like about the way Netflix does their shows. I wish I'd kind of do it like they released the first part of a season and then like six months later, they released the second part of the season. And then that way every six months, at least we'd be able to get 10 to 13 episodes to be able to watch. Instead we get 10 episodes, then have to wait a year to be able to watch 10 or 13 more episodes. I'll rank it about an eight out of 10. As a Voltron fan, I liked it. I have some Netflix but they're minor.  There was one thing I forgot to mention guys at the very last scene of the season of the show, Hagar reveals that in this Voltron universe, Prince Lothor does exist. When after Shiro is missing, Hagar goes to the body of Zarkon. It's not really revealed if he, like I said before, it's not really revealed if he's dead or if he's just a coma or severely injured or whatever. But she orders her troops to summon Prince Lothor. So that's gonna be pretty cool. I'd like this, I really wanna see how they do Lothor next season. Lothor has been kind of the constant throughout all of the different incarnations of Voltron. Voltron, the defender of the universe, the main villains were Zarkon and Lothor with a few generals or sub commanders or whatever. And then in Voltron, the third dimension, Lothor was the main baddie. Same with Voltron Force, he was the main baddie. Voltron Fleet of Doom, which had both the Lion Force Voltron and the Vehicle Force Voltron. Zarkon was the main villain, I believe. It's been a while since I've watched it. But Lothor ended up being the main villain. He kind of turned on his father and teamed up with the two Voltron forces and specifically Alura to help him. And then he kind of turned on them towards the end off to go back and re-watch it. But so that's gonna be pretty cool. I'd like this, I really wanna see how they do Lothor next season. Hit that subscribe button. Make sure you hit the like, comment below and share with your friends.


Let me share with you a method that can help you to get more new clients. So first I want you to imagine, think about a friend of yours, somebody that you genuinely like, that you respect, and that they have a business, okay? Have you got someone in mind? Now imagine that they asked for your help in getting some more clients. And they make it easier for you to, for example, think of some people that might be a good fit for them. They need to give you a message to send onward. They describe who it is that would be the best fit for them. And then you take half an hour to look through your network to see who might I send this message to. Would you help a friend who you like, you trust, you respect, who asked you for that kind of help? Probably. So why is it that we don't do this more often? So I'm going to share with you something called the barn raising method for getting new clients. So let me first explain what barn raising is. This is a method of, it's a community action that I think was popularized maybe in the 19th century in America. I think it's still used in some rural communities today. And essentially it's when a member of a community needs to build a barn because the weather is going to change and they need to build the barn quickly, they would rally their community to help build their barn. And why would the community do this? Well, especially in more rural communities or more tight-knit communities, people know each other and they trust each other, they like each other. Just like I said earlier, if a friend you liked and trusted asked you for help, wouldn't you help? Of course you would. So same thing in these communities is that person who needs the barn to be built would ask their community for help. They would set a date and then they would all come and build the barn together. And in fact, I found a cute little time lapse video that I want to show you. So it looks something like this. This is the time lapse of a barn being built. But look at this. Look at all these people working together to make this thing happen. And that's the point. That's the point of a barn-raising project is you all get together and do it together. And let's see here what happens. Continue on. See, the whole thing is coming together. And the reason why the community does this, why other people are volunteering their time to help build this barn, these are not paid workers. Okay, these are community volunteers. It's because the community members know that when they need help, this person that they've helped to build the barn of course is going to be very grateful and say, what do you need help with? And so everybody helps each other. That's what happens in a tight-knit community. And the reality is that you also have a tight-knit community of people who are willing to help you if you only reached out to ask for help. So the barn-raising strategy for getting new clients works like this. You either make a public post asking for this or you can privately reach out to 10, 15, 20 of your friends that trust you, like you, that you feel open to making this kind of vulnerable request. And the request, when I say it's vulnerable request, it all depends on how you phrase it. And I would really be open to hearing if you have any ideas for how you might phrase something like this or how you might frame this request. But let me share with you a very simple way that I thought of in a short time and please go ahead and let me know what you think about this. So let's say that you want to raise an additional, well now I said raise because it sounds like fundraising, right, barn raising sounds like fundraising. This is what people do all the time when it comes to fundraising for charities, fundraising for even medical, personal medical expenses. I mean, you've probably seen that too, right? It's gotten popular in the past 10 years to say, everyone, I have a major surgical procedure coming up or my friend does and they need help. Would you be willing to chip in $15, $20, $25 or whatever you can to help my friend with their medical or help me with the medical procedure, right? You've seen that. And so my question is why don't we do this for business? You know, if we think about our business, especially as I talk about authentic business, if we think about our business as a, you know, the only way our business can thrive, I mean, survive, let alone thrive is with community support. Isn't that true? I mean, who buys from you? It's usually, you know, for a business to get from zero to sustainable from that gap, from making nothing to being at somewhat sustainable, it's usually not strangers buying from the business. It's usually friends and family and colleagues or people who have been referred by friends, family and colleagues buying from the business, right? So it's for the business to even be survivable requires a community effort for it to work. And then once the business is sustainable to some degree, then there is more of a budget to run ads, to do, to spend, to invest more, to get the word out to more people, which now strangers are starting to, you know, see the business and to start to trust the business and therefore to buy from the business. But really the beginning, that beginning, you know, first stage is usually word of mouth with one's close knit community, which you already have. It's your friends, it's your family, it's your colleagues, it's the people that you've connected with in various courses you've taken, for example. So let me give you a, this is a template that I just came up with, you know, in a short time. And here's what I'm gonna ask you to do. You probably don't wanna just copy and paste what I wrote because then it's not authentic to you. And you know me, I always believe in using your, you know, exploring and finding your authentic voice to share. So I want you to first think about this before I show it to you, okay? Maybe pause this video before I share that with you and think, how would I make this request in my way? Maybe your style is to do it with more fun. Maybe your styles do it with more, I don't know, maybe gravitas or maybe your style is to do it with kind of a heart from a heart, very heart-based perspective. How would you make the request to say, dear community, I'd like to rally, I'd like to recruit you to kind of rally around my business to help it get to sustainable level. Now that's usually how barn raising is done. It's like, hey, we need to build a barn because the winter's coming or harvest is coming and we need the barn, but you could also use this technique to get additional, your next $1,000 a month in clients. Maybe you're already sustainable, maybe you're already making, I don't know, 5,000 a month or whatever and you wanna get to 6,000 a month or 7,000 a month or 10,000 a month and you could use the same method and come from it from a more inspirational, fun way. But the way I'm going to share the template with you is for somebody who's trying to get from zero to sustainable. So again, use my template just so that you can get the gist of the idea but then use your own way of doing it. Got it? Ready? Okay, don't copy, I mean, I'm not saying don't copy what I wrote because somehow it's copyrighted, I don't care. You can always copy anything I say, literally work forward, I don't care and call it your own. That doesn't matter to me. What matters to me is whether you're being authentic to your own community, to your own relationship with them. That's what matters. Okay, let me go and show this to you on the screen here. All right, so basically, if you wanted to raise $1,000 a month in income, it basically means you need to get four clients who are using your service four times a month who pay you $300 per month per client. Now I'm assuming, of course, it totally depends on what your per session rate is. But let's say your per session rate is $75 per session, which is a really reasonable rate for someone who is starting out in their business. Someone who's starting out might even charge less than that, might even charge $50 per session or even $25 per session and then raise their rates from there but whatever, $75 per session, let's say. And so if a client sees you four times a month, they're paying you $300 per month. So you just need four clients who are doing that $300 a month or earn you $1,200 a month. That's more than the 1,000 month. Or if you wanna have five clients who each pay you $200 a month to see you twice a month, right? Then basically $100 per session, which is also quite reasonable, then you just need five clients for that to reach $1,000 a month. Or if you're charging $125 per session, if for clients who only see you once a month, then you just need eight clients. So just think about this for a second. Don't you know more than eight people? Of course, you know more than eight people. You know hundreds of people on a first name basis. Now you're not close with all of them, but you're probably close with, I'm gonna guess you're close with like at least 20 people. 20 people, you're probably close enough with 20 people or 30 people who you feel comfortable asking for a barn raising help. Now, some of those 20 people might not be right to help you barn raise. Maybe they know somebody who would be willing to help you barn raise. Does that make sense? So you can see the numbers are quite doable. If you know 20 people and half of those 20 people referred you to three people each. They just took half an hour. Half an hour, I mean, they're a friend. They're a supportive friend, you're a family member, right? They just took half an hour to look at their contacts or look at their phone book or their LinkedIn contacts, their Facebook friends list or whatever and go, why are there three people that might be willing to sign up for my friend Susie's service or my friend Bob's service? So you see what I mean? So if 20 people, half of them or this is say 20 people referred you to two people each, then you have 40 people, potential clients. And you just need, like I showed you on the screen, you just need four of them paying you four times or paying you 300 a month or eight of them paying you 125 per month. Very doable in my opinion, I think. So here's the request. And like I said, you got to use your own language on this. This is just don't copy and paste if you want, but it's gonna be more authentic if you use your language. So basically something like this, dear friends, if you're willing to help support my business, read on, I'm setting a goal of raising, setting goal of raising $1,000 a monthly income in my business by serving more clients with the work that I love to do. Are you or someone you know, seeking help getting through the following challenges? Now that's one way of saying or you can say, hey, do you know anyone who would love to reach the following goals, right? Or do you know somebody who would love to experience the following experience, to have the following experience, okay? And then list out like one to three or five up to five, I think, of the top things you love working with people on. Now, if you don't know, just make a guess, right?  That's the question. So list that here. And then if you already have worked with some people, okay? And this is not something you put in the post, but something I'm speaking to you privately here. If you already know what type of clients are best for you, you know, or you know, which ones are not a good fit for you, like, oh my gosh, I've worked with these types of people, they're really not the right fit. They're not ready to work with me or, you know, whatever reason. Then you can also clarify that here in this section of the message. Like, by the way, my ideal clients are at this stage development or they are this type of person or I really don't work well with clients who are this type, but I do work with clients who are this type, you know, kind of clarify that. And then you continue on with your letter, okay, with your post. To reach the goal of $1,000 additional income means having the following and then list your packages in a simple way. Just, you could even literally use what I wrote here, right? You could say this, right? You could put that in your copy and paste that in here if you want to. And then continuing finishing your letter, you could say, for those interested in exploring whether it's a good fit to work with me, I would be happy to offer a free exploratory session, one hour. Now, one hour is a generous amount of time. Some people even go longer, but you could say half an hour if you've done a lot of these before and you feel like you're pretty good at doing them. But I think one hour is a reasonable amount of time to just have a spacious conversation to ask that person questions, to get to know them better, to really show caring at once. And that's really key. I wanna look you in the eyes. Exploratory calls are not where you have a script and you go, okay, I better move this person through this motion and then that idea so that they can buy from me. That's a terrible, terrible exploratory call.  Whether or not they buy from you, that's the important point. Whether or not they buy from you, they are a human being who has given the time to talk with you about their issues and their goals and their dreams or whatever they want. They've given their time and their vulnerability to talk with you. They deserve your care and warmth even that they never buy from you. And even if they never refer a single person, even if they never talk to that person ever again, they still deserve your warmth and your care, don't they? Of course they do, of course they do, right? And I'm sure you would agree with me. Okay, but the irony is if you show up with warmth and care without thinking about the sale, they're much more likely to want to continue being connected to you. And by the end of the call, you might feel like, wow, their needs and their wants are really the thing I love to do with people and at that point, your enthusiasm will genuinely bubble up and say, my goodness, I would be honored, grateful to have you as a client because this is the kind of thing that I love doing with clients. Would you be willing to, can I answer any questions about how I work with clients? That's all you gotta say, right? That's all you gotta say, rewind this. Listen to that again, okay? All right, so let's continue on with the letter here. So one hour to get to know your needs and for you to better understand whether and how I can help no strings attached genuinely other than my gratitude for at least trying, at least trying this experience out, right? The exploration will help you better understand my service and even if you don't sign up, it will equip you to be a better advocate for my services for which I'm really grateful. Again, this is being sent to the people that like you, that trust you, that you feel okay about being vulnerable and saying, hey, would you help me barn raise to build a barn to get me the next thousand, next several clients, basically. Now this part of the letter you can leave out if you want to or you can make this part of the entire letter, okay? So the alternate goal is, I would love to schedule 15 exploratory calls between these dates and give some dates. Oh, from November 1st until December 15th, whatever, okay? With anyone who resonates with what I wrote above, now you would obviously, if you wrote a letter talking about exploratory calls, you would include some of these things so people know who you're trying to reach out to, right? Would you like to take one of these exploratory sessions or maybe refer someone to it? If so, comment yes below. Now I'm assuming that you're posting this on Facebook or whatever and I'll be in touch to schedule it. If you're doing as a private message, then just say, hey, if so, let me know and I'll be in touch, okay? So my question is, how do you feel about the strategy, okay? How would you feel if a friend posted this? Like I said, think about someone you would like. Now, a common concern is some people might say, George, doesn't this lower my professional credibility when I'm asking my network for help to get clients? Doesn't this make people somehow make me seem desperate or not successful and people only want to work with people who are successful, right? Well, let's think this through here. Let me ask you this question.  Are you, is that the service you're selling?  I know how to help people market their business. If that's the case, then this strategy won't work for you, I'm sorry. I mean, it still could. If you're willing to be vulnerable to certain people, they probably could help you out. But this strategy works for most of you who are watching this, who don't build yourself, who don't promote yourself as a marketing expert, who don't promote yourself as, I'm good at helping people get clients. That's not what you're selling. You're selling your healing service. You're selling your coaching, life coaching service.  Like ironically, I have a hard time using this strategy because people say, George, aren't you supposed to be good at helping people get clients? I can't be, you can't get your own clients. I would agree if you, right? But the funny thing is I exactly did this years ago when I started my business. So, hey folks, I have started my social media marketing, consulting company business, and I would love your help getting the word out about this. I did this in the beginning of it and I got my first couple of inquiries clients from doing this. So I have a thick skin, I guess, and I didn't mind telling people. And guess what? Everyone, now, hopefully, I think people see me as respectable, credible. I have, now I have a waiting list, I've had a waiting list of clients for five years now. Five years straight, I've had a waiting list of clients. So my business has developed to a very mature stage, but in the beginning, I did this exact thing. Even as a marketing expert, in the beginning, I'm a marketing expert, but I need your help. That means people know I'm a marketing expert. I did that, right? Anyway, so I'm just saying, especially you're not a marketing expert, you can certainly tell your network, hey folks, I'm not a marketing person. I'm not good at marketing. I'm good at healing. I'm good at my coaching. I'm good at whatever it is thing I do, but I'm not good at marketing. So can you all help me out, dear friends? You see what I mean? So the last thing I'll say is that if you feel shy about doing this, you don't have to post it on Facebook. Now, for those of you who are actually interested in posting this as a public post on Facebook or on LinkedIn or Instagram or Twitter or whatever, if you're interested in making a public post about this, I would love to see it. And if you go ahead or make a YouTube video, public YouTube video about this, I would love to see it and go ahead and comment below with the link to your post. If you don't want to get the link to your post, look it up. You can get a link to any social media posts. On Facebook, you click on the timestamp.  That page is what you can paste below as long as it's a public post. Everyone can see it who's not your friend. They can see it for the link below. I'd love to see you do this. If you want to do it in your own language. If you're shy though about doing it publicly, you can just ask five, 10, 15, 20 of the friends who like you, who trust you that you trust, that you really trust them to get help from. So email or privately message some friends, hey, would you be willing to help me out on this barn raising idea? And if you are willing, let me know. And maybe you can create a secret little Facebook group or secret Google group to keep in touch about this project so that you can update them along the way on how it's going as you make your way towards $1,000, $5,000, $10,000 a month in income. So again, keep the idea really simple. It's basically to inspire and to recruit some supportive friends, whether it's a public post or private messages to come to your help, to help you with your business, just like you would help somebody else that you like and trust with their business, wouldn't you? Of course you would. So I'm really curious to know what you think about this. If you have any suggestions as well to make this idea work for you even better or maybe work for others, feel free to comment below. Or any questions, quick questions, I'm happy to answer briefly as well. All right, go for it, let me know what you think and may this help you to get your next $1,000 a month in income or more. Take care.


Hey everybody Lance Coyke here today. We're discussing kind of like the cousin of the flexed arm hang that we went over yesterday This is where I jump on up and then I lower down halfway. That's the flexed arm hang today What I want to discuss is holding yourself at the top of the movement So I mentioned in the previous video that we don't really You know, I don't really program this quite as much But when would I program it? Well, if you're having trouble getting yourself up into the right position at the top And I need you to sit there so you can kind of figure it out And so I can give you some cues and you can think about them, right? It gives you more time to fix what's going on. You can't just always expect to just keep bumping out reps and then all of a sudden you're gonna be able to figure out what is going on Sometimes it happens, but not very often. Okay? So I jump on up and I hold myself up here at the top generally now if I'm messing up at the top I filmed a whole video about messing up at the top, but if I'm messing up spoiler alert I'm kind of like crunching over and bringing my shoulders forward and I don't want that, right? I'm shutting off the muscles that are in my upper back Which I need to stabilize my shoulders throughout this entire movement So instead if I'm holding there at the top what I need to try to do is pull my shoulder blades back closer together So they can feel more of that upper back stuff and that if I'm really having trouble with that This holding at the top is a great isometric exercise for you to try