Solved

Getting device busy when trying to mount a new file syst for a web server quota

Posted on 2008-11-02
23
902 Views
Last Modified: 2008-11-05
Hi,

Below is a segment from my command line. I am trying to implement a quota on the webserv group, which is the group that will only have access to the Document Root directory for serving up web pages.

[root@localhost /]# mount /usr
mount: /dev/md5 already mounted or /usr busy
mount: according to mtab, /dev/md5 is already mounted on /usr
[root@localhost /]# quotaon -v /usr
quotaon: Mountpoint (or device) /usr not found.
[root@localhost /]# quotaon -v usr
quotaon: Mountpoint (or device) /usr not found.
[root@localhost /]#



I am reading a tutorial on how to initiate quotas and here is the tutorial segment:



# df k
# touch /usr/quotas
# edquota webserv

"/tmp/EdP.ai3aOSH" 2 lines, 127 characters fs /usr blocks (soft = 0, hard = 1) inodes
(soft = 0, hard = 1)

# cat /etc/mnttab
/dev/dsk/c0t0d0s0 / ufs
rw,intr,largefiles,onerror=panic,suid,dev=2200000 1020099612
/proc /proc proc dev=3ac0000 1020099612
mnttab /etc/mnttab mntfs dev=3cc0000 1020099628
swap /var/run tmpfs dev=1 1020099628
swap /tmp tmpfs dev=2 1020099631
/dev/dsk/c0t0d0s3 /usr ufs
rw,intr,largefiles,quota,onerror=panic,suid,dev=2200003 1020099631
# umount /usr
# mount /usr
# quotaon v /usr
/usr: quotas turned on



I am not getting the results I should be at all.

Thank you for your help in advance,

D
0
Comment
Question by:designitm
  • 13
  • 10
23 Comments
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 22865308
Hi,
why do you try to enable qoutas for /usr? Isn't it your Document Root you'd like to apply quotas on?
Is the fs in question defined with quotas in your fstab (usrquota/grpquota)?
Since it's generally not possible to remount /usr, you might have to reboot after modifying fstab (if it's really /usr)
Did you create the quota files with 'quotacheck -cvug [fs]' ?
Please post, we'll discuss the futher steps then.
wmp
 
0
 

Author Comment

by:designitm
ID: 22865358
Hi,

Thank you for touching upon this issue.

I am trying to put the quota on the Document Root. I am trying to make it that the webserv group which only has the ability to serve the web pages wont be able to write anymore files. Now, I am not really too familiar with this practice in general and do not know exactly how to do this. I think the book I am reading assumes a higher level than I may be in certain areas.

I did not use quotacheck, I will copy the tutorial that I was using, which comes from the Safari Book online site. It looks a lot longer than it is, I think you will be able to identify the key information in this tutorial:

Create the Web Groups and User Account

In order to segment duties and associate real users with web content, we want to create new group accounts. The account names will vary depending on your environment. The goal is to create specific groups that serve certain functions. For example, the webadmin group would own and maintain the web servers configuration documents located in the /path/to/apache/conf, /bin, and /logs directories. The webdev group would own and maintain all of the actual web document root files within the /path/to/apache/htdocs directory. The webserv group is only used as the group association that the webserv user has. We do not want the webserv user to be a member of the users group. We will discuss how to modify the ownership and permissions on directories and files in a later section.

Execute the following commands to create the appropriate web groups:

# groupadd webadmin
# groupadd webdev
# groupadd webserv


In the example in this section, we use the names webadmin, webdev, and webserv. These names are provided as examples only.

Using the same rationale for the creation of separate web groups, a separate user account should be established that has no function other than owning the Apache processes and files. This helps to prevent the Apache user account from inadvertently gaining unintended privileges by being associated with any other groups. In the unfortunate event that the Apache process is taken over, the attackers will be limited in what they can do due to user and group account isolation.

As an example, let's take a look at some real Apache honeypot shell log data after an attacker broke into the Apache web server by exploiting the SSL vulnerability. Once the shell was spawned by the exploit, the attacker issued the following commands:
Code View: Scroll / Show All

sh-2.05$ id
uid=48(apache) gid=48(apache) groups=48(apache)
sh-2.05$ cat /etc/issue
Red Hat Linux release 7.2 (Enigma)
Kernel \r on an \m

This server is operated for authorized users only. All use
is subject to monitoring. Unauthorized users are subject to
prosecution. If you're not authorized, LOG OFF NOW!
sh-2.05$ ps x

  PID   TTY   STAT  TIME COMMAND
 2281  ?      Z    0:00 [httpd <zombie>]
 2282  ?      Z    0:00 [httpd <zombie>]
 2283  ?      Z    0:00 [httpd <zombie>]
 2284  ?      Z    0:00 [httpd <zombie>]
 2285  ?      Z    0:00 [httpd <zombie>]
 2286  ?      Z    0:00 [httpd <zombie>]
 2287  ?      Z    0:00 [httpd <zombie>]
 2288  ?      Z    0:00 [httpd <zombie>]
 2289  ?      Z    0:00 [httpd <zombie>]
 2290  ?      Z    0:00 [httpd <zombie>]
 2291  ?      Z    0:00 [httpd <zombie>]
 2292  ?      Z    0:00 [httpd <zombie>]
 2293  ?      Z    0:00 [httpd <zombie>]
 2294  ?      Z    0:00 [httpd <zombie>]
 2295  ?      Z    0:00 [httpd <zombie>]
 2296  ?      Z    0:00 [httpd <zombie>]
 2297  ?      Z    0:00 [httpd <zombie>]
 2301  p2     R    0:00 ps x
 2985  ?      S    0:00 ./bash
 4247  ?      S    0:00 ./bash
 4248  p1     S    0:00 sh -i
16433  ?      S    0:00 ./bash
16434  p2     S    0:00 sh -i
21510  ?      S    0:00 ./bash
21511  p3     S    0:00 sh -i
23289  p3     S    0:00 /dev/shm/k
23292  p3     Z    0:00 [k <zombie>]
23302  p3     Z    0:00 [k <zombie>]
sh-2.05$
sh-2.05$ killall -9 bash k httpd
httpd(801): Operation not permitted
bash(901): Operation not permitted


                                


After checking their user id (which indicated that they were running the shell as the Apache user) they checked the /etc/issue file for information. Then they tried to issue the killall command to terminate all of the bash, httpd, and program "k." The attacker was unable to kill either the httpd Apache processes or the bash shell because the Apache user did not have sufficient rights to terminate those programs as these were owned by the root user. In order to fully "own" the host, the attacker would need to execute a local privilege escalation attack to become the root user.

When the Apache server is configured to run on the standard HTTP port 80, then the httpd daemon process must be owned by root, as only root can start a listener on a privileged port (i.e., a port number less that 1024). This could represent a significant security threat if an attacker ever hijacks the web server, as any commands executed would operate with full root privileges. The Apache daemon protects against this by spawning several child processes that do the actual work of listening for client requests. The Apache user owns these child processes. In this way, the Apache server is protected because the main daemon merely spawns or kills child processes and is segmented from all client requests.

The "nobody" userid and group that comes default on UNIX variants should not be used to run the web server. The "nobody" account was originally introduced as a means to map the "root" account over NFS. Due to the underlying association between the "nobody" and "root" accounts, it is best to create new accounts for the sole purpose of running the web server. Create an account with a name such as webserv, which runs the web server software. In the next entry, we designate the web document root as the webserv user's home directory. Using the -m flag will create this directory if it does not already exist. Because this account will never be used to log into for shell access, we do not need to create the normal user account login files. Designating the web server document root as the home directory for the webserv user also helps with security since we will be creating a restrictive disk quota in an upcoming section. This will prevent the webserv OS account from ever creating any new files in the document root, thus preventing many web defacement attacks.

Execute the following command to create the Apache web server user account:

# useradd d /usr/local/apache/htdocs g webserv c "Web Server Account"
-s /bin/bash webserv
# passwd webserv
 Changing password for user webserv
 New UNIX password:
 Retype new UNIX password:
 Passwd: all authentication tokens updated successfully
# tail 1 /etc/passwd
webserv:x:501:503:Web Server Account:/usr/local/apache/htdocs :/bin/bash


We then create a password for this account. Once a password is added, we then tail the /etc/password file to double-check that our new account has been created successfully. Since this account will never be used to log into for normal shell access, we do not need to create the normal user account login files. Designating the web server document root (/usr/local/apache/htdocs) as the home directory for the webserv user also helps with security since we will be creating a restrictive disk quota in the future steps. This will prevent the webserv OS account from ever creating any new files in their home directory. In the previous command, the /usr/local/apache/htdocs pathname is the path to your DocumentRoot and the webserv user account name is the name of the process that will run the Apache child processes. Again, use an account-naming convention unique to your site.
Lock Down the Web Server User Account

To make sure the user account you created cannot be logged into, you want to lock this new account by using the passwd command. Additionally, by using the usermod command, you are changing the default system shell for the new user to a non-valid shell. In the next example, webserv is equal to the name of the web user account you created.

Execute the following commands to lock down the new webserv account:

# passwd l webserv
Changing password for user webserv
Locking password for user webserv
Passwd: Success
# usermod s /bin/false webserv
# grep webserv /etc/shadow
webserv:!$1$KxCOaOcA9U$irW8YbkSq1B2.:11897:0:99999:7:-1:-1:134532732
# grep webserv /etc/passwd
webserv:x:501:503:Web Account:/usr/local/apache/htdocs:/bin/false
# login webserv


First, we use the passwd l command to lock the webserv account. We then use usermods to change the default shell from /bin/sh or /bin/bash to /bin/false. We then test our changes by looking at the webserv entry in the /etc/shadow file. We can confirm that the webserv account is locked by seeing an exclamation point (!) preceding the encrypted password hash in the second field. We then check the /etc/passwd setting for the webserv account to verify that /bin/false is now the default shell. The last step is to actually try and log into the webserv account.

NOTE

You should probably do this within a separate tty-terminal, since the /bin/false entry will kill the current session.

Implementing Disk Quotas

There are two main security benefits for implementing disk quotas on the Apache user account:

   1.

      Prevent a web site defacement.

      One of the primary tricks that an attacker will use to deface a site is to create or replace the home page for the web site. UNIX systems have several different mechanisms to keep a user from being able to create or modify files on the system. One of these is the disk quota system. This functionality can be used to supplement the filesystem read/write/execute permissions.
   2.

      Prevent the web server from filling up the disk with new files.

      One sort of attack that you want to prevent is filling up the filesystem that is hosting your DocumentRoot. Running out of room can often cause programs to act strangely and might allow permanent damage to files if the filesystem were filled and then files were accessed and not allowed to write completely.

The use of the quota settings should be evaluated by each organization. This setup may not work appropriately if the Apache web server uses more interactive application add-ons that need to create files within the DocumentRoot such as PHP, MySQL, and so on. Before implementing any disk quotas, it is necessary to identify how the system is partitioned. Your partition-naming convention may be different, and most of the references in this document will use the /usr/local path description. This will be the partition that functions as both the Apache html document root and will hold the webserv user's home directory.

The goal of this implementation is to apply a disk quota to the new system account "webserv," which will be the userid that the Apache web server runs as. By placing a restrictive quota that will not allow the webserv user to create ANY new files on the partition that the web server document root resides, we can defend against many of the typical methods attackers use to deface or compromise a web site. This technique would deter attacks where the web server is tricked by an insecure CGI script into executing a command such as

"/bin/echo 'You've been 0wned!!!' > htdocs/index.htm"


The disk quota system provides two limits on a user's disk usage: limits on the maximum number of inodes a user can have and limits on the number of disk blocks a user can have. These limits are configured on a per-user basis on the specified filesystem. In the following sessions, the partition that holds the Apache DocumentRoot is /usr. We first must create a file called quotas on the target partition. We can then use the edquota command to enter in our quota details.

# df k
Filesystem eferr used avail capacity Mounted on
/dev/dsk/c0t0d0s0 6191949 5303753 826277 87% /
/proc 0 0 0 0% /proc
fd 0 0 0 0% /dev/fd
mnttab 0 0 0 0% /etc/mnttab
swap 1659688 8 1659680 1% /var/run
swap 1660384 704 1659680 1% /tmp
/dev/dsk/c0t0d0s3 7995933 232001 7683973 3% /usr
# touch /usr/quotas
# edquota webserv


The edquota command will place you within your specified editor program (in this case, vi). Within the vi session, change both of the block and inode hard settings to equal 1:
Code View: Scroll / Show All

"/tmp/EdP.ai3aOSH" 2 lines, 127 characters fs /usr blocks (soft = 0, hard = 1) inodes
(soft = 0, hard = 1)


                                


It is easy to unintentionally implement an undesired effect. Our goal is to disallow any new files to be created or owned by the webserv user. Note that setting a quota to 0 disables that quota; this is why we set the hard limits to 1. Next, we add the quota option to the /usr partition in the /etc/mnttab file. In order for the new quota feature to become enabled, we must re-mount the partition. We then use quotaon to turn on the quota mechanism on this partition.

# cat /etc/mnttab
/dev/dsk/c0t0d0s0 / ufs
rw,intr,largefiles,onerror=panic,suid,dev=2200000 1020099612
/proc /proc proc dev=3ac0000 1020099612
mnttab /etc/mnttab mntfs dev=3cc0000 1020099628
swap /var/run tmpfs dev=1 1020099628
swap /tmp tmpfs dev=2 1020099631
/dev/dsk/c0t0d0s3 /usr ufs
rw,intr,largefiles,quota,onerror=panic,suid,dev=2200003 1020099631
# umount /usr
# mount /usr
# quotaon v /usr
/usr: quotas turned on


We now have an active disk quota on /usr for the webserv user. The only problem is that with this quota, the webserv user still is able to own one inode/file. This means that a successful defacement could still take place. We need to fulfill the webserv quota by creating one new file and assigning ownership to the webserv user.

# touch /usr/local/apache/test
# chown webserv /usr/local/apache/test
# repquota v /usr
/dev/dsk/c0t0d0s3 (/usr):
 Block limits File limits
User        used  soft  hard  timeleft  used  soft  hard  timeleft
Webserv     1     0     1               1     0     1


The final step is to actually run a test to see if we can create any new files on the /usr partition as the webserv user. In order to run this test, you will need to temporarily unlock the webserv account. Execute the following commands to verify the quota for the new account:

# su  webserv
Block limit reached on /usr
File count limit reached on /usr
$ id
uid=102(webserv) gid=1(other)
$ touch /usr/local/apache/test2
quota_ufs: over file hard limit (pid 15849, uid 102, fs /var)
touch: test2 cannot create


Notice the preceding status message when we log into this account. The system lets us know that we have reached our limit for the /usr partition immediately upon entering our shell. We then try and create a new file in the DocumentRoot directory, and we are denied with the status message below saying that creating this file would put us over the hard quota limit.


Thank you again,

D
0
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 22865406
OK, first, please tell me -
1. again - where is your Document Root? Is it really /usr/local/... or something else?
2. How far did you advance in the above tutorial? Did you already create/define something?
wmp
 
0
 

Author Comment

by:designitm
ID: 22865415
Hey,

The document root is in /usr/local/apache/htdocs (is this bad?)

I have advanced all the way to:

# cat /etc/mnttab
/dev/dsk/c0t0d0s0 / ufs
rw,intr,largefiles,onerror=panic,suid,dev=2200000 1020099612
/proc /proc proc dev=3ac0000 1020099612
mnttab /etc/mnttab mntfs dev=3cc0000 1020099628
swap /var/run tmpfs dev=1 1020099628
swap /tmp tmpfs dev=2 1020099631
/dev/dsk/c0t0d0s3 /usr ufs
rw,intr,largefiles,quota,onerror=panic,suid,dev=2200003 1020099631
# umount /usr
# mount /usr
# quotaon v /usr
/usr: quotas turned on

I am stuck at the "#umount /usr" line

Thanks,

D
0
 

Author Comment

by:designitm
ID: 22865443
Another added question which goes along with this segment:

In the same book I get to a file permission changing section where it says to update the httpd.conf file to have

User webserv
Group webserv

but in the command line it says to implement these lines:

# chown -R root:webdev /usr/local/apache/htdocs
# chmod -R 664 /usr/local/apache/htdocs

This puts the webserv directory under the webdev group appose to the webserv group. Now the file says forbidden access permission denied when I go to view it in the browser.

Thank you again,

D

0
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 22865552

1. To have the document root in /usr/... is a bit uncommon, because somebody could unintentionally fill up this filesystem, which will cause problems. Even if you use quotas to prevent users from doing so, an administartor could still fill it up.
2. Does your mnttab really look like the one in your post?   If so, /usr is already prepared for quotas.
wmp
0
 

Author Comment

by:designitm
ID: 22865596
Hi,

This is what I get when I run cat /etc/mtab:

