capnjosh

in my case it’s a 2+ TB file I’m copying with scp. I can’t realistically expect to keep a putty window open the whole time. Here’s a Stack Overflow post that seems to be working alright:

http://unix.stackexchange.com/questions/65116/does-a-scp-transfer-close-when-i-close-the-shell (3rd comment down, by

Create screen
user@server:~$ screen -S bigscptransfer

You’re now in the screen
ser@server:~$ scp bigfile.dat server2:.

Detach from the screen using CTRL+A then push D
[detached from 5899.bigscptransfer]

Resume session when you need it with:
user@server:~$ screen -r bigscptransfer

Pretty straightforward from here:

wget -qO – https://package.perforce.com/perforce.pubkey | sudo apt-key add –

nano /etc/apt/sources.list.d/perforce.list
….. then add the following line to that file
deb http://package.perforce.com/apt/ubuntu xenial release

apt-get update

apt-get install helix-p4d -y

/opt/perforce/sbin/configure-helix-p4d.sh

… in the step where you choose the port, “ssl:1666” means it sets up ssl, which means *everything* has to use ssl configs, which is another layer of complexity. Handy, yes, but more complex.

After that, you can log in with any p4 client. It’s pretty good. You’ll have a new user – perforce – that runs the server, and things are generally in good shape.

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.

Got it working. See here: https://capnjosh.com/blog/setting-up-perforce-replication/

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.

Reboot
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
lvdisplay
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
df -h

Big new winning thing I learned:
cfdisk

References:
http://www.joomlaworks.net/blog/item/168-resizing-the-disk-space-on-ubuntu-server-vms-running-on-vmware-esxi-5

Make a Linux disk size bigger without having to reboot

http://serverfault.com/questions/724561/how-to-resize-a-virtual-machine-running-ubuntu-in-vmware-5

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.

In short:

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”:
export P4PORT=1667
export P4PASSWD=Changeme41
– these assume the user is the OS user you’re running the p4 protect command under.

Install CentOS minimal

Start NIC
ifup eth0

yum update
yum install nano

Stop and disable firewall (I assume you have some other firewall):
service firewall stop
chkconfig firewall off

disable selinux:
nan /etc/selinux/config
-change to ‘disabled’
-reboot

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):
mkdir /capnjosh1-p4root
chown perforce:perforce /capnjosh-p4root/

Start perforce server:
service perforce-p4dctl start

Run p4 protect to set up core permissions:
p4 protect
-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.

Here’s the key:

add the proxy configs to catalina.properties, just at the end, one per line. This is only mentioned in the Confluence-proxy article I found, but it works with Jira as well. Much cleaner.

/opt/atlassian/confluence/conf/catalinia.properties. Here’s what I added to the end of that file:

# Proxy Settings
http.proxyHost=10.22.1.2
http.proxyPort=8080
https.proxyHost=10.22.1.2
https.proxyPort=8080
http.nonProxyHosts=localhost\|10.22.18.45

NOTE: that nonProxyHosts doesn’t *seem* to work with wildcards, e.g. 10.*.*.*
When I did it this way I could never get Confluence to actually connect to Jira and Jira to connect to Confluence. You have to specify the entire IP address. Otherwise, you’ll get messages about “connection refused” or “the application doesn’t appear to be online”. Not very helpful at all, no sir.