Im using Apache FtpServer and built my own ftp server. I`m using this server on a VM (VPS). Im able to login and list the files however, Im couldn't download or upload files. Every time I try I get the error
220 Service ready for new user.
USER testuser
331 User name okay, need password for testuser.
PASS ********
230 User logged in, proceed.
FEAT
211-Extensions supported
SIZE
MDTM
REST STREAM
LANG en;zh-tw;ja;is
MLST Size;Modify;Type;Perm
AUTH SSL
AUTH TLS
MODE Z
UTF8
TVFS
MD5
MMD5
MFMT
211 End
OPTS UTF8 ON
200 Command OPTS okay.
SYST
215 UNIX Type: Apache FtpServer
STAT /
212-
drwx------ 3 user group 0 Oct 25 02:46 lost+found
drwx------ 3 user group 0 Oct 25 06:27 v
-rw------- 1 user group 4496 Oct 25 06:30 working.txt
212 End of status.
TYPE I
200 Command TYPE okay.
PORT 10,9,226,222,220,45
200 Command PORT okay.
STOR /Records.xls
150 File status okay; about to open data connection.
220 Service ready for new user.
When I run the code on localhost, I can download, modify and upload files. Why this isn't working on a VM?
Related
I tried to use hydra for my sample website below:
https://demo.leafworks.jp/package/loginplus/admin.php
login id: admin
password: leafworks
login error message: ログインに失敗しました。
I tried this command:
hydra -l admin -p leafworks demo.leafworks.jp http-post-form "/package/loginplus/admin.php:login_key=^USER^&pass=^PASS^:ログインに失敗しました。"
But it returns:
Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2022-11-29 00:30:28
[DATA] max 1 task per 1 server, overall 1 task, 1 login try (l:1/p:1), ~1 try per task
[DATA] attacking http-post-form://demo.leafworks.jp:80/package/loginplus/admin.php:login_key=^USER^&pass=^PASS^:ログインに失敗しました。
1 of 1 target completed, 0 valid passwords found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2022-11-29 00:30:30
What is the problem with my command?
environment: Ubuntu 20.04.1 LTS
I am using the Cumulocity java agent (7.38.0) and it apparently lost communication with the server somehow and never recovered. The admin interface says:
LAST COMMUNICATION
November 22, 2016 2:25 AM
and last cumulo record in the the device syslog was:
Nov 22 01:25:47 localhost root: 01:25:47.166 [CumulocityLongPollingTransport-scheduler-2] WARN c.c.s.c.n.ConnectionHeartBeatWatcher - canceling the long poll request because of inactivity
(there was 1 hour time diff due to some device config prob.)
process looks running anyways:
ps -ef | grep -i c8y
root 1341 1257 0 Nov19 ? 00:00:00 /bin/sh ./c8y-agent.sh
root 1342 1341 0 Nov19 ? 00:00:00 /bin/sh ./c8y-agent.sh
root 1344 1342 0 Nov19 ? 00:25:39 java -cp cfg/*:lib/* -Dlogback.configurationFile=cfg/logback.xml c8y.lx.agent.Agent
Has anyone seen this prob before?
We had it once or twice when people were connecting to cumulocity via firewall or vpn. The result was exactly as you described: the polling gets stuck after some time, like if connections were blocked. In other words i would suspect that it’s a proxy that’s blocking the reconnect.
I am trying to install Redmine on CentOS 6.3 but I continue to get this error in the log file
Passenger could not be initialized because of this error: Unable to start
the Phusion Passenger watchdog (/usr/lib/ruby/gems/1.8/gems/passenger-4.0.20/buildout
/agents/PassengerWatchdog): Permission denied (errno=13)
I have been looking online and cannot find this error anywhere or any way to fix it. I have tried changing permissions to the folder to 777 and apache:apache but neither work.
The only solution that I have come up with to get redmine to work is to set SELinux to disabled or permissive (which I do not want to do).
Does anyone have another way to fix this problem that leaves SELinux enabled?
Found the SELinux log file under /var/log/messages
here is the end of the file
Oct 16 14:07:30 localhost pulseaudio[2329]: alsa-util.c: Disabling timer-based scheduling because running inside a VM.
Oct 16 14:07:30 localhost rtkit-daemon[2183]: Sucessfully made thread 2331 of process 2329 (/usr/bin/pulseaudio) owned by '500' RT at priority 5.
Oct 16 14:07:30 localhost pulseaudio[2329]: alsa-util.c: Disabling timer-based scheduling because running inside a VM.
Oct 16 14:07:30 localhost rtkit-daemon[2183]: Sucessfully made thread 2332 of process 2329 (/usr/bin/pulseaudio) owned by '500' RT at priority 5.
Oct 16 14:07:31 localhost rtkit-daemon[2183]: Sucessfully made thread 2427 of process 2427 (/usr/bin/pulseaudio) owned by '500' high priority at nice level -11.
Oct 16 14:07:31 localhost pulseaudio[2427]: pid.c: Daemon already running.
Oct 16 14:08:04 localhost kernel: type=1400 audit(1381957684.726:5): avc: denied { execute_no_trans } for pid=2663 comm="httpd" path="/usr/lib/ruby/gems/1.8/gems/passenger-4.0.20/buildout/agents/PassengerWatchdog" dev=dm-0 ino=1048752 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:lib_t:s0 tclass=file
Oct 16 14:08:04 localhost kernel: type=1400 audit(1381957684.760:6): avc: denied { execute_no_trans } for pid=2668 comm="httpd" path="/usr/lib/ruby/gems/1.8/gems/passenger-4.0.20/buildout/agents/PassengerWatchdog" dev=dm-0 ino=1048752 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:lib_t:s0 tclass=file
Oct 16 14:09:11 localhost pulseaudio[2329]: alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write!
Oct 16 14:09:11 localhost pulseaudio[2329]: alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_intel8x0'. Please report this issue to the ALSA developers.
Oct 16 14:09:11 localhost pulseaudio[2329]: alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
any suggestions?
So, you can fix this by using audit2allow (yum install audit-libs-python audit-libs).
SELinux logs to /var/log/audit/audit.log. If you tail and capture the output from restarting the web service (service httpd restart) you can then run the new output through audit2allow and make a module to install under selinux...
So, assuming you have captured it into a file called "audit_tmp":
cat audit_tmp | audit2allow -D -M passenger
This will create a file called passenger.pp which you can apply using:
semodule -i passenger.pp
Doing this will unblock the first thing that was stopping passenger from loading - but be aware that there will probably be more so you will need to repeats the process again until it works. I hope that makes sense!
Take a look at /var/log/syslog. That file contains SELinux error messages, which tell you how to fix up any permission problems.
I am receiving the following error while trying to accept SSL connection from a client application. I am using openssl version 0.9.8 on HP-UX IA.
SSL_accept(40107e50) -1 err: 336285997 'error:140B512D:SSL routines:SSL_GET_NEW_SESSION:ssl session id callback failed'
I have checked for /dev/random and /dev/urandom. It exists and functioning properly.
ls -l /dev/random
cr--r--r-- 1 root sys 144 0x000000 Mar 10 2010 /dev/random
cr--r--r-- 1 root sys 144 0x000001 Mar 10 2010 /dev/urandom
Please help me in identifying the root cause of the problem.
Let me know if you need more information.
This can occur when OpenSSL's PRNG is not sufficiently seeded. Check on it with RAND_status(), and seed as necessary with RAND_add() or RAND_seed(). http://www.openssl.org/docs/crypto/RAND_add.html
Non of my ftp accounts work via ftp since I upgraded to plesk 9.5.4. I get "530 login incorrect." The username and password are correct since I can see them at both at /etc/passwd and /etc/shadow. I have tried changing the information via Domains -> mydomain.com -> Web Hosting Settings -> FTP Login and I still get the error. If I add a user name or password via Web Users, it is added to the password file, but that login does not work either. My root login via SSH works fine. Any suggestions?
Thanks,
-Jonathan
Check your /var/log/messages for errors from proftpd.
Here is my /var/log/messages for simple FTP session:
Jan 16 16:39:15 localhost xinetd[577]: START: ftp pid=9317 from=::ffff:10.50.2.4
Jan 16 16:39:16 localhost proftpd[9317]: 10.52.52.203 (10.50.2.4[10.50.2.4]) - FTP session opened.
Jan 16 16:39:16 localhost proftpd[9317]: 10.52.52.203 (10.50.2.4[10.50.2.4]) - FTP session closed.
Jan 16 16:39:16 localhost xinetd[577]: EXIT: ftp status=0 pid=9317 duration=1(sec)
Jan 16 16:39:16 localhost xinetd[577]: START: ftp pid=9318 from=::ffff:10.50.2.4
Jan 16 16:39:16 localhost proftpd[9318]: 10.52.52.203 (10.50.2.4[10.50.2.4]) - FTP session opened.
Jan 16 16:39:22 localhost proftpd[9318]: 10.52.52.203 (10.50.2.4[10.50.2.4]) - Preparing to chroot to directory '/var/www/vhosts/domain.tld'
Jan 16 16:40:03 localhost xinetd[577]: Exiting...