So you remote deskptop rebooted and teamviewer did not run on startup as it does not do in Linux for some strange reason:
Connect with ssh ( putty)
Then run
DISPLAY=`localhost`:0 teamviewer&
Njoy š !
Virtual machines and NTP do not go easily well together. Machines paused for extended periods tend to loose the ntp sync since the difference grows too much.
Also from VMware Docs the following info might be clarificatory:
And :
In ESX, the ESX NTP daemon runs in the service console. Because the service console is partially virtualized, withĀ the VMkernel in direct control of the hardware, NTP running on the service console provides less precise time than in configurations where it runs directly on a host operating system. Therefore, if you are using native synchronization software in your virtual machines, it is somewhat preferable to synchronize them over the network from an NTP server that is running directly on its host kernel, not to the NTP server in the service console. In ESXi, there is no service console and the NTP daemon runs directly on the VMkernel, so it works well as a NTP server for virtual machines.
Quoted from :Ā http://www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf
Easy way (And I think best solution is)
To force a sync run hwclock command.
nJoy š !
To check if your php installation can successfully send emails from a bash script try this :
Ā php -r ‘var_dump(mail(“david.saliba@testemail.com”, “test subject”, “test body”));’
Thanks Gareth !
nJoy š !
Suppose the Disk is /dev/sdb, the second scsi disk,
fdisk /dev/sdb
create as many partitions as you need using command n
Label them with command t as 8e for making it Linux LVM
Write and Exit with the command w.
Format the partitions you require using mkfs command
mkfs -t ext3 -c /dev/sdb1
LVM commands
pvcreate /dev/sdb1
vgextend VolGroup00 /dev/sdb1
lvextend -L 15G /dev/VolGroup00/LogVol01 ;for extending LogVol to 15GB
lvextend -L+1G /dev/VolGroup00/LogVol01 ;for adding one more GB to Logical Volume LogVol01
lvextend -l +100%FREE /dev/VolGroup00/LogVol01
Next you shall need to resize the filesystem.
resize2fs -l /dev/VolGroup00/LogVol01
Thats it finished Njoy Ā š !
php -i | grep -i memcache
Short and sweet
sample output :
memcache
memcache support => enabled
memcache.allow_failover => 1 => 1
memcache.chunk_size => 8192 => 8192
memcache.default_port => 11211 => 11211
memcache.default_timeout_ms => 1000 => 1000
memcache.hash_function => crc32 => crc32
memcache.hash_strategy => standard => standard
memcache.max_failover_attempts => 20 => 20
memcached
memcached support => enabled
libmemcached version => 0.50
Registered save handlers => files user memcache memcached
Njoy š
Sometimes you know passwords but are not ion a position to use shared keys. Solution is using expect to pass the password from a script read or a comman line parameter.
** NOTE Passwords in command lines are a really bad idea since you can see them in the history / ps -ef so best is to read from stdio and pass as a parameter.
#!/usr/bin/expect
spawn scp [lindex $argv 0] root@192.168.8.117:/vmfs/volumes/datastore1/
######################
expect {
-re "Password:" {
exp_send "[lindex $argv 1]\r"
}
}
interact
Where I work, we love using OVA templates to speed up our deployment of virtual machines. I recently upgraded one of my servers to ESXi 5.1 (which also required an update to vSphere). ESXi 5.1 provides support for Windows 8 and Server 2012, which is incredibly useful. However, whilst building OVA templates for these operating systems, I stumbled across an issue.
I ran through the āNew Virtual Machineā wizard, selecting Windows 8 (or Server 2012), leaving all settings default. Installed my operating system, and made the required customisations, shutdown the machine and exported an OVA template through vSphere ā excellent, how easy!
However, whilst trying to re-deploy the OVA to the ESXi 5.1 host, through the āDeploy OVA templateā wizard, it failed immediately after completing the wizard (right before it shows the deployment progress bar). Now, I have a particular hate for misleading error messages, and this one seems to fall right in-to thatĀ category –
Failed to deploy OVF package: The task was canceled by a user.
How misleading. I, or any other user, certainly didnāt cancel the task. So what happened? I took a look through the (horrendous) hostd.log on the ESXi box and found absolutely nothing of any value.
Frustrated by the inability to redeploy a template I spent so long preparing, I broke open the OVA template and took a look inside. There were three files with different extensions,
I immediately discarded (renaming to .mfx will do the trick) theĀ .mf. If you modify theĀ .ovaĀ and donāt update theĀ .mf, itāll complain that the checksum is invalid. Removing this file seems to prevent vSphere from checking the checksums, which is useful, seeing as we want to poke around theĀ .ova. After fiddling around inside theĀ .ova, I stumbled across the following lineā¦
<rasd:ResourceSubType>vmware.cdrom.iso</rasd:ResourceSubType>
Changing the above line, to readā¦
<rasd:ResourceSubType>vmware.cdrom.atapi</rasd:ResourceSubType>
ā¦appears to have fixed my deployment issues. Perhaps changing the āCD Drive Device typeā in the virtual machineās settings wouldāve fixed it. But by that point, I had already exported the OVA and deleted the source virtual machine.
Hopefully someone will stumble across this one day, and itāll save them a few hours!
When running:
svn checkout https://mysvn.mydomain.com:8443/svn/Linux/trunk/scripts/ –username *** –password ‘****’
I got :
WARNING: gnome-keyring:: couldn’t connect to: /tmp/keyring-fTq763/pkcs11: No such file or directory
Password for ‘default’ GNOME keyring: *****
svn: OPTIONS of ‘https://mysvn.mydomain.com:8443/svn/Linux/trunk/scripts’: authorization failed: Could not authenticate to server: rejected Basic challenge (mysvn.mydomain.com:8443)
Problem could be damaged keyring or wrong keyring password.
To fix quickly :
pkill keyring
re-run the checkout.
Voila ! you get a new keyring and the process works. Checkout goes through.
Njoy š
p.s.
As a desparate measure :
mv /usr/bin/mate-keyring-daemon /usr/bin/mate-keyring-daemon.rubbish
This article explains how to connect to a ssh server located on the internet from a local network protected by a firewall through a HTTPS proxy.
Requirement are :
The ssh daemon need to listen on 443 port. To accomplish this, just edit this file (on debian system)Ā /etc/ssh/sshd_configĀ and add this line :
Port 443
Then restart the daemon :
sudo /etc/init.d/ssh restart
I suppose you are on a Linux system (debian for example). First you have to compile theĀ connect binaryĀ which will help your ssh client to use proxies (HTTPS in our case). Then you have to configure your ssh client to tell him to use HTTPS proxy when he tries to connect to your ssh server.
connectĀ software :connect-proxyĀ package :
sudo apt-get install connect-proxy
cd /tmp/ wget http://www.meadowy.org/~gotoh/ssh/connect.c gcc connect.c -o connect sudo cp connect /usr/local/bin/ ; chmod +x /usr/local/bin/connect
~/.ssh/configĀ file and add these lines :
## Outside of the firewall, with HTTPS proxy Host my-ssh-server-host.net ProxyCommand connect -H proxy.free.fr:3128 %h 443 ## Inside the firewall (do not use proxy) Host * ProxyCommand connect %h %p
ssh my-ssh-server-host.net
For example to connect to in sshĀ github.comĀ :
Host github.com ProxyCommand=ssh my-ssh-server-host.net "/bin/nc -w1 %h %p"
From bash it’s easy to snap a photo from the webcam.
mplayer -vo png -frames 1 tv://
That’s it.. Njoy š