Yes, for a Linux server at AWS, you typically launch it via the AWS
Console (web page) and get an SSH key. Then ssh to the server
using the SSH key, and work from the command line.
If you prefer to always use a GUI, not a CLI, you can use X Windows
or a Web-based Linux admin GUI. But I've never done that. I
always use the Unix CLI.
The OS is already installed, along with any other software that
is included in the Amazon AMI. If you start by launching an
instance of the "Amazon Linux AMI", you get a vanilla Linux
OS, with not much else installed. If you want things pre-installed,
launch your server as an instance of an AMI that has what you
need. There are thousands of combinations, so you can probably
find any combo that you need. I always start with the "Amazon
Linux AMI" and install the rest myself.
Yeah, as you guessed, the Django account to connect to the DB
should not need rights to create/modify tables, except when you
are doing a Django "manage" command like "syncdb" or "migrate".
At normal runtime, it should only need the rights to SELECT,
INSERT, UPDATE, and DELETE data in existing tables.
--Fred
Fred Stluka -- mailto:fred@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.
Fred Stluka -- mailto:fred@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.
On 4/29/16 7:09 PM, Patrik Mjartan wrote:
I had a brief look and AWS looks really good indeed. Thank you very much for thorough explanation as well on how to go about it.--
A rather newbie question - when I make an account on AWS, I assume I have to ssh there from my local computer to do 'anything', that is, there is no 'shared desktop' or any such thing, is there, that is, everything has to be done through command line, right?Similarly, what about installing the OS itself? Is it some pre-installed linux version where I ssh into and do my thing, or how does it work?
Also a thing that I was not sure about - does the django's account that connects to the DB has to have rights to create/delete tables (+ certain update/insert/delete restrictions)? I assume all the tables are setup when the app is under development and once it's 'up in the public' there isn't going to be excessive changes to the back-end. Of course there could be once in a while, but that could be, again, using 'root' type of account for the DB itself, once it's done the django would again use non-root DB account.
On Friday, April 29, 2016 at 9:17:08 PM UTC+1, Fred Stluka wrote:Patrik,
I host the servers of all my clients at AWS (Amazon Web Services).
I'd suggest you start by running the DB server (MySQL, PostgreSQL
or whatever) on the same Linux server as the Web server (Apache,
nginx or whatever). Have the Web server handle all the static files
(HTML., JS, CSS, image) and forward the Django requests via WSGI
or uWSGI to the Django server on the same Linux server. You can
do it all with one AWS EC2 micro instance, which is free for the
first year, and only $0.02/hour ($15/month) after that.
As your needs grow, you can scale vertically by converting your
micro instance to a small, medium, large, XL, XXL, etc. And/or
you can scale horizontally, by moving the DB server to it's own
EC2 Linux server or to the AWS RDS service. And by using AWS
ELB, Autoscale, ElasticBeanstalk, etc., to manage farms of web
servers and DB servers, allocating and terminating servers as
needed to handle the load. It's a one-line change in the Django
settings file to point Django to the IP address of an RDBMS on a
different server.
Or turn the entire ops business over to AWS and just use their
AWS Lambda service to serve the HTTP requests. I haven't yet
done that with Django, so you'd have to look into how well it
works.
For security reasons, configure Django to use a non-root user
at the DB server, ideally one with as few privileges as possible.
And make sure that the DB server is running as a non-root Linux
user. It everything accesses everything as root, you have a big
security risk. If someone DID succeed in hacking your Django
app, and became able to get it to execute arbitrary SQL calls,
they could make an SQL call that causes the DB server to make a
system call (as root), that could run arbitrary code on your Linux
server. So, lock it down at each level, just in case.
For more info about AWS, see:
- http://bristle.com/Tips/CloudComputing.htm
- http://bristle.com/Talks/CloudComputing/current/
For direct printer access from a web app, see:
- http://google.com/search?q=direct+printer+access+from+a+ web+app
Lots of hits, so I'm thinking it must be possible.
--Fred
Fred Stluka -- mailt...@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.
On 4/29/16 2:40 PM, Patrik Mjartan wrote:
--Sorry, I miss-clicked post button and so I will reply twice now.
Another important (rather obvious to you I guess) question would be - what is the usual structure of the servers?
What I mean is - I assume we don't want to have the actual DB on the same server as where we host the website.
Is it usually such that Web server is hosted by some hosting company (so they can make sure it's up 24/7) while DB server is on the premises of the company (ie. the one for which I work for) such that data can be retrieved faster? Although I guess that doesn't make too much sense either, as the data has to be retrieved by web-server first in order to be presented to the user...
Overall I'm quite sure that the company I work for would prefer paying some hosting companies to host everything so they don't have to spend money on (potentially) expensive hardware. Is this the standard approach?
I'm a total newbie in this area so would appreciate some help ^_^.
On Friday, April 29, 2016 at 7:33:58 PM UTC+1, Patrik Mjartan wrote:Thank you very much for the reply!
I went through the tutorial a few days ago and loved it.
One, very important, question that I forgot to ask - one of the biggest advantages on having an actual desktop front-end app is having a direct access to media, such as printers. Hence a simple button click in the app would result in some document getting printed by default printer (or w/e printer is selected by code, not necessarily user). Is it possible to capture such functionality by web-app at all? Printing PDF documents is not a huge problem (users can just download the PDF invoice and print it manually), problem is for example receipts (in case of future expansion to include on-site sales).
If it is not possible to do it directly, I guess it's always possible to make a small stand-alone app that communicates with the server and listens on when it should print certain documents.
On Friday, April 29, 2016 at 7:05:52 PM UTC+1, Fred Stluka wrote:Patrik,
Yes, Django can be used for that.
The "ORM" features and the "templates" and "views" of Django
make it very easy to do a "CRUD" app for a users to create/
retrieve/update/delete data in any RDBMS.
There are some built-in security features like logins, protection
against "CSRF" attacks, etc.
Django "formsets" make it easy to show multiple rows with a
details panel for the row currently selected.
With a web app, you won't have to re-distribute the front
end. Just push a new version to the server.
Django's templates and views both support "inheritance",
which should solve your problem of managing multiple
related forms. And, there are many Open Source custom
widgets for Django and for JavaScript that will give you all
the sub-grouping and tree-views that you need.
Django scales very well to large amounts of data, large
numbers of screens, and large numbers of users. There
are many performance tuning options, including "caching"
of templates, and of fully-constructed pages, and of DB
data. Also, lots of other "middleware" for security,
performance, logging, and other "aspects" of the software.
Yes, you can run a Django server locally, behind a "firewall",
or can expose it to the world, securing various parts as
needed.
To make it as secure as possible, I'd put in on a Linux server
that is protected by tools like Logwatch, Fail2ban, and
Tripwire. See:
- http://bristle.com/Tips/Unix.htm#unix_security
And be sure to redirect all page requests from HTTP to
HTTPS.
I do all of this and more, including processing financial
transactions and supporting "multitenancy", restricting
access by thousands of different users, each to his own data,
plus "attribute based access control" for cases where data is
shared, at the Web site I'm currently working on:
- http://HelpHOPELive.org
Sorry for all the terms and acronyms, but if you're considering
writing such an app, you'll need to be aware of them and they're
all pretty easy to Google. Feel free to reply with more questions.
Also, you'll quickly get a feel for Django's power if you go
through the on-line tutorial at:
- https://docs.djangoproject.com/en/dev/intro/
Enjoy!
--Fred
Fred Stluka -- mailt...@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.
On 4/29/16 12:57 PM, Patrik Mjartan wrote:
Hi,--
I work for a very small company that I developed an application for, all using MS Access (it has back-end MS Access db - although this is planned to change to some more robust RDBMS, and a front-end app built in MS Access). Currently this app is used to calculate the exact wages of some employees (sorry, English is not my native language so I don't know how that type of wage is called here, but basically we look at how many products they produced and calculate it based on that. It's not a hourly wage). However, this summer I would like to expand it to do some order management too (ie. each order has specific products that need to be produced... each of those can be produced by our employees and so it's directly linked to the wages).
However, it is very hard to manage everything using MS Access. Basically each time I make any change to FE or BE, I have to re-distribute the FE to all of the front-users. This is not a HUGE problem, the big problem, however, is within the MS Access itself, that is, it's very hard to manage all the forms as they are listed as simple names (ie. you cannot sub-group them efficiently to make a tree-view). Overall I cannot see myself working with MS Access in 5 years time as I can already see the scalability problems after a few months of working with it.
What I thought of, however, is making a website that is only for local use, but is it possible to have the same functionality as a regular front-end app? Is this good idea to begin with? I had a brief look at Django (I'm VERY new to web-dev, but I'm a fast learner I like to think) and I really like it so far. But is it possible to have the same level of functionality MS Access offers? That is, for example a sub-form on a form that gives more details about the current record selected in the main form? Ie. main form consists of overview of 10 recent orders and the lower portion of the main form is a subform that displays some detailed info about a selected order.
How does it stand from security-perspective if the app is changed from local to public? Obviously even on local I'd imagine I'd put a login requirement there, similar to how the admin page has it, but how safe is it regardless if put to public? Are there pre-determined measures that if taken, it will be 100% secure? As you'd imagine I wouldn't be very happy if someone deleted all of our inventory records because they could bypass the logging system.
Is there any good literature I can read up on doing some similar exercises/examples? For instance: orders/inventory management web app?
Thanks a lot in advance!
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com .
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/fdee3fe0- 6f3e-4d5b-862c-3a875b04035b% 40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com .
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users .
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/af709945- ddab-4e9b-97bb-ffc6d36f34dc% 40googlegroups.com.
For more options, visit https://groups.google.com/d/optout .
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/727bc5dd-0df8-4b78-951f-8f1b999b9e5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment