As far as I know there's nothing special in DNN Core to limit the volume each user can upload files. Are there any ways like changing the code or installing any modules to handle that? (for example I don't want to let users to upload more than 100MB into a space allocated to them)
Is there any configuration in DNN core that puts user uploaded files in separate folders so that the browsing of files becomes easier? Any modules recommended. (for example I want to upload user12 files to a folder named user12 or anything similar)
The setting to establish and enforce a quota for file storage would be set at the module level -- not the DNN/Portal level. It depends on the module that you use.
There does not appear to be too many choices regarding a DNN Module that would allow your users to upload various files into their own folder. However, I did find one that has two positive reviews that, if it works as promised, should suit your requirements
http://www.snowcovered.com/snowcovered2/Default.aspx?tabid=242&PackageID=16691
According to the author, it allows you to give users their own directory which they can upload to.
DNN supports disk quotas on a per portal basis. I am not aware of a module that allows disk quotas on a per user basis.
You can find the settings under Admin | Site Settings | Advanced Settings | Host Settings
Related
I am currently learning Kubernetes and I'm stuck on how to handle the following situation:
I have a Spring Boot application which handles files(photos, pdf, etc...) uploaded by users, users can also download these files. This application also produces logs which are spread into 6 different files. To make my life easier I decided to have a root directory containing 2 subdirectories(1 directory for users data and 1 for logs) so the application works only with 1 directory(appData)
.appData
|__ usersData
|__ logsFile
I would like to use GKE (Google Kubernetes Engine) to deploy this application but I have these problems:
How to handle multiple replicas which will read/write concurrently data + logs in the appData directory?
Regarding logs, is it possible to have multiple Pods writing to the same file?
Say we have 3 replicas (Pod-A, Pod-B and Pod-C), if user A uploads a file handled by Pod-B, how Pod-A and Pod-C will discover this file if the same user requests later its file?
Should each replica have its own volume? (I would like to avoid this situation, which seems the case when using StatefulSet)
Should I have only one replica? (using Kubernetes will be useless in that case)
Same questions about database's replicas.
I use PostgreSQL and I have the same questions. If we have multiple replicas, as requests are randomly send to replicas, how to be sure that requesting data will return a result?
I know there a lot of questions. Thanks a lot for your clarifications.
I'd do two separate solutions for logs and for shared files.
For logs, look at a log aggregator like fluentd.
For shared file system, you want an NFS. Take a look at this example: https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs. The NFS will use a persistent volume from GKE, Azure, or AWS. It's not cloud agnostic per se, but the only thing you change is your provisioner if you want to work in a different cloud.
You can use persistent volume using NFS in GKE (Google Kubernetes Engine) to share files across pods.
https://cloud.google.com/filestore/docs/accessing-fileshares
Based on the subdomain that is accessing my application I need to include a different configuration file that sets some variables used throughout the application (the file is included on every page). I'm in two minds about how to do this
1) Include the file from GCS
2) Store the information in a table on Google Cloud SQL and query the database on every page through an included file.
Or am I better off using one of these options and then Memcache.
I've been looking everywhere for what is the fastest option (loading from GCS or selecting from cloud SQL), but haven't been able to find anything.
NB: I don't want to have the files as normal php includes as I don't want to have to redeploy the app every time I setup a new subdomain (different users get different subdomains) and would rather either just update the database or upload a new config file to cloud storage, leaving the app alone.
I would say the most sane solution would be to store the configuration files in the Cloud SQL as you can easily make changes to them even from within the app and using the memcache since it was build exactly for this kind of stuff.
The problem with the GCS is that you cannot simply edit the file and you will have to delete and add a new version every time which is not going to be optimal in a long run.
GCS is cheaper, although for small text files it does not matter much. Otherwise, I don't see much of a difference.
I'm running a DotNetNuke 7.0 Community Edition installation and I'm currently looking for a way of allowing users to upload own content into their very own directory. I would also like the users to have a maximum storage limit of for instance 2GB. Perhaps there already is an in-built solution for this scenario but I'm also willing to spend money for a commercial module.
So I've not found an on-board setting allowing me to set a per-user-quota, neither have I been able to find a module available in the store http://store.dnnsoftware.com for several hours now.
I even decompiled the DotNetNuke.dll in my installation directory and noticed it has members called UserQuota in DotNetNuke.Portals.PortalSettings and DotNetNuke.Entities.Portals.PortalInfo but I still failed to find where to define a quota for my users. Is this a Professional/Enterprise feature only by any chance?
Any help would be greatly appreciated. If there's no such module I can also write a custom module, but instead of reinvent the wheel I'd love to hear your ideas first.
Thanks.
For future reference:
I ended up coding a custom DNN upload plugin which stores all files users upload into their own directory and controls the maximum storage space each of these users has. If you need this for an own project just drop me a message for the .zip.
DotNetNuke has a portal level quota for file-space that you can set. This is available under "Admin" -> "Site Settings" -> "Host Settings" (On Advanced Tab).
However, this is for the entire portal. I am not aware of any user specific, or folder specific quota mechanism for DotNetNuke.
I am running Sitecore 6.5
I have two installations of Sitecore and want to transfer a whole site from one installation to another.
Have found a few articles that go into Serialization and Creating a Package although they don't go into detail about how these two fit together.
How do I transfer a site from one installation to another?
thanks.
Create a package with the package designer.
include these items and their children with the button "items statically". if you have placed your solution specific item in folders, it is only needed to include these.
/sitecore/content
/sitecore/layout
/sitecore/media library
/sitecore/templates/ (only take the templates you have created. e.g. the folder user defined
using the button "files statically", include the folders with you have solution specific changes to like:
/bin
/layouts
/app.config/include (only take the files changed in the solution,
compared to a default sitecore installation)
web.config (if you have made changes to this, compared to default
sitecore web.config)
if you have any user accounts you want to transfer to, you can include them with "security accounts".
then generate zip file and install on empty sitecore and full publish :)
If your systems are similar enough, you may want to consider moving the Sitecore DBs via backup/restore (in SQL) and copying over filesystem assets. Generally I find this faster and less prone to user error than creating/installing very large packages. (Just remember to take back-ups first.)
Large packages have a tendency to break, one option would be to look into this:
http://www.hhogdev.com/Products/Team-Development-for-Sitecore/Overview.aspx
TDS can sync all your items to XML on your dev box and from that you can create a different sort of installation package which is significantly more robust than a regular package you create through the Sitecore desktop. It's the same sort of package that Sitecore use when you upgrade versions.
I believe there is a 60 day trial on this product so plenty of time to try it out.
Note: when transferring user accounts, passwords will not be migrated when using either packages or serialization.
Solution is here - cowboy-aspx from Sitecore :)
https://kb.sitecore.net/articles/242631
Here's my requirement:
1. I want my installable to have a custom license agreement
2. run another package as part of the installation
3. let the user have an option of running the app on start-up
What should I use, create a dmg or use PackageMaker available with xcode? Are there any good web pages showing how to use PackageMaker?
Thanks.
They serve different purposes:
DMG (disk images) is just a container file format to solve age-old issues with multi-fork files and transfer protocols and intermediate hosts that can't handle them, by not relying on them in the first place. In addition, the disk images can use internal compression. Your users will thank you for not confusing them with file wrapped in file wrapped in file (although disk images themselves take some explaining initially).
PackageMaker is a full-fledged installer package builder. You can customize the installation process and locations, do sub-installations and pretty much anything else you could possibly need. If your installation entails more than just dragging and dropping an application bundle into place, this is the one to go with.
From your requirements, the choice seems obvious. Since an installer package is itself a bundle, I'd say: create an installer package with PackageMaker and put it in a compressed disk image. Distribute the disk image to your users. It just provides a nicer experience.