| cpaelzer | good morning | 05:10 |
|---|---|---|
| lordievader | Good morning | 06:06 |
| === ejat_ is now known as ejat | ||
| Checkmate | Hello is possible to resize root path / | 10:15 |
| RoyK | Checkmate: yes | 10:24 |
| RoyK | Checkmate: it might be easy, it might be hard, depending on your setup ;) | 10:24 |
| Checkmate | Royk teach me the way please | 10:25 |
| RoyK | Checkmate: please detail your setup - what you want (bigger or smaller filesystem? what sort of filesystem? partitions or lvm? etc) | 10:26 |
| Checkmate | Royk pastebin.com/raw/UczkUVuY | 10:28 |
| Checkmate | i have 2Tb on /home/ i want to add 60gb to /dev/root | 10:28 |
| Checkmate | Royk is Linux rev 1.0 ext4 filesystem | 10:30 |
| Checkmate | I try this resize2fs /dev/sda3 60G | 10:39 |
| Checkmate | The containing partition (or device) is only 5119744 (4k) blocks. | 10:39 |
| waveform | Checkmate, you need to expand the partition containing the file-system before you can expand the file-system. However, assuming /dev/sda4 comes immediately after /dev/sda3 (which is presumably /dev/root) you first need to *move* /dev/sda4. This is the pain of using partitions instead of LVM | 10:40 |
| waveform | unfortunately that's non-trivial - assuming you've got physical access to the box, you're probably best off booting from some live disk (e.g. an Ubuntu installer) and using gparted to do all this for you | 10:41 |
| Checkmate | waveform you mean i need to swap i'm on vps i dont know how to expand /dev/sda4 | 10:45 |
| RoyK | better reinstall on lvm, add as much as *needed* to each partition. Also, is the 2TB on /home on another disk? | 10:47 |
| waveform | ah, vps - so no physical access and the disks are probably just files anyway | 10:47 |
| Checkmate | Royk is only on /home but i don't know how i can resize on vps | 10:48 |
| waveform | in that case just expand /dev/sda3 through whatever interface your vps provides for configuring storage on the instance (assuming it provides such an option), reboot and retry your resize2fs command (you can leave off the size - if omitted, resize2fs just expands the file-system to the size of the container/partition) | 10:48 |
| RoyK | Checkmate: the provider can probably help | 10:48 |
| Checkmate | waveform i can expand /dev/sda3 to /dev/sda4 ? | 10:49 |
| waveform | Checkmate, no: you just need to expand /dev/sda3. Because you're on a VPS, /dev/sda3 is probably just a big file on some server pretending it's a partition on your VPS' disk. Your provider will (hopefully) have some interface you can use to request/give more space to /dev/sda3 | 10:51 |
| Checkmate | please i dont know what command using to expand | 10:51 |
| waveform | we can't tell you that: it won't be something on the server itself; it'll be something in your vps' control panel (i.e. on the website you used to set up the vps) | 10:52 |
| waveform | hence, it'll also be specific to the vps provider | 10:52 |
| Checkmate | ok looks i need to contact ovh support | 10:53 |
| Checkmate | waveform if i'm on the rescue mode | 11:28 |
| Checkmate | i can adjust size safely? | 11:28 |
| waveform | expanding a file-system can generally be done online (sometimes, depending on file-system, even when it's mounted) but you need to have expanded the container of the file-system first | 11:33 |
| waveform | I think I'm right in saying ext4 is one FS which permits online expansion; in other words, if you've expanded your /dev/sda3 (through your vps) you should be able to resize2fs it with or without booting to rescue mode | 11:34 |
| Checkmate | can you please give me the commands to expanded /dev/sda3 | 11:37 |
| TJ- | waveform: correct, I use that regularly with LVs that grow. "resize2fs /dev/sdXY" | 11:38 |
| waveform | Checkmate, if you've resized the /dev/sda3 "partition" (in quotes because this is on a vps so it's probably not *really* a partition), just "resize /dev/sda3" and it'll expand to the size of the new container | 11:39 |
| waveform | TJ-, yeah - I was sure I'd done that on my LVs at some point but it's one of those things I haven't needed for a year or so and I have to re-check each time :) | 11:39 |
| Checkmate | waveform give me the command i want to try if i can resize or not | 11:41 |
| TJ- | Checkmate: I just gave it | 11:41 |
| TJ- | Checkmate: "resize2fs /dev/sdXY" | 11:42 |
| Checkmate | you mean resize2fs /dev/sda3 200G | 11:42 |
| Checkmate | why when i check df -h i see the same size nothing changed!! | 11:43 |
| waveform | as mentioned: you *don't* need to specify the size. Just "resize2fs /dev/sda3" and it'll expand to the size of the container (*if* the container has been expanded) | 11:43 |
| Checkmate | when i do this command giving me result The containing partition (or device) is only 5119744 (4k) blocks. | 11:43 |
| waveform | simple - it means you haven't expanded the container | 11:44 |
| Checkmate | waveform can i expanded it my self or only by the provider? | 11:45 |
| waveform | depends on the provider - some (most? in my experience) provide some means to do this through their interface/website - but for a few it is "contact support" | 11:45 |
| Checkmate | waveform possible by rescue | 11:46 |
| Checkmate | do you have the command i should give it a try then if doesn't work i will contact the support | 11:47 |
| waveform | Checkmate, as you're on a vps this is *not* something you're going to be doing from within the Ubuntu command line - this'll be something on your provider's site | 11:47 |
| Checkmate | waveform its not by the command line? | 11:52 |
| waveform | no | 11:52 |
| waveform | not typically on a vps | 11:52 |
| === devil is now known as Guest20311 | ||
| === nacc_ is now known as nacc | ||
| === Guest20311 is now known as devil__ | ||
| JediMaster | hey guys, we're preparing for Bionic/18.04, getting a bunch of test servers up and running, and I'm sure that I saw PHP 7.1 support, as well as 7.2, for Bionic, yet I can't find any 7.1 packages now, does anyone know if PHP 7.1 has been ditched from Bionic? | 16:29 |
| JediMaster | https://launchpad.net/ubuntu/bionic/+source/php7.1 says "There is no current release of this source package in The Bionic Beaver." | 16:29 |
| JediMaster | yet the source package exists | 16:29 |
| nacc | JediMaster: yes, we are on 7.2 only | 16:30 |
| nacc | JediMaster: php7.1 exist in Artful | 16:30 |
| JediMaster | nacc: thought so | 16:30 |
| nacc | JediMaster: it does not exist in bionic | 16:30 |
| JediMaster | The problem is that PHP 7.2 no longer has the 'php-mcrypt' module as it lost support something like 7 years ago, and there are a lot of major PHP based applications that rely on it | 16:30 |
| nacc | JediMaster: right, there's a pecl repository | 16:31 |
| nacc | JediMaster: or move the php applicaiton to openssl like it should have 5 years ago | 16:31 |
| nacc | most upstreams have at least started that | 16:31 |
| JediMaster | Ah, I didn't know that, so you could in theory install mcrypt through pecl then | 16:31 |
| nacc | JediMaster: yes, i believe so | 16:32 |
| JediMaster | nacc, unfortunately we host Magento sites, and Magento only started work on 7.2 support at the start of the year, so there's no chance it'll be ready for 18.04's release, or likely until the end of the year | 16:32 |
| nacc | JediMaster: right, i've heard this issue for magento | 16:33 |
| JediMaster | It'd be great to move people over to the latest LTS release, but I think that composer requirements on the latest (even beta) Magento support 7.1 at best | 16:33 |
| nacc | which... isnot in ubuntu :) | 16:33 |
| nacc | yeah, they seemed to be a bit behind the curve on this one | 16:34 |
| JediMaster | Yeah, I know it's not an ubuntu issue =) | 16:34 |
| dpb1 | JediMaster: good thing 16.04 has many years left. | 16:34 |
| dpb1 | :) | 16:34 |
| JediMaster | dpb1, yeah but, not as shiny new as 18.04! | 16:34 |
| JediMaster | bleeding edge all the way | 16:34 |
| dpb1 | there there 16.04, he didn't mean it. | 16:35 |
| dpb1 | JediMaster: I'm with you | 16:35 |
| dpb1 | :) | 16:35 |
| JediMaster | That's why I drive beta cars (aka Electric) | 16:35 |
| nacc | JediMaster: you also could run 18.04, and 16.04 in a vm or container | 16:35 |
| JediMaster | nacc, it's already virtualised, that'd be a bit horrid nesting it ;-) | 16:36 |
| dpb1 | lxd | 16:36 |
| nacc | JediMaster: :) | 16:36 |
| JediMaster | dpb1, I've not come across lxd, just reading up on it | 16:37 |
| dpb1 | JediMaster: for pure application workloads (like php) it's fantastic | 16:39 |
| sdeziel | JediMaster: you could have 16.04 containers with PHP-FPM (7.0) serving the dynamic stuff and have the shiny new web frontend of your choice that comes with 18.04 | 16:43 |
| sdeziel | you could probably also have your DB backend running on 18.04 | 16:44 |
| JediMaster | it's easy enough on our multi-server setups where we have a load balancer (nginx serving static content directly and load balancing php), multiple PHP-FPM servers (no web server) and a database server, as we'd just make the PHP-FPM servers 16.04 and the rest 18.04 | 16:46 |
| JediMaster | but on a standalone machine it sounds like quite a lot of hassle having a container just to run PHP-FPM | 16:47 |
| nacc | JediMaster: only because you are trying to use a version of an extension not supported | 16:47 |
| nacc | that's the hassle-source, focus on that :) | 16:48 |
| nacc | if you are going to use old software, setup a reproducible deployment enviornment for it | 16:48 |
| JediMaster | also the application (which we can't realistically re-write) doesn't officially support 7.2, but does 7.1 | 16:48 |
| nacc | JediMaster: yeah | 16:48 |
| nacc | JediMaster: that's why i'm saying it doesn't makes sense to move the underlying OS for htat application | 16:49 |
| nacc | JediMaster: i believe magento also supports 7.0, and just run magento in the container | 16:49 |
| nacc | which can run in any VM/host | 16:49 |
| JediMaster | Yeah, it's another 3 years support on 16.04 now isn't it? | 16:49 |
| nacc | JediMaster: yep | 16:49 |
| nacc | JediMaster: hopefully by then magneto gets its act together :) | 16:49 |
| nacc | JediMaster: note that debian is putting the smae pressure on them, as their next release will also be 7.2 only, iirc | 16:50 |
| JediMaster | Yeah, I think that's the same conclusion we've come up with | 16:50 |
| JediMaster | Good to know, I suspect we can move people to 18.04 in maybe 6 months, but meh | 16:50 |
| nacc | JediMaster: it's not ideal, but it's also waht upstream PHP has decided | 16:50 |
| nacc | JediMaster: there's always a chance we'll get enough outcry that we'd package mcrypt ourselves, but I've been trying to avoid it | 16:51 |
| nacc | as I don't think we can really support it (so it'd be in universe) and it's not great for that package to not get security updates | 16:51 |
| JediMaster | indeed | 16:51 |
| JediMaster | nacc, thanks for the help, always nice to talk to the Canonical peeps | 16:57 |
| nacc | JediMaster: np :) | 16:57 |
| teward | dpb1: were you hunting me for something? | 17:24 |
| teward | I've been insanely busy the past few weeks, if so | 17:24 |
| nacc | teward: nginx merge, most likely | 17:25 |
| nacc | which we just landed (in bionic-proposed) | 17:25 |
| teward | nacc: right, i saw that. | 17:25 |
| teward | thanks by the way :) | 17:25 |
| nacc | teward: np | 17:25 |
| teward | (FYI: I'm autosubbed to app the nginx bugs, no need to specifically subscribe me to the merge requests, FFes, etc. | 17:25 |
| teward | I saw you added me to a specific one, but i'm subbed to them all automatically) | 17:26 |
| teward | nacc: any major evils in the merge process? | 17:26 |
| teward | out of curiosity :0 | 17:27 |
| teward | :) * | 17:27 |
| nacc | teward: just some dropped noise | 17:28 |
| nacc | teward: nothing otherwise noticed | 17:29 |
| teward | cool. glad to hear that :) | 17:37 |
| shubjero | Anyone here using Ubuntu cloud images? I'm using OpenStack to deploy a large VM with Ubuntu 16.04 EFI/GPT cloud image but the root disk doesnt get deployed any bigger than 2TB despite the partition scheme being GPT. Any thoughts? | 17:55 |
| sarnold | what's the backing store? | 17:56 |
| shubjero | The underlying virtual block device 'lsblk' is showing up as 5.3T | 17:56 |
| shubjero | qcow2 | 17:56 |
| shubjero | image: disk | 17:57 |
| shubjero | file format: qcow2 | 17:57 |
| shubjero | virtual size: 5.3T (5798205849600 bytes) | 17:57 |
| shubjero | I have the ability to add a second partition that consumes the rest of the free space on the block device but that's not how I want this to work. | 17:57 |
| tomreyn | i know that xen has a bug in some versions restricting it to this size, but i guess you'll be using kvm? | 18:05 |
| tomreyn | shubjero: ^ | 18:05 |
| shubjero | Yeah, KVM | 18:09 |
| === hosified_ is now known as hosified | ||
| dpb1 | teward: we got enough context and proxying from rbasak, nacc and others to confirm that it's what you would have wanted. | 18:11 |
| dpb1 | teward: thanks for confirming. :) | 18:12 |
| teward | dpb1: yep. I had asked the SErver Team to help out :) | 18:15 |
| teward | dpb1: given the fact that the weeks up to yesterday were chaotic prepping for basially a "tear it all down and rebuild" for the corporate network here at work | 18:16 |
| teward | instead of switch level routing for VLANs, the firewall now does the routing, so the ACLs we had in place now actually work! :D | 18:16 |
| teward | since that's all done i can relax a bit now heh | 18:16 |
| dpb1 | teward: sounds fun actually. :) | 18:17 |
| teward | dpb1: well, doing the overhaul was. Cleaning up the fires afterwards, not as much. | 18:42 |
| teward | but yeah, nacc and the rest of the Server team did a very good job with the merge, so +1 to them for helping me out :) | 18:42 |
| dpb1 | teward: haha, yes. the fun ends when you have to support it | 18:42 |
| teward | well, considering the *state* of the network before we did this | 18:43 |
| teward | it was already at an unsupportable cluster**** of a network so we fixed that to make it *less* of one :P | 18:43 |
| teward | still got a complete nuke-and-redo on the radar but :p | 18:43 |
| teward | that's a longer term plan :P | 18:43 |
| teward | dpb1: I will say this though: | 18:44 |
| teward | merges are easier than having to introduce *new* binary packages for a MIR :p | 18:44 |
| * teward shivers when he remembers the MIR of nginx back in the 14.04/14.10 era | 18:44 | |
| sarnold | teward: they're not all that bad :) | 18:45 |
| apb1963 | Is there a reason why /bin/false is not in /etc/shells? | 18:45 |
| teward | apb1963: `/bin/false` isn't a shell? | 18:45 |
| dpb1 | man | 18:45 |
| teward | probably, anyways. | 18:45 |
| dpb1 | that would be an awesome shell | 18:45 |
| dpb1 | I think actually in the old days it was used in /etc/passwd | 18:45 |
| teward | apb1963: `/bin/false` can be *used* as a shell assignment to prohibit logins but it's not a shell in and of itself | 18:46 |
| dpb1 | maybe still? | 18:46 |
| teward | dpb1: still is for some system users. | 18:46 |
| sarnold | apb1963: heh, tough choice .. ask the service to knock someone out *before* executing false? or trust false hasn't been boogered up? | 18:46 |
| teward | or at least a few in a custom installation system. | 18:46 |
| dpb1 | yes | 18:46 |
| * teward still uses it to deny certain system accounts from logging in :P | 18:46 | |
| dpb1 | you are right | 18:46 |
| dpb1 | apb1963: anyway, what's your question behind that one | 18:46 |
| teward | sarnold: with the help from infinity and the rest of the teams, the nginx MIR was pretty painless. Can't say that for every MIR or package introduction though. | 18:47 |
| apb1963 | well, I only ask because https://help.ubuntu.com/lts/serverguide/ftp-server.html recommends adding it... although they call it "nologin".. but same idea | 18:47 |
| apb1963 | so, I think that's got to be a bad idea. | 18:47 |
| sarnold | teward: yeah, nginx was around the middle-point I think. pcp took a *lot* more time and effort from a lot more people .. thunderbolt-tools (which I did last week) was really just a few hours of reading and done. | 18:47 |
| teward | apb1963: well, /usr/sbin/nologin is *not* /bin/false, but... | 18:48 |
| teward | I think the answer is "Use your judgement" | 18:48 |
| apb1963 | that's not really an answer... was hoping for something more definitive. | 18:48 |
| teward | sarnold: well most of the evils of the NGINX MIR were the third-party utilities/plugins | 18:48 |
| teward | apb1963: i'm balancing multiple things patience is a virtue | 18:49 |
| apb1963 | ok | 18:49 |
| teward | I think i'm going to ask you a more pointed question though | 18:49 |
| teward | why the heck do you need to set up an FTP server | 18:49 |
| sarnold | hehe | 18:49 |
| teward | and what does SFTP *not* provide that needs you to resort to an FTP server? | 18:49 |
| teward | FTP is evil and is 99% a plaintext protocol that deserves to be incinerated | 18:49 |
| sarnold | if only sftp had an easier anonymous mode.. | 18:50 |
| apb1963 | SFTP? I thought ftps was the be-all and end-all of ftp security. | 18:50 |
| teward | *twitches* | 18:50 |
| teward | apb1963: SFTP is SSH tunneled, versus FTP with SSL. SFTP has some other mechanisms in it too. But you didn't answer my question ;) | 18:50 |
| teward | which was "Why do you need an *FTP* server" | 18:51 |
| apb1963 | Because wordpress in all its wisdom and glory, requires it. | 18:51 |
| teward | fun fact: tftpd + configuration + localhost only bind == sane | 18:51 |
| apb1963 | at least... to install plugins | 18:51 |
| teward | let me check what I do on my WP instances... *grabs his SSH keys* | 18:52 |
| sarnold | sftp is actually a well-specified protocol; directory listings can be machine parsed reliably. ftps relies upon a human to read the ls output and make sense of it. machine parsing that output is a best-effort kind of thing | 18:53 |
| sarnold | I don't know if ftps actually handles early termination well or if it requires proper tls termination.. | 18:53 |
| apb1963 | honestly, it doesn't matter to me which protocol... as long as wp finds it acceptable, I'm happy. The problem is that what I read about SFTP seemed more complex than ftps. | 18:54 |
| apb1963 | and I like simplicity | 18:54 |
| teward | apb1963: using it for WP is a no-go | 18:55 |
| apb1963 | Considering I'm going to set it up once and forget it, I'd rather not have to read War & Peace to figure it out. | 18:55 |
| apb1963 | teward, "it" being? | 18:55 |
| teward | SFTP | 18:55 |
| teward | FTPS is also evil and TBH Wordpress can access it locally without SSL | 18:55 |
| teward | my FTP for my WP systems only listens on localhost on a nonstandard port, and is pretty darn basic otherwise | 18:55 |
| apb1963 | well it wants an ftp login to proceed with installation of a plugin | 18:55 |
| apb1963 | so i'm just trying to make it happy | 18:56 |
| sarnold | ew | 18:57 |
| teward | well | 18:57 |
| teward | my `ftp` user has `/bin/false` for the FTP Daemon user | 18:57 |
| teward | but I don't add dedicated FTP users | 18:57 |
| dpb1 | teward: and /etc/shells? | 18:58 |
| dpb1 | on that same server | 18:58 |
| teward | dpb1: getting there hang on | 18:58 |
| teward | but keep in mind that *that* user's setting is irrelevant | 18:58 |
| apb1963 | I was thinking that the right way to go would be to change /bin/false to something in /etc/shells already | 18:58 |
| dpb1 | whatever user WP users, is what I'm asking, I think. | 18:58 |
| teward | because to edit a wordpress dir, FTP and the user logged into it *still* needs permissions | 18:58 |
| teward | dpb1: my WP uses my own user login locally | 18:58 |
| dpb1 | ah | 18:59 |
| teward | so it *can't* have anything but a legitimat eshell | 18:59 |
| teward | dpb1: this being said, my website roots all have custom ACLs to permit my user read/write outside of the www-data user and group | 18:59 |
| teward | but again, paranoid insane maniacal security guy here :) | 18:59 |
| teward | so ACLs are fun | 18:59 |
| dpb1 | apb1963: If you want a "non-interactive" user to use FTP, I'd go the other way | 18:59 |
| teward | ^ this | 18:59 |
| apb1963 | dpb1, what's the other way? | 19:00 |
| dpb1 | basically, follow the wiki guide | 19:00 |
| dpb1 | add /bin/false to /etc/shells | 19:00 |
| teward | dpb1: he'll still have to mess with permissions for the wordpress docroot | 19:00 |
| dpb1 | but keep your FTP listening on localhost only | 19:00 |
| teward | even with a noninteractive user | 19:00 |
| apb1963 | dpb1, And allow all the uid's with /bin/false as a shell, shell access? | 19:01 |
| dpb1 | apb1963: I don't think it would change anything for things other than ftp | 19:01 |
| dpb1 | try it | 19:01 |
| dpb1 | if you ssh into a server and the shell is /bin/false and that is added to /etc/shells | 19:01 |
| dpb1 | what happens? | 19:01 |
| apb1963 | It changes everything for any uid with /bin/false as a shell... presumably there's a reason why they're disallowed login. | 19:01 |
| teward | *tests something that dpb1 is talking about in a container* | 19:02 |
| dpb1 | irdk what the side effects are, other than vsftp caring | 19:02 |
| apb1963 | dpb1, See, I'm not a security expert... and when people tell me to do what seems to be the equivalent of chmod 777... yeah, that works.. but is it wise? | 19:02 |
| apb1963 | Right, I don't know the side effects either. And that's why I'm here... to get those answers. | 19:03 |
| teward | apb1963: adding /bin/false to /etc/shells won't let them login | 19:04 |
| teward | because it autokills the connection instantly | 19:04 |
| apb1963 | you tried it? | 19:04 |
| dpb1 | but that is just ssh | 19:05 |
| * sarnold sees a 777 and falls over | 19:05 | |
| dpb1 | I don't know what other side effects there are | 19:05 |
| apb1963 | Right... none of us appear to know | 19:05 |
| apb1963 | The fact that it autokills (sure, it executes /bin/false and done), doesn't mean a gaping security hole might have been opened up. We just don't know. | 19:06 |
| teward | https://paste.ubuntu.com/p/c3df2fxRFV/ shows the example | 19:06 |
| teward | apb1963: yes I did, in an LXD container running 16.04 inside it | 19:06 |
| teward | apb1963: well if the FTP server is listening only on localhost I don't think there's that much of an issue | 19:07 |
| teward | but I also can specify /bin/false *as* a shell ***without*** editing /etc/shells | 19:07 |
| sarnold | a decade ago I read a nice thing about .. openbsd? openwall? and their /bin/false and what they did to make it bulletproof.. | 19:07 |
| apb1963 | There you go. The fact that such an article even exists is proof of what I'm saying... it could be a security issue. We just, don't know. | 19:08 |
| teward | apb1963: I could make the argument that there is *still* holes inside any implementation of any controlsystem to restrict users | 19:08 |
| teward | keep that in mind that 'security' is never truly bulletproof | 19:09 |
| apb1963 | And, unless someone sees a reason I shouldn't give ftp a real shell... or, perhaps even a new wpftp user. | 19:09 |
| teward | anything you do is an accepted risk | 19:09 |
| dpb1 | apb1963: https://serverfault.com/questions/328395/nologin-in-etc-shells-is-dangerous-why - in the absence of any one else chiming up, here's what I'd do. copy /bin/false to /bin/false-ftp, and set the user you have designated for unattended access for WP to that. then add that to /etc/shells | 19:09 |
| teward | ^ that | 19:09 |
| teward | but consider that you don't *need* to put anything in /etc/shells to use it as a shell | 19:10 |
| teward | so for your FTP 'system' user you can manually force it to be anything not in /etc/shells | 19:10 |
| sarnold | well now I'm confused as hell http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/false/false.c?rev=1.1&content-type=text/x-cvsweb-markup | 19:11 |
| apb1963 | dpb1, yeah, that's along the lines of what I was thinking... but the /bin/false-ftp is a great idea. | 19:11 |
| teward | but consider if the FTP server only listens locally, you still need to *breach* the server to get to the FTP server to exploit. | 19:11 |
| apb1963 | teward, you lost me on the manual forcing. | 19:11 |
| apb1963 | teward, or more precisely.... the part about "not" in /etc/shells. | 19:12 |
| teward | apb1963: `usermod --shell /bin/false USERNAME` <-- forces the shell to be /bin/false or anything else I want it to be, regardless of what valid login shells are in `/etc/shells` | 19:12 |
| teward | again, writing up an example but LXD is slow | 19:12 |
| apb1963 | Yes | 19:12 |
| apb1963 | oh and thank you for that... I was searching for that command earlier | 19:12 |
| dpb1 | sarnold: haha | 19:14 |
| sarnold | dpb1: cute right? :) | 19:15 |
| teward | oooh i discovered an evil | 19:20 |
| teward | dpb1: for local allowed users, `/bin/false` and `/usr/sbin/nologin` both prevent FTP logins over FTP proto | 19:20 |
| teward | s/allowed users/users/ | 19:20 |
| dpb1 | what ftp are you using | 19:20 |
| teward | bog standard `ftp` on the command line | 19:20 |
| teward | and Filezilla | 19:20 |
| teward | with vsftpd server in a container | 19:20 |
| dpb1 | server, I mean | 19:20 |
| dpb1 | ah ok | 19:20 |
| teward | which coincidentally is what the server guide is saying to use :p | 19:21 |
| teward | only worked when I put a shell to the user, and that user is a bog-standard no-privs user | 19:21 |
| sarnold | for good reason, least bad option :) | 19:21 |
| dpb1 | teward: so, you tried /bin/false in /etc/shells ? | 19:21 |
| teward | dpb1: i'm testing everything standby :P | 19:21 |
| dpb1 | teward: also make sure you restart vsftpd | 19:21 |
| teward | dpb1: already did. twice ;) | 19:22 |
| dpb1 | heh | 19:22 |
| dpb1 | teward: I mean, ya, you are just trying out the instructions and they are not working. -> fail | 19:22 |
| teward | oh interesting. | 19:22 |
| teward | dpb1: OK so... | 19:24 |
| teward | /usr/sbin/nologin did not work, until it was in /etc/shells | 19:24 |
| teward | but this is with a local user purpose-created to be a 'service' user | 19:24 |
| teward | fails for /bin/false without it being in /etc/shells | 19:25 |
| teward | worked when added to /etc/shells | 19:25 |
| teward | not sure how my other system works though maybe because i'm logging into an interactive user. | 19:25 |
| dpb1 | ah | 19:25 |
| dpb1 | ok | 19:25 |
| teward | in either case, whatever shell you give the user has to be in /etc/shells either way | 19:25 |
| dpb1 | sounds fine then | 19:25 |
| teward | so whether it's /usr/sbin/nologin or /bin/false | 19:26 |
| teward | it still needs to be added to /etc/shells | 19:26 |
| dpb1 | good | 19:26 |
| teward | even if the user that you login to is a purpose-built user custom added to the system for a specific purpose | 19:27 |
| teward | (just don't give the user perms anywhere beyond its purpose heh) | 19:27 |
| apb1963 | I lnked /bin/false to /bin/false-vsftp and added /bin/false-vsftp to /etc/shells | 19:52 |
| apb1963 | Unfortunately, I can't yet test it since vsftpd fails to come up. | 19:53 |
| dpb1 | boo | 19:53 |
| apb1963 | Apr 09 12:43:08 yellow systemd[1]: vsftpd.service: Main process exited, code=exited, status=2/INVALI | 19:53 |
| apb1963 | "That's all we know" | 19:54 |
| teward | apb1963: run vsftpd directly as root and see what actual error it gives? | 19:55 |
| teward | systemd doesn't do a good job at showing errors for everything :P | 19:55 |
| apb1963 | 500 OOPS: missing value in config file for: /etc/letsencrypt/live/template.greetonix.com/fullchain.pem | 19:56 |
| teward | apb1963: my suggestion: don't set up FTPS, just set up FTP, set it to listen 'locally', and pass 127.0.0.1 and user creds to Wordpress | 19:56 |
| teward | since it doesn't initiate a connection from oyur computer to the server for FTP, it just does a local instance | 19:57 |
| teward | you don't need encrypted FTP for Wordpress to connect locally if it's not leaving the system for communication. | 19:57 |
| apb1963 | I suppose that's reasonable | 19:58 |
| teward | and by locally I mean add listen_address=127.0.0.1 to the vsftpd.conf config | 19:59 |
| teward | and then only use FTP from wordpress -> vsftpd | 20:00 |
| apb1963 | actually... after a bit more thought.. isn't wordpress connecting my site to the plugin site? | 20:00 |
| teward | FTPS is more needed if you're working with a remote filesystem, though, but local -> local is usually a "Why bother the estra step" | 20:00 |
| teward | apb1963: where does Wordpress actually sit? | 20:00 |
| teward | assume that it's on 1.2.3.4 | 20:00 |
| apb1963 | ok | 20:01 |
| teward | if I tell it to connect to localhost, the wordpress *via php on the server 1.2.3.4* is connecting to 127.0.0.1 - which is itself | 20:01 |
| apb1963 | no.. you're missing the point. The plugin is elsewhere. Call it 5.6.7.8 How does the file get from 5.6.7.8 to 1.2.3.4 ? | 20:02 |
| apb1963 | Is it over https? Or ftp(s)? Or maybe even something else. | 20:03 |
| teward | apb1963: how're you installing the plugin? | 20:03 |
| apb1963 | through wp | 20:03 |
| teward | Plugins > Add New, and then from that catalog? | 20:03 |
| apb1963 | yes | 20:03 |
| teward | it downloads the file locally and then FTPs it into its own work directory | 20:03 |
| apb1963 | although I'll be using the wp-cli | 20:03 |
| teward | it doesn't create an FTP connection from your system -> remote location | 20:03 |
| teward | it just pulls the file down to a temp dir, uploads the plugin via FTP to its own server, and then does the install once it's uploaded/unzipped | 20:04 |
| RoyK | why would people use FTP in 2018? | 20:04 |
| lynorian | I don't know | 20:04 |
| apb1963 | ok. so over https then. If that's true, then I guess it's ok to eliminate ftps in favor of ftp | 20:05 |
| apb1963 | RoyK, ask the wordpress developers | 20:05 |
| apb1963 | teward, thank you for the insight | 20:05 |
| teward | yep. | 20:05 |
| * apb1963 goes back to configuring | 20:06 | |
| sarnold | "because wordpress" is a pretty summary :) hehe | 21:07 |
| nacc | dpb1: rbasak: fyi, up to ~4400 packages imported, which means we're in the last 500 or so, iirc | 22:18 |
| nacc | definitely some more failures, but we'll see the result once it's all done | 22:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!