/dev/md1 / ext3 rw 0 0
none /proc proc rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
/dev/md5 /usr xfs rw 0 0
/dev/md7 /var xfs rw 0 0
/dev/md6 /home xfs rw,usrquota 0 0
none /tmp tmpfs rw,size=1g 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

It says the /usr directory is mounted on the /dev/md5 "device?"

What would a recommendation be when placing a document root in relation to the apache server?

I know these are a bunch of questions but your help is greatly appreciated.

Thank you,

Daniel
0
 
LVL 68

Accepted Solution

by:
woolmilkporc earned 500 total points
ID: 22865702
Ok, you can still have your document root in the path where it is now, but I'd suggest creating a new FS and mount it there, e,g, /usr/local/htdocs or the like. This would imply, however,  that you take a backup of some kind, create the FS and then restore the data. But don't rely on me in creating FS's on CentOS (or RedHat) since I'm not a true expert for those systems.
Back to mtab - quotas are not yet enabled. You'll have to edit /etc/fstab to add the usrquota and grpquota options to the FS in question.
For /usr something like the following -
/dev/md5 /usr xfs rw,usrquota,grpquota 0 0
You must reboot, if it's /usr
The other questions, later.
wmp
 
0
 

Author Comment

by:designitm
ID: 22865721
I really appreciate this, thank you!

All the best,

D
0
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 22865734
And I thought the adventure was just beginning ...
0
 

Author Comment

by:designitm
ID: 22865748
Ohh it is.... I just don't want to impose too much at once. I am stuck on the permission issue with the server user and group settings.

Any help would be great :)
0
6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

 
LVL 68

Expert Comment

by:woolmilkporc
ID: 22865858
Hi again,
did you really issue
# chown -R root:webdev /usr/local/apache/htdocs
# chmod -R 664 /usr/local/apache/htdocs
If so, htdocs has READ permission by 'others' which should be sufficient to be able to read it.
0
 

Author Comment

by:designitm
ID: 22865880
Hey,

I did issue those commands, but when I change the httpd.conf file to

User webserv
Group webserv

while running two other commands:

# chown -R root:webadmin /usr/local/apache/conf
# chmod -R 660 /usr/local/apache/conf


It then tells me I am forbidden.

Is this not good?

Thanks,

D
0
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 22865913
Well, chmod 660 is different from chmod 664, obviously. The last '0' would mean 'Don't give any permissions to other people than those in the webadmin group or root', while '4' means 'Give read access to just anybody'.
http://www.ss64.com/bash/chmod.html
wmp
0
 

Author Comment

by:designitm
ID: 22865957
Yeah, that is what the book was saying to do.

Here is the tutorial snippet:

Updating Ownership and Permissions

Setting the appropriate ownership and permissions (utilizing the newly created webadmin, webdev, and webserv groups from a previous section) of the Apache files and directories can help to prevent/mitigate exploitation severity. These changes should be made just before deployment into production to correct any insecure settings during your testing phase. It is also advisable to check/update these settings on a continued basis through a Cron job. We will be updating the ownership and permissions of the following directories and files.
Server Configuration Files

We want to protect all the Apache web server configuration files from unauthorized changes. These settings will modify the files so that only the root user, and members of the WebAdmin group, will be able to read, write, or execute any of the files within the conf subdirectory.

NOTE

Care should be taken if you are utilizing any access control lists. Keep in mind; if you create an Apache passwd file by using the htpasswd binary, the appropriate permissions must be in place to allow the httpd child process (owned by webserv) to read this file. If you place the passwd file in the server configuration directory, then you will have to reapply the Read permissions back to your /usr/local/apache/conf/passwd file.

# chown -R root:webadmin /usr/local/apache/conf
# chmod -R 660 /usr/local/apache/conf
# chmod 664 /usr/local/apache/conf/passwd



DocumentRoot Files

We want to protect all the content within our document root from unauthorized changes. The following settings will modify the files so that only the root user, and members of the WebDev group, will be able to read, write, or execute any of the files within the conf subdirectory. This means that the user that our web server is running aswebservwill only be able to read files. The webserv user will not have write access to any files within our web site.

# chown -R root:webdev /usr/local/apache/htdocs
# chmod -R 664 /usr/local/apache/htdocs

Additionally it says to change the user and group settings in the conf file to that of webserv

What do you think?

