In my case, I had a template VM in ESXi that I deployed and needed to add tons of disk space to – up to 9TB.
First, I’d suggest using cfdisk instead of fdisk – it’s got a pseudo-UI so you can see it (for those of us who don’t have as robust of a mental abstraction of command line output).
When I tried to write the changes to disk I got a message that since the disk was MBR the max size the volume could be was 2TB. Ummm….. now what?
Well, convert it to GPT of course! This can be a dangerous effort, or so it seams, but since this was a brand new machine deployed from a template, I had nothing to lose. Here’s a step-by-step that worked: https://johnlewis.ie/converting-to-gpt-in-ubuntu/
I did this a little over a week ago, but it actually worked the first time. Just make sure you get your “sda2” and “sda3” – or whatever they actually are for you – correct.
You want to schedule out the next 4 months. But Google Calendar only seems to be able to show you 6 weeks. Here’s how you can show as much as you want.
On the calendar view in the top-left of your Google Calendar main page, click on the start date you want to see then drag down, *then use your scroll wheel to scroll down* then unclick on the end date you want to include.
You want to increase the size of a disk.
You’ve got a virtual machine running.
Here’s what you do:
Make the disk bigger in VMWare or whatever your hypervisor it. Note, if you make an existing disk larger you will have to scan the drives from with the OS or reboot after creating the partition. If you add a new disk, you shouldn’t have to reboot. Either way works.
Create a partition. Use cfdisk. Tons. Easier than fdisk for those requiring a visual representation and a nicer interface. See here for a bit more info: https://en.wikipedia.org/wiki/Cfdisk. cfdisk is self-evident. You can’t really screw it up. Just use it instead of fdisk.
Or rescan the disk bus. There are a few ways, and yes this is annoyingly a big, giant hassle.
echo “- – -” > /sys/class/scsi_host/host1/scan (change the “host2” to “host3” and more numbers, then run fdisk -l or cfdisk each time to see… or just reboot if that’s acceptable.
Create a physical volume
pvcreate /dev/sda3 (whatever you saw in cfdisk)
Extend the volume group
vgdisplay (to get the volume group name and path)
vgextend /dev/tempubuntu16-vg /dev/sda3 (again, whatever you saw in cfdisk)
extend the logical volume
lvextend -l +100%FREE /dev/tempubuntu16-vg/root
Resize the logical volume
resize2fs /dev/tempubuntu16-vg/root (whatever you saw in lvdisplay)
See all your disk space
Big new winning thing I learned:
Make a Linux disk size bigger without having to reboot
There are some WordPress errors that prevent you from even getting in to your admin panel. When these are caused by a broken plugin, it can be alarming. Here’s how you can painlessly disable all your plugins so you can login. After that you will then be able to re-enable them all and then from within your admin panel selectively enable them as you please.
You need to access the folder structure directly in the server hosting your WordPress Blog. cPanel will have a link to “File Manager”; use that.
1. Rename the /wp-content/plugins folder to anything, e.g. rename it so after the rename the folder structure looks like this: /wp-content/plugins_tempRename.
2. Log in to your admin panel
– You will likely get a message about needing to update the database due to a WordPress update. For me this was quick – I think it only did some minor changes to some DB table that probably reflected the change to the plugins folder name you just did.
– If you still can’t log in, then that means the problem is *not* due to broken plugins. I’d suggest looking for some option in cPanel to “reset WordPress core files”, then try logging in again after that.
3. Once in your admin panel, navigate to the Plugins section and then “activate” the plugins one at a time (after maybe updating them if there are any updates available).
4. Profit, however marginal that may be 😉
I had seen some error message that tipped me off to there being a plugin-related problem… in my case it was an older version of W3 Total Cache:
“Fatal error: Call to undefined function wp_cache_get()”
Right after you install perforce server, it’s in a sort of initialization mode where there is no password for the default “root” user. Anybody can connect and act as that root user by simply connecting as the user “root”. So, you want to lock that down a bit. “p4 protect” is how you do this.
p4 protect may seem like where you would do user permissions. I guess you *could*, but it’s intended more as a sort of global permissions layer, where you can set some hard limits. By default all “users” will have “write” permission on everything in the instance. You can then later specify different permissions in the Perforce administration app via a client.
If you comment out the line that specifies “user” permissions in p4 protect, it will actually remove the line entirely, and only the “root” user will be able to connect at that point.. So I’m thinking of p4 protect as a sort of way to lock everyone but “root” out of the instance without messing with a full p4 client, e.g. you’re at the host console and you just need to quickly do something drastic without hosing lots of stuff.
Note, to connect with p4 connect to a specific port with a specific password you need to set some environment variables really quick before running “p4 protect”:
– these assume the user is the OS user you’re running the p4 protect command under.
Install CentOS minimal
yum install nano
Stop and disable firewall (I assume you have some other firewall):
service firewall stop
chkconfig firewall off
-change to ‘disabled’
Set up the Perforce repo as described here: https://www.perforce.com/perforce-packages
Install perforce server:
yum install perforce-server.x86_64
Set up a config file for an instance of perforce server that we’ll call “capnjosh1”:
cp /etc/perforce/p4dctl.conf.d/p4d.template /etc/perforce/p4dctl.conf.d/capnjosh1.conf
edit that new conf file:
replace %NAME% with “capnjosh1”
replace %ROOT% with where you want the files to be (/capnjosh1-p4root)
replace %PORT% with 1666
create the directory and make owned by the user perforce (automatically set up by the yum installation):
chown perforce:perforce /capnjosh-p4root/
Start perforce server:
service perforce-p4dctl start
Run p4 protect to set up core permissions:
-by default it’ll give the OS account ‘root’ full perforce access
(if you set to a different port besides 1666, you will have to set this environment variable “export P4PORT=1667”, or whatever port number you put)
If it doesn’t start, it’ll say as much… likely check your p4root folder and make sure it’s owned by the ‘perforce’ user.
Here’s what’s cool, if you want to add more perforce instances, just copy-paste that .conf file and change the name, port, and p4root path.
When you uninstall perforce, it’ll auto-rename your .conf files so they won’t get auto-loaded if you reinstall perforce again.