Andama is an open source remote desktop software, with client side encryption and privacy in mind. The project is currently in funding phase so please help as much as you can.
Laravel 5.x requires PHP version 5.5.9+. Also, in case you want to use database (sqlite or mysql), install Sqlite3, Mysql or PostgreSQL server.
Install composer with
curl -sS https://getcomposer.org/installer | php sudo mv composer.phar /usr/local/bin/composer
Install Laravel (option 1)
composer create-project laravel/laravel laravel-test
Instal Laravel (option 2)
composer global require "laravel/installer=~1.1"
Add the following to .bashrc file
at the end of the file then in terminal type
and verify that $PATH variable contains the full path to laravel executable.
Then create new Laravel project with
laravel new laravel-test
cd laravel-test php -S localhost:8888 -t public
and open http://localhost:8888 in your web browser
The Point-to-Point Tunneling Protocol (PPTP) is a method for implementing virtual private networks. Since it is marked as non secure and vulnerable, I don’t recommend it as a “final” VPN solution. The main reason for its popularity is probably the native MS Windows support (since win 95). Also, it can be easily implemented with Mikrotik RouterOS (like I said, use it for internal VPNs only).
To set up your CentOS box as a PPTP clients you’ll need the pptp package.
yum -y pptp
Open /etc/ppp/chap-secrets and add the next line (at the end). Also, replace the userName and password with the correct details:
userName PPTP password *
Create profile file
and paste the next content (replace IP_OR_HOSTNAME with PPTP server IP or hostname)
pty "pptp IP_OR_HOSTNAME --nolaunchpppd" name userName remotename PPTP require-mppe-128 file /etc/ppp/options.pptp ipparam myVPN
save the file and test the connection with
pppd call myVPN
ifconfig should return something like
.... ppp0 Link encap:Point-to-Point Protocol inet addr:10.16.18.252 P-t-P:10.16.18.251 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1436 Metric:1 RX packets:14 errors:0 dropped:0 overruns:0 frame:0 TX packets:15 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:2192 (2.1 KiB) TX bytes:631 (631.0 b) ...
also in /var/log/messages you should see something like
Jul 20 10:58:50 mysrv pppd: pppd 2.4.5 started by root, uid 0 Jul 20 10:58:50 mysrv pppd: Using interface ppp0 Jul 20 10:58:50 mysrv pppd: Connect: ppp0 <--> /dev/pts/1 Jul 20 10:58:50 mysrv pptp: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated Jul 20 10:58:50 mysrv pptp: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Jul 20 10:58:50 mysrv pptp: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply Jul 20 10:58:50 mysrv pptp: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established. Jul 20 10:58:51 mysrv pptp: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Jul 20 10:58:51 mysrv pptp: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply. Jul 20 10:58:51 mysrv pptp: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 716). Jul 20 10:58:51 mysrv pppd: CHAP authentication succeeded Jul 20 10:58:51 mysrv pppd: MPPE 128-bit stateless compression enabled Jul 20 10:58:51 mysrv pppd: local IP address 10.16.18.252 Jul 20 10:58:51 mysrv pppd: remote IP address 10.16.18.251 Jul 20 10:59:51 mysrv pptp: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
If you check your routes, you’ll probably notice that ppp0 connection is not used by any route(s). This is default behavior and you can easily switch/add default route with:
route add default dev ppp0
In my case, I don’t want to route the complete traffic (this VPN is just for management) so I’ll add only one static route
route add -net 192.168.120.0/24 dev ppp0
To start this connection on boot, add “pppd call myVPN” in rc.local.
According to this link , Google will abandon development and official support of the Android Developer Tools in Eclipse. Instead ADT, the main focus and interest will be on Android Studio. This applies specifically to the ADT plugin and Android Ant build system.
Projects from Eclipse can be easily migrated to Android Studio with just a few simple clicks.
For more information, please check the next link: Android Developers Blog
I found the next error message in the log
May 8 10:48:57 srv kernel: ACPI Error: SMBus/IPMI/GenericSerialBus write requires Buffer of length 66, found length 32 (20130517/exfield-299) May 8 10:48:57 srv kernel: ACPI Error: Method parse/execution failed [\_SB_.PMI0._PMM] (Node ffff88042949d960), AE_AML_BUFFER_LIMIT (20130517/psparse-536) May 8 10:48:57 srv kernel: ACPI Exception: AE_AML_BUFFER_LIMIT, Evaluating _PMM (20130517/power_meter-339)
The message is generated every 5 minutes when lm-sensors try to read the values from the power meter sensor(s). HP has ignored the spec for this method and the result is the error shown above.
The problem can be solved on two ways:
– you can ignore this message (it is safely to ignore)
– you can skip the power meter sensors (at least until someone fix this)
Since I already have the latest firmware, I can’t suggest the firmware update (at least for 310 gen8 server).
To reproduce the problem just find the file power1_average and try to read it
find /sys/devices/LNXSYSTM\:00/ |grep ACPI000D
In my case the file is located in /sys/devices/LNXSYSTM:00/device:00/ACPI000D:00/
Read the file
The result will be probably 0 and the error will be thrown in the log.
To solve the problem check the exact sensor which is affected with:
[root@srv log]# sensors ... power_meter-acpi-0 Adapter: ACPI interface power1: 0.00 W (interval = 300.00 s) ....
As you can see above, the sensor is power_meter-acpi-0. Now disable the sensor by adding
chip "power_meter-acpi-0" ignore power1
at the end of the /etc/sensors3.conf file.
The reboot is recommended but it is not necessary.
Check the sensor again with
[root@srv log]# sensors ... power_meter-acpi-0 Adapter: ACPI interface ....
As you can see, the line “power1….” is missing and the log is empty.
If you’re a regular visitor, you’ll probably notice the new theme. I usually don’t change the things which works but since Google decided to penalize non mobile-friendly sites I had to change the theme.
Until I find the decent theme, …
If you’re trying to install CentOS 7 on HP server and you receive the error from the caption, don’t worry – you’re not alone. According to Google, there are about 48400 results related to this topic
The fix is still not available and according to HP, the problem is related to “Processor Power and Utilization Monitoring” function which should be disabled to fix this mess.
– All ProLiant Gen8 Servers
– ProLiant DL580 G7
– ProLiant BL620 G7
– ProLiant BL680 G7
How to disable “Processor Power and Utilization Monitoring”:
– enter BIOS (press F9 during boot)
– press CTRL+A (Service Option is hidden by default)
– select “Service Options” -> Processor Power and Utilization Monitoring -> Disable
Press F10 to save and exit and reboot the server.
More information can be found on the next links:
DL380 Gen9 is also affected with this problem. The solution remains the same (disable Processor Power and Utilization Monitoring)
Edit: 2016-03-31 (comment by Jimmy)
There really isn’t any fix needed. It is just an informational message. The system is reserving performance counters for system management and the kernel wants to own all the performance counters regardless. You can disable the ProLiant management features if you really want to stop the message. Other than printing the message during boot, there isn’t any negative impact on the system or performance.
The server which worked perfectly for years, after reboot decided to post the message:
Strike F1 key to continue, F2 for setup utility
The “fix” for this problem is to read carefully the posted messages shown during boot and to fix the problem. In my case, the problem was a faulty memory module which just lost a contact in the slot.
According to Wikipedia, middle age crisis is a term which describes a critical phase in human development during the forties to early sixties. I’m still in early thirties and something happens with me which can be “fixed” with the “beauty” from the image below.
This summer will be used to finally get the bike licence (“A” category). The next one, …. Yeah…
Today I had a chance to test Huawei E173 USB dongle and it works perfectly on my Mint Linux. All I had to do was to plug it in and turn on via network manager applet.
I wanted to test this dongle with CentOS 6 and the main idea was to use this device for SMS monitoring. Using online SMS providers is much cheaper and easier (a bunch of APIs) but the online services are useless when your network is disconnected.
There are a lot differences between RH based server distros and the new/cutting edge distro like Mint. To be honest, I expected the problems with CentOS.
The first thing was to check the USB dongle
[root@server ~]# dmesg |grep usb .... usb 2-4: new high speed USB device number 2 using ehci_hcd usb 2-4: New USB device found, idVendor=12d1, idProduct=1446 usb 2-4: New USB device strings: Mfr=3, Product=2, SerialNumber=0 usb 2-4: Product: HUAWEI Mobile usb 2-4: Manufacturer: HUAWEI Technology usb 2-4: configuration #1 chosen from 1 choice usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning usbcore: registered new interface driver usb-storage usb-storage: device scan complete usb-storage: device scan complete ...
Ops… the device is detected as USB storage which I didn’t expect (and I don’t want).
[root@server ~]# lsusb ... Bus 002 Device 002: ID 12d1:1446 Huawei Technologies Co., Ltd. E1552/E1800/E173 (HSPA modem)
After some googling I discovered that the first thing I need to do is to install usb_modeswitch and smstools packages. The first package will be used to switch USB dongle from usb storage into modem mode. The second one will be used for SMS operations.
In the moment I tested this, I was far away from the server and I couldn’t try the simple plug/unplug method. The solution was to invoke the next command
[root@server ~]# usb_modeswitch -c /etc/usb_modeswitch.d/12d1\:1446 -v 0x12d1 -p 0x1446 Looking for target devices ... No devices in target mode or class found Looking for default devices ... found matching product ID adding device Found device in default mode, class or configuration (1) Accessing device 002 on bus 002 ... Getting the current device configuration ... OK, got current device configuration (1) Using first interface: 0x00 Using endpoints 0x01 (out) and 0x81 (in) Inquiring device details; driver will be detached ... Looking for active driver ... No driver found. Either detached before or never attached SCSI inquiry data (for identification) ------------------------- Vendor String: HUAWEI Model String: Mass Storage Revision String: 2.31 ------------------------- USB description data (for identification) ------------------------- Manufacturer: HUAWEI Technology Product: HUAWEI Mobile Serial No.: not provided ------------------------- Setting up communication with interface 0 Using endpoint 0x01 for message sending ... Trying to send message 1 to endpoint 0x01 ... OK, message successfully sent Resetting response endpoint 0x81 Could not reset endpoint (probably harmless): -71 Resetting message endpoint 0x01 Could not reset endpoint (probably harmless): -19 Device is gone, skipping any further commands -> Run lsusb to note any changes. Bye.
As the output recommended, I tried again with lsusb
[root@server ~]# lsusb .... Bus 002 Device 003: ID 12d1:1001 Huawei Technologies Co., Ltd. E169/E620/E800 HSDPA Modem ...
Also, after this step, you should have
[root@server smsd]# ls /dev/ttyUSB* /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2
I found that the settings file /etc/smsd.conf (for SMSTools) should be something like this:
devices = GSM1 logfile = /var/log/smsd/smsd.log loglevel = 7 user = smstools infofile = /var/run/smsd/smsd.working pidfile = /var/run/smsd/smsd.pid # 3.1.5 introduced smart logging # once your configuration is OK, set log level lower (5 is good in most cases) smart_logging = yes [GSM1] init = AT+CPMS="ME","ME","ME" device = /dev/ttyUSB0 incoming = yes
You can find more information about the configuration parameters on the next link http://smstools3.kekekasvi.com/index.php?p=configure
Start smsd service with service smsd start
To send SMS message go into /var/spool/sms/outgoing/ dir and create the file testSMS (for example) and add the next content inside
To: 38765655849 fdfgdfgfg
The other option is to use smssend command.
In case that something doesn’t work, check the logs inside /var/log/smsd/ dir.