D
0
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 22866019
The clue is that apache (httpd) must run under the userid of someone in the webserv group (user 'webserv'). This is accomplished by the 'USER' and 'Group' entries in httpd.conf, as stated in your post above ('Additionally it says ...')
Issue 'apachectl restart' after making changes in httpd.conf.
btw, I feel a bit uncomfortable in working in a closed thread. What can we do? Reopen? (Don't know whether that's possible)
wmp
0
 

Author Comment

by:designitm
ID: 22868992
Hey,

Reopen? I have issued a restart command after changing the httpd.conf file. When you say working in a closed thread, what do you mean by this. Normally when you have the httpd.conf file it starts you off as apache or daemon, something like this, wouldn't these threads be closed as well?

D
0
 

Author Comment

by:designitm
ID: 22869183
Do you think it could have with the passwords and group values for the webserv user. Maybe they cannot read the credentials?

D
0
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 22869348
Hi,
I meant to say that we are working _here_ at EE on a closed thread (=question and answers) which is not common practice. Sorry for not having been clear enough.
But back to topic:
What is the status?
Given that httpd.conf now contains the correct values for 'user' and 'group' and given you issued all the chown commands as described above, and given you restarted apache, I would think that all is now working as expected (except for the quotas, of course).
Is this the case?
wmp



0
 

Author Comment

by:designitm
ID: 22869832
Hi,

I wish it was the case. I will explain what I had done originally to lead to this point and maybe you can see an error in my ways that had stemmed from the beginning.

I have a server that I rent from a company and they give you either a minimal system (without PHP and Apache), or a complete system that runs Plesk 8.3, Apache 3.3.3 and PHP 5.1.6.

Os wise I can choose from a selection, but the most recent and top pick by them was CentOs 5.+.

I wanted to upgrade the Apache server and upgrade my PHP version to Apache 2.2.10 and PHP 5.3. I had accomplished this, but in order to do so, I had to install both in different locations from the server, because I could'nt get the exact layout they were using for both PHP and Apache (though I think the Apache layout was RedHat) and that installed okay when I chose that but PHP couldn't be found after installation.

So I used a different partition in the /usr directory appose to the /etc directory that Apache and PHP were in.

Everything I have done up to now has worked great, but now I am in the "juicy" stuff which is permissions and quotas and all that and I am running into the issues from before.

Do you think something along the way could have led me up to this error, and do you have any other suggestions of my set up based on what you are reading.

I have thought that I would re-initialize the server I have with them and try a minimal installation and do the steps up to the point where we had left off to see if it gives better results.

By the way how can we work in a more open thread? Should I re-issue the question to an open group?

Thanks,

D
0
 

Author Comment

by:designitm
ID: 22869841
Sorry the Apache version they give is 2.2.3

D
0
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 22870224
First, forget about the "closed thread" stuff'.

Second,
"So I used a different partition in the /usr directory appose to the /etc directory..."
In my opinion this can't be the cause of a problem, given you have your new httpd.conf set up correctly regarding all paths (e.g. document root etc.) and regarding the user/group ids.
If, beyond that, you also issued the above chmods and chowns against the right paths/files (= your new ones), everything should be fine.

So, if it isn't anyhow, it could actually be better to start over, as I guess this could soon end in a mere confusion.

What do you think?
Of course you are welcome to get back here and ask for help. I will be here watching (and will help if I can).

Cheers
Norbert


0
 

Author Comment

by:designitm
ID: 22871160
Thank you very much. I will let you know how it turns out either way and will be making all these new changes within the next hour or so.

I really appreciate you time,

Daniel
0

Featured Post

Superior storage. Superior surveillance.

WD Purple drives are built for 24/7, always-on, high-definition security systems. With support for up to 8 hard drives and 32 cameras, WD Purple drives are optimized for surveillance.

Join & Write a Comment

Phishing is at the top of most security top 10 efforts you should be pursuing in 2016 and beyond. If you don't have phishing incorporated into your Security Awareness Program yet, now is the time. Phishers, and the scams they use, are only going to …
Never store passwords in plain text or just their hash: it seems a no-brainier, but there are still plenty of people doing that. I present the why and how on this subject, offering my own real life solution that you can implement right away, bringin…
Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:
In a previous video, we went over how to export a DynamoDB table into Amazon S3.  In this video, we show how to load the export from S3 into a DynamoDB table.

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now